什么决定了卫星程序集的目标框架版本？
什么决定了卫星程序集的目标框架版本？
查看日志文件，我可以看到附属程序集是通过运行 ResGen.exe 和 Al.exe 构建的，但我无法找出决定生成程序集的目标框架的因素。
背景
我正在尝试解决以下问题：当我在构建服务器上构建附属程序集时，它的目标是 .NET 4.0 运行时，但当我在开发中编译它时，它的目标是 .NET 2.0 运行时电脑。该解决方案的其余部分针对 .NET 2.0 运行时，如果可执行文件针对 .NET 4.0 运行时，则不会加载附属程序集。
我尝试在构建服务器上使用 msbuild “手动”构建项目，这也会生成针对 .NET 2.0 运行时的卫星程序集。
当我使用自动构建服务器进行构建时，我只会得到错误的目标运行时版本 4.0。
What decides the target framework version of a satellite assembly?
Looking at the log file I can see the satellite assembly is build by running ResGen.exe and Al.exe but I can't find out what decides the target framework of the resulting assembly.
Background
I'm trying to resolve a problem where a satellite assembly gets targeted for the .NET 4.0 runtime when I build it on the build server but targeted for .NET 2.0 runtime when I compile it on my development computer. The rest of the solution is targeted for .NET 2.0 runtime and the executable will not load the satellite assembly if it is targeted for .NET 4.0 runtime.
I have tried building the project "manually" using msbuild on the build server which also results in a satellite assembly targeted for .NET 2.0 runtime.
I only get the wrong target runtime version of 4.0 when I build using the automated build server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我花了一整天的时间来追踪这个问题，但我想我已经解决了。是的，我是一名烈士。从不幸的冒险发现中受益！
我最好的猜测是，Windows 7.1 SDK 安装似乎在其添加的注册表项方面存在错误。某些注册表值本应指向 7.1，但却指向 7.0a。此外，某些注册表项的命名不正确。
经过一些手动更改后，我的资源 DLL 重新编译为框架的适当目标版本。我非常确定 x64 版本不会用我的更改进行修补。 使用风险自负！
不过，我个人对构建服务器的注册表被黑客入侵不太满意。谁知道在我的服务器构建运行时还有什么可怕的事情在等待着我。我正在考虑只安装 Visual Studio 2010。
I just spent the whole day tracking this down, but I think I have it solved. Yes, I am a martyr. Benefit from the findings of misfortunate adventure!
My best guess is that the Windows 7.1 SDK installation seems to have a bug in it regarding the registry keys it adds. Some of the registry values point to 7.0a when it should point to 7.1. Additionally, some of the registry keys are incorrectly named.
After some manual changes, my resource DLLs were back to compiling to the appropriate target version of the framework. I'm pretty sure an x64 version would not be patched with my changes. Use at your own risk!
I personally am not too happy with having a hacked up registry for our build server, though. Who knows what other horrors await me at runtime on my server builds. I'm considering just installing Visual Studio 2010.
今天遇到了同样的问题。原因似乎是一些必需的环境变量没有设置。
以前，我的构建服务器上的构建命令只是“C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe”，
我创建了包含两行的批处理文件：
并将服务器配置为使用此批处理文件构建命令。
我的构建服务器是 Jenkins，而不是 TFS，但我希望这也能解决您的问题。
Ran into same problem today. The reason seems to be that some required environment variables were not set.
Previously, the build command on my build server was simply "C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"
I created the batch file containing two lines:
and configured the server to use this batch file as a build command.
My build server was Jenkins, not TFS, but I hope this will solve your problem as well.
自动构建如何设置执行 MSBuild 的命令环境？如果您能弄清楚这一点，并看看它与您在同一台计算机上“手动”成功构建时设置命令环境的方式有何不同，您可能会找到答案。如果找不到这些线索，请将构建设置为使用诊断进行日志记录 (/fl /flp:v=diag;logfile=build-diag.log) 并区分自动与手动构建日志。
How is the automated build setting up the command environment where MSBuild is executed? If you can figure that out, and see how it is different from how you set up the command environment when you "manually" had a successful build on the same machine, you will likely find the answer. If you can't find these clues, set the build to log with diagnostics (/fl /flp:v=diag;logfile=build-diag.log) and diff the auto vs. manual build log.
除了约翰尼·考夫曼的回答之外，我还遇到了一个问题，即我在 HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 中有一个名为
11.0的子项。该密钥中引用了我的计算机上不存在的HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A。因此，如果 Johnny Kauffman 的答案没有帮助，请检查11.0键并考虑将其删除。In addition to Johnny Kauffman's answer, I had the problem that I had a subkey in
HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0named11.0. In this key were references toHKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0Awhich doesn't exist on my machine. So if Johnny Kauffman's answer doesn't help, check for the11.0key and consider removing it.