一个卫星程序集的目标框架版本是由什么决定的?

9
什么决定卫星程序集的目标框架版本?
查看日志文件,我可以看到卫星程序集是通过运行ResGen.exe和Al.exe来构建的,但我找不到决定生成程序集目标框架的原因。
背景
我正在尝试解决一个问题,即当我在构建服务器上构建卫星程序集时,它会针对.NET 4.0运行时进行目标设置,但当我在开发计算机上编译它时,它会针对.NET 2.0运行时进行目标设置。解决方案的其余部分针对.NET 2.0运行时,并且如果卫星程序集针对.NET 4.0运行时,则可执行文件将无法加载该程序集。
我已尝试在构建服务器上使用msbuild手动构建项目,这也会生成一个针对.NET 2.0运行时的卫星程序集。
只有在使用自动化构建服务器构建时,才会出现错误的目标运行时版本4.0。
4个回答

16

我整天都在追踪这个问题,但我认为我已经解决了它。是的,我是一个殉道者。从不幸的冒险中受益吧!

我猜测 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\\v7.1@InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx35Tools-x86@InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0@MSBuildToolsPath)"

你的解决方法对我很有用。在Microsoft Connect上发布了一个类似的官方解决方法。它没有包括从v7.0A到v7.1的MSBuild更改。这些更改是必要的,才能让我的构建机正常工作。非常感谢! - Magnus Lindhe
我可以确认这个修复了问题(或者至少对我有效)。由于某种原因,除了最后一个编辑 - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 - 其他都已经完成,所以我只需要完成剩下的部分,然后一切就好了,我的卫星程序集现在与我的应用程序很好地配合。 - CLR
1
运行得非常好。我确实不得不在我的系统上添加Wow3264Node的相同规则,但之后我的构建就再次针对正确的框架进行了。 - Jensen

1
今天遇到了同样的问题。原因似乎是一些必需的环境变量没有设置。
之前,我的构建服务器上的构建命令只是"C:\Windows\Microsoft.NET\Framework\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 %* 

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

我的构建服务器是 Jenkins,而不是 TFS,但我希望这也能解决您的问题。


0
自动化构建如何设置执行MSBuild的命令环境?如果您能够找出这一点,并看到它与手动在同一台机器上成功构建时设置命令环境的不同之处,您很可能会找到答案。如果您找不到这些线索,请将构建设置为使用诊断记录(/fl /flp:v=diag;logfile=build-diag.log),并比较自动和手动构建日志。

0
除了 Johnny Kauffman 的回答之外,我还遇到了一个问题,就是在 HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 下有一个名为 11.0 的子键。在这个键中引用了 HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A,但我的计算机上不存在这个路径。因此,如果 Johnny Kauffman 的回答没有帮助,请检查 11.0 键,并考虑将其删除。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接