什么决定卫星组件的目标框架版本？

查看日志文件我可以看到卫星程序集是通过运行ResGen.exe和Al.exe生成的，但是我找不到决定生成程序集目标框架的内容。

背景

我试图解决其中一个卫星装配被定位为构建服务器上，当我建立它在.NET 4.0运行时，但针对.NET 2.0运行时，当我编译问题在我的开发电脑上。该解决方案的其余部分针对.NET 2.0运行时，如果目标是.NET 4.0运行时，可执行文件将不会加载卫星程序集。

我已经尝试在构建服务器上使用msbuild“手动”构建项目，这也会导致针对.NET 2.0运行时的卫星程序集。

当我使用自动构建服务器构建时，我只会得到错误的目标运行时版本4.0。

来源

2011-05-23 Magnus Lindhe

我只是花了整整一天的时间跟踪这件事，但我想我已经解决了。是的，我是烈士。受益于不幸冒险的发现！

我最好的猜测是Windows 7.1 SDK安装似乎有一个关于它添加的注册表项的错误。某些注册表值指向7.0a应该指向7.1。此外，一些注册表项被错误地命名。

经过一些手动更改后，我的资源DLL重新编译为适当的目标版本的框架。我敢肯定，一个x64版本将不是与我的更改修补。 使用需要您自担风险！

虽然我个人不太乐意为我们的构建服务器破解注册表。谁知道在我的服务器版本上运行时有什么其他的恐惧等待着我。我正在考虑只安装Visual Studio 2010。

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools] 
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\bin\\" 
"ProductVersion"="7.1.7600.0.30514" 
"ComponentName"="Microsoft Windows SDK NetFx 3.5 Tools" 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools\1033] 
"SP"=dword:00000000 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86] 
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\bin\\" 
"ProductVersion"="7.1.7600.0.30514" 
"ComponentName"="Microsoft Windows SDK NetFx 3.5 Tools" 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86\1033] 
"SP"=dword:00000000 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0] 
"MSBuildToolsPath"="c:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\" 
"MSBuildToolsRoot"="c:\\WINDOWS\\Microsoft.NET\\Framework\\" 
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\[email protected])" 
"MSBuildRuntimeVersion"="4.0.30319" 
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\[email protected])" 
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\[email protected])" 
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\[email protected])"

来源

2011-06-09 23:02:20

您的解决方法确实对我有用。有一个类似的官方[解决方法]（http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3 -5-generated-wrong-embedded-resources）发布在Microsoft Connect上。它不包括对于MSBuild v7.0A到v7.1的更改。这些更改对于让它在我的构建机器上运行是必需的。非常感谢！ – 2011-06-15 08:17:26

我可以证实这可以解决这个问题（或者至少对我来说）。出于某种原因，除了最后一次编辑 - HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 - 都已经完成了，所以我只需要完成剩下的工作和繁荣，我所有的卫星程序集现在都可以和我的应用程序一起玩。 – CLR 2012-02-01 18:29:01

工作就像一个魅力。我不得不在我的系统上为Wow3264Node添加相同的规则，但在此之后，我的构建再次瞄准了正确的框架。 – Jensen 2012-10-09 13:21:17

自动化版本如何设置执行MSBuild的命令环境？如果你能弄明白这一点，并且看看当你手动在同一台机器上成功构建时，它与你如何设置命令环境有所不同，你很可能会找到答案。如果找不到这些线索，请将该版本设置为使用诊断程序（/ fl/flp:v=diag; logfile=build-diag.log）进行日志记录，并区分自动与手动构建日志。

来源

2011-05-23 14:54:09

今天遇到同样的问题。原因似乎是没有设置一些必需的环境变量。

以前，我的生成服务器上生成命令是简单的 “C：\ WINDOWS \ Microsoft.NET \框架\ v4.0.30319 \ msbuild.exe”

我创建了一个包含两行的批处理文件：

@call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\setenv.cmd" 
@C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe %*

并将服务器配置为使用该批处理文件作为构建命令。

我的构建服务器是詹金斯，而不是TFS，但我希望这也能解决您的问题。

来源

2011-06-08 12:36:08 IMil

除了约翰尼·考夫曼的回答，我有我在HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0一个子项名为11.0问题。在这个键里面是对我的机器上不存在的HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A的引用。所以，如果约翰尼考夫曼的答案没有帮助，请检查11.0密钥，并考虑删除它。

来源

2013-08-12 06:57:05 dutop

什么决定卫星组件的目标框架版本？

回答

相关问题