Win32控制台应用程序 vs. CLR控制台应用程序

Question

我正在开发一个C++项目，不打算使用.NET库或工具进行开发或部署，因此创建一个使用Visual Studio Win32控制台应用程序是合理的。但是，我听说在Visual Studio下使用CLR应用程序进行调试的能力更强大。所以我有几个问题：

1. 如果不使用任何.NET库或其它资源，是否使用CLR应用程序比Win32应用程序增加了开发过程中的功能？

2. 如果是这样的话，我是否仍然能够将项目开发/编译为CLR项目，以利用这些功能，即使我使用STL等纯C++项目而不利用任何.NET功能？或者这样的项目需要基本的差异，使得恢复到原状态变得非常困难，这意味着我应该坚持使用Win32控制台应用程序？

- bsofman

Answer 1

简而言之，如果您不打算在应用程序中使用CLR或任何.Net对象，只需使用普通的Win32 C++库。其他做法将会给你带来麻烦。

现在回答关于调试的原始问题，是的，与调试普通的C++应用程序相比，使用CLR进行调试具有某些优势。从Visual Studio 2005开始，C#和VB.Net都开始专注于使本地/自动/观察窗口中的变量显示更加有价值。这主要是通过引入.NET属性（例如DebuggerDisplay、DebuggerTypeProxy和可视化器框架）来实现的。

但是如果您不使用任何.Net类型，则无法获得这些好处。

C++表达式求值器不利用其中任何一个。它具有自己的方法来定制类型显示。但是，它没有属性样式那么丰富（或潜在危险），因为它不允许在 debugee 进程中运行代码。

这并不意味着调试C++提供了糟糕的体验，仅仅是不同，并且对许多STL容器类型有更好的显示。

调试CLR应用程序也存在某些缺点。例如，由于JITer将隐藏局部变量、参数和常见的“this”，因此有时很难调试优化的代码。同样构建的C++应用程序的调试也可能令人沮丧，但您可以始终抓取寄存器和反汇编以查看情况。但对于CLR应用程序来说，这样做非常困难。

- JaredPar

---

非常感谢您详细的回答！我想知道您是否能够详细说明一下您的第一个声明，并解释这种设置可能长期面临哪些问题？这主要是因为无意中使用了.NET对象/功能，它们编译得很好，然后以后不得不更改应用程序中深度嵌入的代码部分吗？ - bsofman

@bsofman，基本上是这样。为了既能利用CLR又能在没有CLR的情况下部署，您需要两个构建配置（每个都需要一个）。语言之间的差异将显示为其中一个配置中的构建错误，而不会出现在另一个配置中，最终可能会变得非常烦人。 - JaredPar

Answer 2

我认为将本地C++代码编译为CLR会引起一系列麻烦。除非您已经投入大量精力来开发现有的C++代码，并且必须使用托管类型运行代码，否则建议避免这样做。

例如，C++/CLI是将本地C++代码打包到CLR程序集中的一种方法，但C++/CLI为C++语言添加了非标准语法，同时使用本地C++类型与托管类型混合似乎是一个非常棘手的问题。

总之，我建议仍然将其保持为本地应用。如果您计划将其移植到CLR，并且刚开始开发此项目，我建议考虑使用CLR本地语言（如C#）开始编写。

- Kei

Answer 3

这个答案是从这里复制的 - http://social.msdn.microsoft.com/Forums/vstudio/en-US/895ecb47-8b34-4a1a-a20b-fda1e5e576eb/whats-the-difference-between-clr-console-application-and-win32-console-application CLR控制台应用程序和Win32控制台应用程序有什么区别？ - 前者使用公共语言运行时（换句话说，.NET框架）；后者不使用。

在win32控制台应用程序模型下，我不能使用System命名空间。 - System命名空间是.NET框架的一部分。

当我想使用该命名空间时，我该怎么办？ - 您应该编写一个.NET应用程序。

在C#模型中没有输入提示吗？ - 在现有版本的Visual Studio中确实没有针对C++/CLI的智能感知。如果您想要一个.NET应用程序，C#可能是更好的语言选择。

- Steam