C++和.Net程序采用了两种不同的编译方式。通常一个C++编写的程序，都是一次编译成二进制的代码，在相应的操作系统平台上直接执行即可。而.Net程序采用两次编译的方式，用C#，VB.Net等语言写成的程序被编译成IL代码，通过CLR在运行的时候JIT编译成为本地二进制代码。
沁阳网站制作公司哪家好，找创新互联公司！从网页设计、网站建设、微信开发、APP开发、响应式网站等网站项目制作，到程序开发，运营维护。创新互联公司于2013年开始到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联公司。
MFC和WinForm很多设计上的不同从根本上说，都是因为编译模式带来的不同。因此，在仔细探讨MFC和WinForm之前，有必要细细体会一下不同编译方式带来的改变。
考虑一段代码，它需要在不同的编译环境下生成不同的代码，或者是为了减少代码编写量用一些替换方式取代类似的代码。在C++中利用预编译和宏来解决这些事情。MFC框架中，更是大量使用宏来进行核心功能的设计。但是宏只是一种巧妙的减少输入代码量的方式，本质上和手写输入一些代码并无区别（也许不够严密吧），它并不能在程序运行的时候动态支持代码的插入和改变，因为此时它已经编译完成了。而二次编译则不同，你可以将它的第一次编译看成是通常一次编译程序的预编译期，只是这个预编译更为的强大，它可以编译生成信息更为丰富的元数据。并且，只要在JIT执行前动态插入代码，利用反射等手段，就可以将已经编译好的程序的行为在某种程度上进行改变，其动态性能得到了本质上的改变。
因此，在MFC和WinForm中，我们可以看到两者在动态性能，安全性和效率方面都有很大的不同，总结一下，都可以归结到这不同的编译模式上来。在以后的日志中，都可以看到这些区别的
没有差异。
所有的 .net软件，最终都会被编译成 中间代码。这个中间代码是通用的。同样的一个操作，比如从数据库中提取数据。中间代码基本上是一致的。
只是在编译之前。有不同的预编译，就是对代码进行识别与优化。这个要花不同的时间。
相对而言vb.net更随意一点。所以在预编译上，理论上说，应该要花费更多的时间。
.NET里默认是有预编译头的，也就是stdafx.h，在建项目时不选预编译头就可以了。对于已建好的项目，选择项目菜单下的属性，在C/C++下的预编译头里，创建使用预编译头选成不使用预编译头，就能像原来那样使用了。
这里的vb指vb6还是vb.net，你是问语法还是转码后的图片
vb.net和c#都会预编译程clr文件，双击exe执行的其实是clr，没有任何区别
看到你这个问题，我也茫然，然后马上百度。。。
下面是copy过来的
命令行参数应用例子，原帖地址：
'添加窗体Form1,然后添加如下代码:
Private Declare Function mciSendString Lib "winmm.dll" Alias "mciSendStringA" (ByVal lpstrCommand As String, ByVal lpstrReturnString As String, ByVal uReturnLength As Long, ByVal hwndCallback As Long) As Long
Private Sub Form_Load()
Select Case Left(Command, 2)
Case "/o" '表示open，打开光驱
mciSendString "Set CDAudio Door Open Wait", 0, 0, 0
Case "/c" '表示close，关闭光驱（答者：这个要是台式才行，我的本本测试的时候不行）
mciSendString "Set CDAudio Door Closed Wait", 0, 0, 0
End Select
Unload Me
End Sub
将上面的编译成test.exe，放到c:\下，然后打开命令提示符窗口，敲入c:\test.exe /o看看，是不是打开光驱了看再试试c:\test.exe /c
条件编译参数，原帖地址：
VB中的条件编译是经常被忽略的一个功能，它允许编译最终代码中的一部分。允许我们更好的控制我们的应用程序哪些功能在客户机上运行。比如一个应用程序有两个版本：实际发行的版本和用于调试的版本（或者完全版和演示版）。不同的版本用于不同的操作系统和国家地区。
当你使用了条件编译功能实际上是编译了源代码的两个不同部分。缺点是如果更换版本必须重新编译一次，此时如果用户需要更换版本就必须重新提供一套相应的版本。因此演示版本内部并不包含完全版中的某些代码。
用关键字逗#地来实现条件编译，下面用一个实际例子（调试版本）来说明：
在声明部分用#Const声明一个常量。
#Const DebugVer = True
那么，接下来就在可以在你的代码中这样写：
#If DebugVer = True Then
Msgbox "This is the Debug Version Please Report any Messages"
#End If
那么任何位于 #IF… #End IF之间的代码将被编译到最终的EXE文件中，因为你上边定义的条件常量DebugVer的值为true。 如果将DebugVer的值改为false，那么编译工程时将不会编译包含在#IF… #End IF之间的代码。
这里的条件常量不一定非要是布尔类型的常量，可以象使用其他常量一样使用这个常量，但是注意它是常量，每次运行它只能是一个值。
VB中可以用几个预编译指令： #Const、#If .Then ...#ElseIf.Then...#Else...#End If
#Const 声明一个常量，相当于宏定义，用#Const定义的只能被当前模块识别。例如定义常 DebugVer =1，标明是调试版本：
#Const DebugVer = 1
然后，数据库连接串写成
#If DebugVer = 1 Then '或者是#If DebugVer Then VB和C、C++也一样，非零为真
connStr = "Provider=OraOLEDB.Oracle;Data Source=Fraud-Test;User Id=Unmi;Password=testpwd;"
#Else
connStr = "Provider=OraOLEDB.Oracle;Data Source=Fraud;User Id=user;Password=pwd";
#End If
要发布到正式环境时编译前只需要把 #Const DebugVer = 1 改为 #Const DebugVer = 1 就 OK 了。
朋友能看到这儿来，我可就告您了，我是不支持用 #Const来定义常量来进行条件编译，一则 #Const 只被当前模块认得，换着别地儿又要再写上，切换个编译条件得同步着改好几处，万一哪一处忘改了，可能就会生出个怪胎来；二则#Const 穿插在代码里头就不高明，切换编译条件要找代码。
虽然VB并不提供象VC和VS.NET中那样预设有 DEBUG 和 RELEASE 版，但也有Project Properties让您去设置编译条件，就在打开的Project Properties窗口的 Make 页的 Conditional Compilation Arguments中输入，比如输入 DebugVer = 1，如果要定义多个条件就用冒号隔开，如： OSVer=98 : DebugVer=1 (好象只能定义数值哦!，用#Const就没这个限制，可以是#Const OSVer=Win98, 用数字也足够表达意义)。在Project Properties中定义的编译条件是项目全局的，省了每个模块都用#Const，而且改起来也特方便，又不侵入代码。
在VC中我一般用 #ifdef DEBUG 来判断，可是在 VB 中 DEBUG 已经被占用，偶一次输入 debug_version ，然后一回车，VB把 debug_version 变成了全大写 DEBUG_VERSION, 说明 VB 认可了 DEBUG_VERSION，但并未为您预先定义好，还是需要在 Project Properties中加上 DEBUG_VERSION条件，如 DEBUG_VERSION = 1。另外，在Project Properties中定义的条件能立即被VB认出来，体现在代码自动格式化成定义的形式。
再列举一个较为完整的用法，演示依据定义编译何种平台下的二进制码：
#If OSVer = 95 Then
'WIN95 Code here
#ElseIf OSVer = 98 Then
'WIN98 Code here
#ElseIF OSVer = XP Then
'WINXP Code here
#Else
'Non-specific OS here
#End if
需要在之前用#Const或在Project Properties中定义OSVer，当然如果不定义，也不会错，编译器会认为OSVer的值为零或者是 False。
答者：看完条件编译参数，想到了不同系统应用不同的代码原来还可以这样。。。
不会的勤百度，总会找到你需要的，O(∩_∩)O~
