我有一个使用 Visual Basic 2010 的 CLI 控制台应用程序制作的可执行文件。我可以在我的开发人员机器上完全运行该程序。
但是,当我将可执行文件复制到另一台机器上,重新启动到预安装环境并再次运行可执行文件时,什么也没有发生。没有显示错误或任何内容。
我的猜测是,如果没有在此环境中未加载的某些依赖项,可执行文件将无法运行,但我需要它在 PE 中工作。
关于发生了什么的任何想法?
首先,由于问题被标记为“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 不支持 .NET Framework。
请注意,您是否编写了 WinForms、WPF 或控制台应用程序是无关紧要的。尽管它们以非常不同的方式呈现其 UI,但它们都依赖于所安装的 .NET Framework。
您将需要(重新)用另一种编程语言编写应用程序,这种语言可以生成本机代码,而不依赖于 .NET Framework。C 和 C++ 是流行的选择。如果您选择使用 C++,请确保创建 Visual Studio 所称的“Win32”项目。这是一种直接针对底层操作系统 API(即本机应用程序)并且不依赖于 .NET Framework 的应用程序。远离描述中包含“.NET”或“CLR”的任何内容。
我对应用程序何时使用 .NET 并没有完全理解……我只是习惯于 Linux C/C++ 开发。我讨厌微软的狗屎
每当您在代码中使用 .NET Framework 库/类时,它都会使用 .NET。我不太确定为什么这很难理解。如果您使用的第三方库由于某种原因在某些环境中不可用,那么 Linux 上很容易出现同样的问题。这不是微软的问题,而是使用错误的工具来完成工作的问题。.NET Framework 是围绕本机 API 的面向对象的包装器,它使人们更容易启动和运行为 Windows 编写程序。但是,如果您“习惯于 Linux C/C++ 开发”,那么在不使用 .NET 的情况下编写一个直接针对本机 API 的简单控制台应用程序应该不会有什么问题。
如果您对“Microsoft 狗屎”的仇恨已经变成了一种过敏,您可以完全避免使用 Visual Studio 并下载MinGW,这是您可能习惯的 GCC 编译器的 Windows 端口。结合您最喜欢的 Windows 移植版 Vi,您可以在与您习惯的环境非常相似的环境中工作。由于 GCC 不支持 C++/CLI 或 .NET Framework,因此您不必担心选择错误的选项。
在过去几个 WinPE 版本的 PE 构建过程中,已支持将 .Net 框架作为可选包安装。我用 C# 编写代码,每天在 WinPE 中运行。我还没有找到一种可以通过断点等方式进行调试的好方法……不过。我最好的选择只是在我的主要入口点周围进行大量日志记录和一个全局异常捕获,它将写出一个完整的堆栈转储。您可以在运行 WinPE 的 VM 中作为远程进程附加到您的应用程序,但如果您需要在执行的早期捕获某些内容,您将遇到困难。