微软和 Visual C++
微软、Visual Studio 和 Visual C++ 那些事……
.NET 框架
.NET 框架（.NET Framework）的 维基百科 中有很详细的阐述，其中的 组件堆栈图 一目了然，对于 .NET vs. Java EE 和 .NET vs. COM 的介绍也言简意赅。以下摘取几句，做笔记。
.NET框架是以一种采用系统虚拟机运行的编程平台，以通用语言运行库（Common Language Runtime）为基础，支持多种语言（C#、F#、VB.NET、C++、Python等）的开发。
通用中间语言被设计来即时编译（JIT），而Java的字节码在最初的时候则是设计成用于解释运行，而非即时编译。
前一版软件组件技术由Microsoft所提出的COM，该技术被用来创建大型（large-scale）的软件系统上，使用COM+ 或MTS对于传统分布式组件有强化的作用。很明显的，Microsoft最终将以.NET全面替换COM成为软件组件的架构。
.NET 的语言
CLI是一套运作环境规范，包括一般系统、基础类库和与机器无关的中间代码，全称为Common Language Infrastructure。如果一种语言实现生成了CLI，它也可以通过使用CLR被调用，这样它就可以与任何其他.NET语言生成的数据相交互。CLR也被设计为操作系统无关性。
CLI被设计成支持任何面向对象的编程语言，分享共同对象模型与大型共同类库。
大部分的语言都做了重大改变以搭配.NET框架。厂商通常利用这个机会来同时改变语言的其他特性。
C#，一个以C++和Java语法为基础开发的一个全新的面向对象语言，是.NET开发的首选语言。
我们圈外人以为做 C# 的就是 .NET，其实前者只是后者的官方开发语言。
Visual Basic .NET，一个加强了面向对象支持的，支持多线程的Visual Basic版本。
VB .NET 和 VB 不同。
C++/CLI，一个C++的.NET平台版本变种。
接下来我们就说说这个。
托管 C++ 和 C++/CLI
托管C++并非独立存在的编程语言，而仅仅是微软对C++的一个语法扩展，允许C++程序员在.NET框架和CLR的基础上进行托管编程。
C++ 托管扩展（Managed Extensions for C++，也经常被称为“托管 C++”）自Visual C++ 2005起被正在标准化的C++/CLI所替换。
目前只有托管C++及其后继者C++/CLI可以做到无缝集成托管和非托管代码，在托管代码中调用COM的速度又相当慢（所以用非托管代码调用咯），所以经常被用于其他语言和非托管代码之间的桥梁。
C++/CLI（CLI: Common Language Infrastructure）在计算机语言中是一门由微软设计，用来代替C++托管扩展（Managed C++，下文使用MC++指代）的语言。这门语言在兼容原有的C++标准的同时，重新简化了托管代码扩展的语法，提供了更好的代码可读性。
托管代码和本地代码
在维基百科 托管代码 的词条中提及托管代码的运行：
运行代码时，运行库编译器（runtime-aware compiler）在受控运行环境下，将中间语言（Intermediate Language）编译成本机的机器码。受控运行环境可为代码插入垃圾回收、异常处理、类型安全、数组边界和索引检查等，以保证代码安全的运行。
另有 博客 介绍的很好。
Visual Basic .NET和C#只能产生托管代码。如果你用这类语言写程序，那么所产生的代码就是托管代码。如果你愿意，Visual C++ .NET可以生成托管代码。当你创建一个项目的时候，选择名字是以.Managed开头的项目类型。例如.Managed C++ application。
跟Visual Studio平台的其他编程语言不一样，Visual C++可以创建非托管程序。当你创建一个项目，并且选择名字以M FC，ATL或者Win32开头的项目类型，那么这个项目所产生的就是非托管程序。
托管代码和非托管代码性能的比较：理解这个问题的关键在于对“即时编译器”和“解释器”是否有正确的认识。
.Net程序被加载入内存以后，当某段IL代码被第一次运行的时候，JIT编译器就会将这段IL代码，全部编译成本地代码，然后再执行。这也就是为什么.NET程序第一次运行都启动很慢的原因！ 随.NET库，微软还附带了一个工具，可以事先将.NET程序所有的IL代码都编译成本地代码并保存在缓存区中，这样一来，这个程序就跟c++编译的一模一样了，没有任何区别，运行时也可以脱离JIT了（这里不要混淆了，这里不是说可以脱离.NET库，而是说不需要在进行即时编译这个过程了）。
所以，请不要将.NET和Java混为一谈，两个的运行效率根本不是一个等级的！
打包工具
我们在 VS2010 中更习惯使用 Visual Studio Installer 打包项目，进行安装和部署。但不知什么原因（目前我还不知道，也没有在网上认真找过 资料），微软放弃了自家的这款工具，在 VS2012 中不再有，而只能用 InstallShield Limited Edition，同时更新过 VS2010 的朋友也会发现在“安装和部署”下除了原有的 Visual Studio Installer，也增加了 InstallShield LE 项目，看来微软是铁了心放弃 VS Installer 了，那我们也没有坚守的必要了。除非公司跟不上时代，否则还是早放弃的好。
在 stackoverflow 上 Create MSI or setup project with Visual Studio 2012 说了同一件事情。好在 InstallShield LE 太难用，最关键的是在对 ActiveX 控件、Windows services的支持上有 硬伤，事情出现 转机，Visual Studio Installer 通过扩展的形式重新回到 VS 中，不过貌似只有 VS2013 和 2015 版本，但也足够了，你说呢？你要是死磕 VS2012，何必呢