Visual C++ 2010 和本机可执行文件
原生exe！ 这意味着我的程序可以轻松运行而无需任何要求？ 即使我使用.net 类？
你知道我想编写一个非常轻量的程序，但我不喜欢使用 C# 或任何其他 .net 编程语言，因为它们都需要 .net-framework 4.5。
试想一个 2.5 MB 的程序需要 +250 MB 的 .netframework。
新更新 - 12/01/2016：
当我问这个问题时已经是差不多 4 年前了。如您所知，Dotnet Native 已发布。将 IL 编译为本机代码是一个有趣的功能。
.NET Native是一种用于构建和部署的预编译技术 Visual Studio 2015 附带的 Windows 应用程序。 自动编译编写的应用程序的发布版本 托管代码（C# 或 Visual Basic）并且面向 .NET Framework 和 Windows 10 到本机代码。通常，面向 .NET 的应用程序 框架被编译为中间语言（IL）。在运行时， 即时 (JIT) 编译器将 IL 转换为本机代码。在 相比之下，.NET Native 将 Windows 应用程序直接编译为本机代码。 对于开发人员来说，这意味着：
- 您的应用将提供本机代码的卓越性能。
- 您可以继续使用 C# 或 Visual Basic 进行编程。
- 您可以继续利用.NET Framework提供的资源，包括其类库、自动内存 管理和垃圾收集以及异常处理。
Native exe!
that means my program can run easily without any requirement?
even if I use .net classes?
You know I want to write a program that is so light and I don't like to use C# or any other .net programing language because all of them need .net-framework 4.5.
Just think a 2.5 MB programm needs a +250 MB .netframework.
New Update - 12/01/2016:
It's almost 4 years ago when I asked this question. As you know Dotnet Native is announced. It's an interesting feature which compile IL into native code.
Compiling Apps with .NET Native
.NET Native is a precompilation technology for building and deploying
Windows apps that is included with Visual Studio 2015. It
automatically compiles the release version of apps that are written in
managed code (C# or Visual Basic) and that target the .NET Framework
and Windows 10 to native code. Typically, apps that target the .NET
Framework are compiled to intermediate language (IL). At run time, the
just-in-time (JIT) compiler translates the IL to native code. In
contrast, .NET Native compiles Windows apps directly to native code.
For developers, this means:
- Your apps will provide the superior performance of native code.
- You can continue to program in C# or Visual Basic.
- You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory
management and garbage collection, and exception handling.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最后我检查了没有一个 .NET 框架超过 250 MB！是的，.NET Framework 3.5 SP1 的离线安装程序为 231MB，但它包含 x86 和 x64 版本的 .NET 2、3 和 3.5 sp1。
您应该阅读http://www.smallestdotnet.com，了解有关各个版本的安装程序大小的详细信息。
现在回答你的问题：
是的，让你的客户安装一个大框架有点烦人，即使是 20-40MB 也会让人烦人。与其他本机选项相比，.NET 的优点是易于编程（在我看来）。
您的本地选项是：
MFC - 您只需要安装 VS 运行时，该运行时大小为 1-2MB，通常安装在较新的电脑上。另外，您可以将应用程序与打包到 dll 中的 MFC 库一起发布，该 dll 又小于 2MB。
这里的交易是您需要使用 C++ 进行编程，总体而言，库是本机库之上非常薄的一层。人们对 MFC 也有过严厉的评价。我刚刚才刚刚尝试过。
Win32 API - 这一切都是简单的，而且相当困难，你可以使用 C 或 C++，但你真的必须了解很多关于 Win32 API 以及 Windows 本身如何工作的知识（像 windows 这样的东西）消息、hwnds 等）相信我，这并不有趣。但在部署过程中，您不需要任何外部库。
还有大量更多选项，请参见此处：
本机 Windows 应用程序开发选项
https://stackoverflow.com/ questions/2711599/what-programming-language-should-i-use-to-create-small-native-windows-applicatio
以下是 MFC 上的一些链接，可能会有所帮助：
想学习 Windows 编程，有一些建议吗？
如何决定新的 C++ 项目是使用 ATL、MFC、Win32 还是 CLR？
C++ MFC 与 .NET？
https://stackoverflow.com/questions/557114/stick-with-mfc-或-进入网络
Last I checked none of the .NET frameworks were 250+ MB! Yes, the offline installer for .NET Framework 3.5 SP1 is 231MB but it contains x86 and x64 versions of .NET 2, 3 and 3.5 sp1.
You should read this http://www.smallestdotnet.com for details on sizes of various versions of the installers.
Now on to your question:
Yes, It is a little annoying to have your clients install a big framework, even 20-40MB does get annoying. With .NET, the advantage is the ease of programming (In my opionion) compared to other Native options.
Your native options are:
MFC - You need only the VS runtimes installed, which is 1-2MB and is usually installed on newer pcs. Also, you can ship your application with the MFC libraries packaged into a dll which is again <2MB
The trade of here is you need to program in C++, the libraries overall are a very thin layer over the native libraries. and people have had harsh opinions about MFC. I've barely just tried it.
Win32 API - This is going all bare bones, and quite difficult, you could use C or C++ but you'd really have to know a lot about the Win32 API and how windows itself works (Stuff like windows messages, hwnds etc) Its not fun, believe me. But during deployment you would not need any external libraries.
There are tons more options, see here:
Native Windows Application Development Options
https://stackoverflow.com/questions/2711599/what-programming-language-should-i-use-to-create-small-native-windows-applicatio
Here are some links on MFC that might help:
Want to learn Windows Programming,some suggestions?
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
C++ MFC vs .NET?
https://stackoverflow.com/questions/557114/stick-with-mfc-or-go-to-net
您可以使用 c++ Win 32 项目创建本机 exe。
you are able to create native exe by using c++ Win 32 projects.
唉，几乎所有东西都需要下载运行时库，即使您安装了一个运行时库，您也几乎需要不断地下载它们的更新。如今，即使是 Microsoft C++ 应用程序也附带了安全更新，如果您使用它们编译了应用程序，则必须安装这些更新。
但是..有一种解决方案。如果您使用 C++，它有一个功能，即只有您使用的内容才会编译到最终应用程序中。通常，这需要链接所有库 dll，但如果静态链接库，最终会得到一个尽可能小的 .exe，并且不需要任何 dll（因为所有代码库中包含的内容将被编译到.exe中）。
与 dll 相比，其好处是值得商榷的，但由于 MS 几乎打破了 .NET 中共享 dll 的理念（即，您实际上必须将所有共享 dll 放在与正在运行的应用程序相同的目录中，这给您带来了维护方面的噩梦）如果您的所有应用程序中都分布有这些共享 dll），那么就不再有太大区别了。静态链接正在卷土重来，听起来就像你想要的那样。
对于现代 C++ 开发，您可能需要查看 Qt 而不是 MFC。它使用起来更好，并且是跨平台的，因此您可以在 Android 或 Linux 平台以及 Windows 上运行 Qt 应用程序。
Alas, nearly everything requires a download runtime library and even if you have one installed, you'll need to download updates for them almost continually. Even Microsoft C++ apps nowadays come with security updates that have to be installed if you've compiled your app with them.
But.. there is a solution of sorts. If you use C++, it has a feature where only the things you use are compiled into the final app. Normally, this would require linking with all the library dlls, but if you statically link with the library, you will end up with a single .exe that is as small as can be, and you will not need any dlls (as all the code contained in the library will be compiled into the .exe).
The benefits are debatable compared to dlls, but as MS has pretty much broken the idea of shared dlls in .NET (ie, you practically have to put all the shared dlls in the same directory as your running app, giving you a nightmare in maintenance if you have these shared dlls spread around all your apps) then there's not much of a difference anymore. Static linking is getting a little bit of a comeback and sounds like its what you want.
For modern C++ development, you'll probably want to take a look at Qt instead of MFC. Its a lot nicer to use and is cross-platform so you can run Qt apps on your Android or Linux platforms as well as Windows.