关于**VisualStudio**解决方案配置**Debug**和**Release**选项，还有解决方案平台

【关于VisualStudio解决方案配置Debug和Release选项，还有解决方案平台】

                  [原作者文章](http://t.csdn.cn/pTC76)

前言
1、 Debug是方便debug调试的，而Release是能优化程序运行。

2、“Debug” and “Release” are actually just two labels for a whole slew of settings that can affect your build and debugging. Debug选项和Release选项实际上是为一系列极多能影响程序的build和debugging的配置的标签/名字。（这两个配置选项的不同贯穿整个窗口，不止是优化配置不同）


3、x86/x64/AnyCPU的区别

我们使用.NET平台开发程序所构造的项目被称为“程序集”，程序集的输出类型有Windows应用程序、控制台应用程序、类库。
使用频率较高的是Windows应用程序和类库。
Windows应用程序一般包括我们常见的WinForm、WPF程序，文件格式通常为可执行文件（.exe）；
类库一般是WEB程序或动态链接库，文件格式通常为.dll。

关于x86/x64/AnyCPU之间的区别，我们就看一看exe和dll两类文件在不同平台的操作系统上运行的结果。

【Debug和Release】

Debug

Debug选项称为调试版本，顾名思义这个选项是调试的时候使用的，它包含调试信息，并且不作任何优化，便于程序员调试程序。这个选项的配置中，我们触发断点后可以通过即时/局部变量窗口来观察对应的变量，在bin\debug\目录中有两个文件，除了要生成的.exe或.dll文件外，还有.pdb文件，.pdb文件中就记录了代码中的断点等调试信息。（.PDB文件让调试器能知汇编指令与代码行数之间的对应关系）

Release

Release选项称为发布版本，Release模式下不包含调试信息，并对代码进行了优化，使得程序在代码大小和运行速度上都是最优的，\bin\release\目录下只有一个.exe或.dll文件，不会生成.PDB文件。在项目文件夹下除了bin外，还有个obj目录。编译是分模块编译的，每个模块的编译结果就保存在了obj目录下。最后会合并为一个exe或者dll文件保存到\bin\release\目录中。因为每次编译都是增量编译，也就是只重新编译改变了的模块，所以这个obj的目录的作用就是保存这些小块的编译结果，加快编译速度。

这个选项的配置使得编译器可以对我们的代码进行低等级的，复杂的优化。优化后代码可能会”面目全非“，导致单步调试变得不可行，我们也无法在变量窗口中看到变量，因为我们要观察的变量可能被优化了。

一般都是用Release来打包发布程序，另外，Release打包出来的程序也相对来说会小一些。

【x86、x64、Any CPU的区别】

原文链接
简单的说，它们之间最直接的区别就是：x86平台编译出来的exe(可执行文件)或dll(动态链接库)都是32位的。以此类推，x64对应的则是64位的。而Any CPU则是取决于当前的操作系统，若操作系统是32位的，则编译出来的程序就是32位的，反之编译出来的就是64位程序。

如：
（通用语言运行平台(Common Language Runtime,简称CLR)）

a、AnyCPU的应用程序+AnyCPU的类库

在x86的操作系统上，应用程序会在32位CLR上运行，所以它引用的类库也会在32位CLR上运行；
在x64操作系统上，应用程序许会在64位CLR上运行，所以它引用的类库也会在64为CLR上运行。

b、x86的应用程序+AnyCPU的类库

在x86的操作系统上，应用程序会在32位CLR上运行，它引用的类库也会在32位CLR上运行；
在x64的操作系统上，应用程序会在WOW下的32位CLR上运行，它引用的类库也会在WOW下的332位CLR上运行。

c、x64的应用程序+AnyCPU的类库

在x86的操作系统上，应用程序无法运行，更不要说引用类库了；
在x64的操作系统上，应用程序会在64位CLR上运行，引用的类库也会在64位CLR上运行。

d、AnyCPU的应用程序+x64的类库

在x86的操作系统上，应用程序会在32位CLR上运行，但引用的类库无法在32为CLR上运行，程序报错；
在x64的操作系统上，应用程序会在64位CLR上运行，引用的类库也会在64位CLR上运行。

e、AnyCPU的应用程序+x86的类库

在x86的操作系统上，应用程序会在32位CLR上运行，引用的类库也会在32位CLR上运行；
在x64的操作系统上，应用程序会在64位CLR上运行，但引用的类库无法在64位CLR上运行。

若你的启动项目，即主程序（编译出来是exe文件的）是x86平台下编译的，而它所依赖的一个项目（或动态链接库）是由x64位平台编译出来的，则会提示“未能加载文件或程序集…或它的某一个依赖性。试图加载格式不正确的程序。”之类的错误。这是因为32位程序不能加载64位的dll，更不能调用其中的类、方法和对象等。

反之，若主程序是由x64平台编译出来的，而dll是x86的呢？答案。。也是不行的！

说到这里，基本上可以确定一点：dll和主程序的生成平台只要一致就可以。
那么问题来了！若主程序是Any CPU编译的，而dll是由x86或者x64平台编译的，又或者，主程序是x86或者x64平台编译的，而dll是由Any CPU编译的呢？正确答案就是两者在“特殊情况”下都是可行的。为什么说是“特殊情况”下呢？

因为第一点也提到了，Any CPU取决于操作系统，而结合第二点上半部分提到的，只要dll和主程序的生成平台一致，那么也是可行的。

所以，由上可知：若主程序是在Any CPU平台下编译的，那么编译dll的平台必须要和编译主程序的操作系统一致才行。若主程序是在x86或者x64平台下编译的，那么dll就必须要和主程序一致。不过有个特例：若dll由Any CPU编译的，那么这个dll就可以被32位和64位的主程序调用。这是为什么呢？请看第三点。

虽说Any CPU编译出来的程序取决于操作系统，但是由Any CPU编译出来dll则取决于调用它的主程序，即若主程序是32位的，那么dll也是32位的，若主程序是64位的，那么dll就是64位的。

所以dll一般采用Any CPU平台编译，而主程序一般采用x86平台编译。

使用x86平台调试的时候，是可以一边调试一边修改代码的，而x64平台下则不行（启用了编辑并继续的）。

我感觉看到这里我还是觉得不是很懂，但是我应该会选择用Debug+x86去调试，最后用release+x86去打包程序，如果出现问题我再研究一下。