《VisualStudio2010中C项目升级指南》由会员分享，可在线阅读，更多相关《VisualStudio2010中C项目升级指南（9页珍藏版）》请在金锄头文库上搜索。
1、Visual Studio 2010中 C+项目升级指南 如何升级？Visual Studio 2010支持来自 VC6、Visual Studio 2002、Visual Studio 2003、Visual Studio 2005 和 Visual Studio 2008的升级。同 Visual Studio的早期版本一样，你可以选择通过 IDE的转换向导或者是命令行工具（Devenv/upgrade）来完成升级。以下是升级过程中的一些建议：1) 把升级环境与构建环境设置成相同的升级过程中会尝试加载一些文件，另外还会评估一些值。如果你的项目中所使用的值不是在项目文件中自己定义的，例如在环境
2、变量中定义的值，那就需要在升级之前事先设置好这些环境变量。如果这些环境变量设置不当，则可能会因为无法对值进行评估而出现警告或错误。2) 在升级之前确保你已经安装了必要的平台在一台没有可用平台的机器上对项目进行转换，可能会导致转换错误。例如，如果你想在 Visual Studio Professional SKU中对安腾平台的一个项目进行转换，由于它不支持安腾平台，你就会看到像下面这样的转换出错信息：1. Failed to upgrade Debug|. Please make sure you have the corresponding platform 2. installed unde
3、r %vctargetspath%platformsItanium. Cannot load the project due to a corrupt 3. project file. The following error has occurred during XML parsing: 4. File: D:SampleConsoleAppConsoleApp.vcproj 5. Line: 28 6. Column: 5 7. Error Message: 8. System error: -2147154677. 9. The file D:SampleConsoleAppConsol
4、eApp.vcproj has failed to load. 这是因为转换过程需要那些平台的属性值才能成功进行。你可以通过查看以下目录获悉已安装了哪些平台：%ProgramFiles%MSBuildMicrosoft.cppV4.0Platforms （或者查看 x64平台下的 %ProgramFiles(x86)%MSBuildMicrosoft.cppV4.0Platforms ）。3) 如果可能的话，使用本地的多定向支持来对 Visual Studio 2008工具集进行构建在 Visual Studio 2010中，我们新增了本地的多定向支持（Multi-Targeting），通过使
5、用新的基于 MSBuild的项目系统，你可以在 Visual Studio 2010的 IDE中为 Visual Studio 2008工具集构建目标。关于这一特性，你可以看看这篇博客。我们建议用户，特别是拥有大型代码库的用户，在升级时先利用这一特性在 Visual Studio 2010中构建Visual Studio 2008工具集的程序。这样，当你在升级过程中碰到问题，就可以把那些跟项目系统或构建系统相关的问题与工具的问题区别开来。这将会让你更加平滑地升级到Visual Studio 2010 工具集。一旦升级完成，属性表文件(.Visual Studio props)就会被转换成新的格
6、式(.props)。同样，项目文件（.vcproj）也会被转换为新的格式（.vcxproj）。值得注意的是，新的项目文件会与旧的项目文件同时生成。在转换过程中还产生了一种新的文件类型（.filter .vcxproj），该过滤器文件包含用来显示解决方案的资源管理器文件夹信息。该过滤器信息原本是项目文件的一部分，然而这种变化是必要的，因为只要项目文件发生变化，MSBuild就会请求重新构建。通过在一个单独的文件中保存过滤器信息，就可以在避免重新构建整个项目的情况下修改过滤器。注意：升级过程不会转换.user 文件。因此，你的调试和部署设置在转换后将不会被保留。在 Visual Studio 20
7、10中，一个新的命令行升级工具 VCUpgrade.exe 也被加入了进来。此命令行工具，适合在只有一个项目的情况下进行升级，因为它无法把解决方案文件作为输入，并将其解析成项目文件。VCUpgrade.exe 位于 $（Visual Studio InstallDir） common7 Tools 目录下，该工具也将附带在 WinSDK的下一个版本中，这样用户就可以在没有 Visual Studio IDE的情况下用命令行对 WinSDK中的项目文件进行升级。升级过程中的警告以下是转换过程中，你可能会遇到的一些常见警告：1) 链接器输出目录在升级时你可能会看到的一个警告是 MSB8012：$(
8、TargetPath)和链接器的 OutputFile属性的值不匹配：1. -MSB8012: $(TargetExt) (.dll) does not match the Linkers OutputFile 2. property value C:fooDebugMFCActiveX.ocx (.ocx) in project configuration Debug|Win32. 3. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetExt) 4
9、. property value matches the value specified in %(Link.OutputFile). 5. -MSB8012: $(TargetPath) (C:fooDebugMFCActiveX.dll) does not match the Linkers OutputFile 6. property value C:fooDebugMFCActiveX.ocx (C:fooDebugMFCActiveX.ocx) in project 7. configuration Debug|Win32. This may cause your project t
10、o build incorrectly. 8. To correct this, please make sure that $(TargetPath) property 9. value matches the value specified in %(Link.OutputFile). Link.OutputFile是在属性页中 Linker- General - Output File 这一项中定义的值。默认情况下，它的值是$（OutDir）$（TargetName）$（TargetExt），与$（TargetPath）相同。当我们把一个应用程序从之前的版本转换过来时，并没有办法可以很好
11、地解析出 Link.OutputFile被$(TargetName)和$(TargetExt)的值，因为不同的用户可能用不同的方法对其进行了赋值。为了解决这一点，我们决定在转换过程中保留Linker.OutputFile中的值。在转换之后，$（TargetName）将默认为$（ProjectName），$（TargetExt）将默认为该类应用程序的默认扩展名：动态库文件为.dll，静态库为.lib，应用程序则为.exe，而 Link.OutputFile值则将被保留。如果 Link.OutputFile与$(TargetPath)不同，警告 MSB8012会被记录在转换日志中。在构建应用程序时
12、你也会看到同样的警告。$（OutDir），$（TargetName）和$（TargetExt）在“常规”属性页中分别对应“Output Directory”，“Target Name”，“Target Extension”。你可以手动更改这些属性的值，这样你就不会再看到警告了。如果你的项目生成了导入库（Linker - Advanced - Import Library），而且链接器的输出目录不是默认目录，那么你可能还需要更改导入库的输出文件夹。否则，生成的导入库所在的目录就可能会与链接器的输出不同。调试。转换后命令被设为默认的$(TargetPath)。你可能需要做一些改动，这样当按下 F5
13、 (Debugging)或 Ctrl + F5 (Start without debugging)之后才能加载正确的可执行程序。2) 属性表的排序如果你的应用程序有属性表，那么在转换过程中你可能会遇到下面的警告中：1. -All user macros reported below for configuration Debug|Win32 are used before their definition, 2. which can cause undesirable build results; this is not supported in this release. 3. You ca
14、n resolve this by changing the inclusion order 4. of the consuming property sheets and making sure they come after the property sheets defining the user macros. 5. - MSB4211: C:fooPropertySheetfoo.props; 6. The property MyIncludePath is being set to a value for the first time, 7. but it was already
15、consumed at C:fooPropertySheetbar.props. 该警告归因于 MSBuild对其属性的评估方式：MSBuild 按顺序依次评估其属性值。如果在派生的属性表中定义的属性在父属性表中被使用，那么其值就会被设为空。然而，VCBuild采用的是延迟评估方式。这样，即使是在派生属性表中定义的属性也可以在父属性表中使用。若要解决此问题，请按照警告消息改变属性表中的顺序，从而确保属性在定义后才被使用。升级后的行为变化尽管底层的构建系统已经发生了改变，但我们仍尽力让用户在迁移到 Visual Studio 2010后有相同的使用体验。另外，我们还采取了一些措施来改进构建体验或
16、是迎合MSBuild的某些特定要求。因此，一旦你迁移到 Visual Studio 2010，就可能就会注意到以下一些变化。1) 从“解决方案依赖”到“项目到项目的引用”如果在一个旧版本 Visual Studio版本下进行编译的 C+程序被转换到 Visual Studio 2010后，解决方案级定义的项目依赖关系便会被转化成项目到项目的引用（project to project references）。这一变化确保了 C + +项目依赖关系能够在项目文件中被捕获。下面就是一个项目到项目的引用在项目文件中的样子：1. 2. 3. c58574bf-9dd8-4cf8-b5b6-6551f2f3eece 4. false 5. 6. nt
