衛星アセンブリのターゲットフレームワークバージョンを決定するものは何ですか？
ログファイルを見ると、ResGen.exeとAl.exeを実行して衛星アセンブリが構築されていることがわかりますが、結果のアセンブリのターゲットフレームワークを決定するものがわかりません。
バックグラウンド
サテライトアセンブリをビルドサーバーでビルドすると.NET4.0ランタイムがターゲットになり、開発用コンピューターでコンパイルすると.NET2.0ランタイムがターゲットになるという問題を解決しようとしています。ソリューションの残りの部分は.NET2.0ランタイムを対象としており、実行可能ファイルが.NET 4.0ランタイムを対象としている場合、実行可能ファイルはサテライトアセンブリをロードしません。
ビルドサーバーでmsbuildを使用してプロジェクトを「手動で」ビルドしようとしました。これにより、.NET2.0ランタイムを対象としたサテライトアセンブリも作成されます。
自動ビルドサーバーを使用してビルドすると、間違ったターゲットランタイムバージョンの4.0しか取得できません。
私はこれを追跡するために一日を過ごしましたが、私はそれを解決したと思います。はい、私は殉教者です。不幸な冒険の発見から利益を得る！
私の推測では、Windows 7.1 SDKのインストールには、追加するレジストリキーに関するバグがあるようです。一部のレジストリ値は、7.1を指す必要があるときに7.0aを指します。さらに、一部のレジストリキーの名前が正しくありません。
手動で変更した後、リソースDLLはフレームワークの適切なターゲットバージョンへのコンパイルに戻りました。x64バージョンには変更が適用されないことは間違いありません。自己責任！
ただし、個人的には、ビルドサーバーのレジストリがハッキングされていることにあまり満足していません。私のサーバービルドで実行時に他にどんな恐怖が私を待っているか誰が知っていますか。VisualStudio2010のインストールを検討しています。
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" でした。
次の 2 行を含むバッチ ファイルを作成しました。
@call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\setenv.cmd"
@C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe %*
このバッチファイルをビルドコマンドとして使用するようにサーバーを構成しました。
私のビルド サーバーは TFS ではなく Jenkins でしたが、これで問題が解決することを願っています。
自動ビルドは、MSBuild が実行されるコマンド環境をどのように設定していますか? それを理解し、同じマシンで「手動で」ビルドが成功したときにコマンド環境をセットアップする方法とどのように異なるかを確認できれば、答えが見つかる可能性があります。これらの手がかりが見つからない場合は、ビルドを診断 (/fl /flp:v=diag;logfile=build-diag.log) でログに記録し、自動ビルド ログと手動ビルド ログを比較するように設定します。