什么决定了附属程序集的目标框架版本？
查看日志文件，我可以看到附属程序集是通过运行 ResGen.exe 和 Al.exe 构建的，但我不知道是什么决定了生成程序集的目标框架。
背景
我正在尝试解决一个问题，即当我在构建服务器上构建卫星程序集时，它会针对 .NET 4.0 运行时，而当我在开发计算机上编译它时，它会针对 .NET 2.0 运行时。解决方案的其余部分针对 .NET 2.0 运行时，如果它针对 .NET 4.0 运行时，可执行文件将不会加载附属程序集。
我尝试在构建服务器上使用 msbuild“手动”构建项目，这也导致了针对 .NET 2.0 运行时的附属程序集。
当我使用自动构建服务器构建时，我只会得到错误的目标运行时版本 4.0。
我只是花了一整天的时间来追踪这个问题，但我想我已经解决了。是的，我是烈士。从不幸冒险的发现中受益！
我最好的猜测是，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)"
今天遇到了同样的问题。原因似乎是没有设置一些必需的环境变量。
以前，我的构建服务器上的构建命令只是“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，但我希望这也能解决您的问题。
自动构建如何设置执行 MSBuild 的命令环境？如果您能弄清楚这一点，并看看它与“手动”在同一台机器上成功构建时设置命令环境的方式有何不同，您可能会找到答案。如果找不到这些线索，请将构建设置为使用诊断记录 (/fl /flp:v=diag;logfile=build-diag.log) 并区分自动与手动构建日志。
除了 Johnny Kauffman 的回答之外，我还遇到了一个问题，即我在HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0named中有一个子项11.0。在这个键中是HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A我的机器上不存在的引用。因此，如果约翰尼考夫曼的回答没有帮助，请检查11.0密钥并考虑将其删除。