C#基础教程（十三) VS平台与目标平台

平时开发C#时候，经常会遇到这个错误，其他信息: 未能加载文件或程序集"32BitLib， Version=1.0.0.0， Culture=neutral，PublicKeyToken=null"或它的某一个依赖项。试图加载格式不正确的程序，由此拉开程序集多少位大幕。

(一) bit位查看

要查看多少位程序集，可以利用VS2013 开发人员命令提示，打开这个.bat，可以发现里面配了很多环境路径，无非里面有一些.exe，用命令行启动程序而已。查看c#程序集dll，用一个corflagse.xe工具，在开发人员命令提示中输入指令是corflags。PE32是32bit，PE32+是64bit。

corflags是.NET提供的工具，C++显然不能用这个，C++用的是dumpbin.exe，输入指令dumpbin /headers。

(二) 配置管理器和平台

       在C++配置管理是决定C++多少位dll或exe，跟C#不一样，C#的配置管理器下面讲。C++工程属性配置界面：

 如果要改变dll位数，直接下拉选没有用的，关闭再进入属性>配置看，根被没改变，能改变的地方在配置管理器，点击：

       活动解决方案平台是添加所有"平台"（x86，x64，anycpu。。）的地方，这个地方是决定位数的地方吗？不是。项目上下文才是决定每个dll或exe多少位的地方，可以新增但不能增加和活动解决方案平台一样的方案，否则会报：

       但你可以把活动解决方案平台里的删掉再在项目上下文方案配置里每个项目中平台新建。也不是说什么项目上下文都提供x86，x64，anycpu，arm。。"平台"选项，看什么工程，C++肯定没有anycpu，C#可以，C#有中间语言（MCIL），可以根据不同系统来运行。又比如C#肯定不支持amr平台。

       再讲讲C#工程，配置管理器跟C++不同，在这：

       生成里的改平台没有用，跟C++一样，得去配置管理器改：

       是不是很相似，是一样的，跟C++，新增规则也一样的，那么在C#中，这里并不是决定dll（exe）多少bit的地方，要这个干嘛？我能领略到微软如此设计有什么意图。不管是C++还是C#，项目上下文"平台"也决定了debug文件名，比如选x64，编译生成的文件默认肯定在x64/debug下，这样我们就可以清晰知道该dll或者exe是多少位，不必再用工去查看，不会乱掉。那么C#还有个生成目标anycpu，这个属于什么文件夹?就debug，x86x64都是有对应文件夹的。当然你不能把目标平台改成x64，平台定成x32，可以生成x64/debug/32位dll，但时间一长或者别人根本不知道。所以一般你看好了，目标平台和项目上下文"平台"选择是联动的，就怕弄混乱。

      就我目前观察，平台确实没什么用，只跟输出路径联动，只起到文件分类不乱的效果。 

(三) 目标平台

       C#工程有这个目标平台，这个平台是决定C#生成是多少位dll，跟C++不一样。目标有x86，x64，anycpu。x86：32位系统运行，x64：64位系统运行，anycpu可以任何平台跑，在多少位系统就是多少位程序。所以anycpu非常要非常谨慎，比如引用了32bit的dll，主程序是anycpu，在32位系统可以跑，到64位机器上就跑不起来了，发生不同程序集引用的那个模块就报错。目标平台下有个首选32，那么编译出来的是纯32程序，不存在自适应平台之说。

(四) 32/64位系统与system，System32，SystemWow64

       32位系统只有System和System32两个系统文件夹，System是16bit组件集合，System32是32bit组件集合。64位系统有System32和SystemWow64，64bit组件放于System32文件夹中，32bit放在SystemWow64中（创建子系统32环境给32位程序运行），而微软为了保障兼容性，所以无论是32位还是64位的DLL文件都是放到了System32文件夹中。