我使用带有Visual Basic 2010的CLI控制台应用程序创建了一个可执行文件。我可以从我的开发人员计算机上完全运行该程序。
但是，当我将可执行文件复制到另一台计算机时，重新启动到预安装环境并再次运行可执行文件，根本不会发生任何事情。没有显示错误或任何错误。
我的猜测是，如果没有在此环境中未加载的某些依赖项，可执行文件无法运行，但我需要它在PE中工作。
关于最新情况的任何想法？
答案 0 :(得分：2)
首先，由于问题被标记为“c ++”并且您多次提到C ++ / CLI，我认为“Visual Basic 2010”是“Visual Studio 2010”的拼写错误。但不管怎样，无论你是用Visual Basic（VB.NET）还是用C ++ / CLI编写应用程序，问题都是一样的。
我的猜测是，如果没有在此环境中未加载的某些依赖项，可执行文件无法运行，但我需要它在PE中工作。
这是完全正确的。您编写了一个针对.NET Framework的应用程序。有点像需要JVM的Java应用程序，.NET应用程序要求安装.NET Framework才能运行（或兼容的替代实现，如Mono）。不幸的是，Windows PE does not support the .NET Framework。
请注意，您是否编写了WinForms，WPF或Console应用程序是无关紧要的。虽然他们以非常不同的方式呈现他们的UI，但他们所有依赖于正在安装的.NET Framework。
您需要（重新）以不同的编程语言编写应用程序，该语言生成本机代码而不依赖于.NET Framework。 C和C ++是流行的选择。如果选择使用C ++，请确保创建Visual Studio称为“Win32”项目的内容。这是直接针对底层操作系统API（即本机应用程序）并且不依赖于.NET Framework的API。远离任何在其描述中包含“.NET”或“CLR”的东西。
我真的不完全理解应用程序何时使用.NET ...我只是习惯于Linux C / C ++开发。我讨厌微软狗屎
只要在代码中使用.NET Framework库/类，它就会使用.NET。我不太确定为什么这么难理解。如果您使用的是某些环境中因某些原因无法使用的第三方库，则Linux上很容易出现同样的问题。这不是微软的问题，而是使用错误的工具来解决这个问题。 .NET Framework是一个面向对象的本机API包装器，它使人们更容易启动和运行Windows编写程序。但是，如果您“习惯于Linux C / C ++开发”，那么在不使用.NET的情况下编写一个直接面向本机API的简单控制台应用程序应该没什么问题。
如果您对“Microsoft shit”的仇恨变成过敏，您可以完全避免使用Visual Studio并下载MinGW，这是您可能习惯的GCC编译器的Windows端口。结合您最喜欢的Vi端口，您所处的环境与您习惯的环境非常相似。由于GCC不支持C ++ / CLI或.NET Framework，因此您不必担心选择错误的选项。
答案 1 :(得分：1)
在过去几个版本的WinPE的PE构建过程中，.Net框架已作为可选包安装受到支持。我用C＃编写代码，每天都在WinPE中运行。我还没有找到一种好的方式来调试，我可以通过断点等方式进行调试......我最好的选择就是进行大量的日志记录，并在我的主要入口点附近捕获一个全局异常，它将写出一个完整的堆栈转储。您可以在运行WinPE的VM中作为远程进程附加到您的应用程序，但是如果您需要在执行的早期捕获某些内容，那么您将遇到困难。