Что определяет версию целевой платформы вспомогательной сборки?

Что определяет версию целевой платформы вспомогательной сборки?

Глядя на файл журнала, я вижу, что вспомогательная сборка создается с помощью ResGen.exe и Al.exe, но я не могу выяснить, что определяет целевую структуру полученной сборки.

Фон

Я пытаюсь решить проблему, когда вспомогательная сборка становится целевой для среды выполнения .NET 4.0, когда я собираю ее на сервере сборки, но предназначена для среды выполнения .NET 2.0, когда я компилирую ее на своем компьютере для разработки. Остальная часть решения предназначена для среды выполнения .NET 2.0, и исполняемый файл не будет загружать вспомогательную сборку, если он предназначен для среды выполнения .NET 4.0.

Я попытался создать проект «вручную» с помощью msbuild на сервере сборки, что также приводит к созданию вспомогательной сборки, предназначенной для среды выполнения .NET 2.0.

Я получаю неправильную целевую версию среды выполнения 4.0 только при сборке с использованием сервера автоматической сборки.


person Magnus Lindhe    schedule 23.05.2011    source источник


Ответы (4)


Я только что провел целый день, отслеживая это, но я думаю, что решил это. Да, я мученик. Воспользуйтесь результатами злополучного приключения!

Я думаю, что в установке 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)"
person Johnny Kauffman    schedule 09.06.2011
comment
Ваш обходной путь сработал для меня. Существует аналогичный официальный обходной путь, опубликованный в Microsoft Connect. Он не включает изменения с версии 7.0A на версию 7.1 для MSBuild. Эти изменения были необходимы, чтобы заставить его работать на моей сборочной машине. Большое спасибо! - person Magnus Lindhe; 15.06.2011
comment
Я могу подтвердить, что это устраняет проблему (или, по крайней мере, для меня). По какой-то причине все, кроме последнего редактирования - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 - уже были сделаны, поэтому мне просто нужно было закончить остальные и бум, все мои вспомогательные сборки теперь хорошо работают с моим приложением. - person CLR; 01.02.2012
comment
Работал как шарм. Мне пришлось добавить те же правила для узла Wow3264Node в моей системе, но после этого моя сборка снова нацелилась на правильный фреймворк. - person Jensen; 09.10.2012

Сегодня столкнулся с такой же проблемой. Причина, по-видимому, в том, что некоторые необходимые переменные среды не были установлены.

Раньше команда сборки на моем сервере сборки была просто «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, но я надеюсь, что это решит и вашу проблему.

person IMil    schedule 08.06.2011

Как автоматическая сборка настраивает командную среду, в которой выполняется MSBuild? Если вы сможете понять это и увидеть, чем это отличается от того, как вы настроили командную среду, когда у вас «вручную» была успешная сборка на той же машине, вы, вероятно, найдете ответ. Если вы не можете найти эти подсказки, задайте для сборки журнал с диагностикой (/fl /flp:v=diag;logfile=build-diag.log) и сравните журнал автоматической и ручной сборки.

person Brian Kretzler    schedule 23.05.2011

В дополнение к ответу Джонни Кауфмана у меня возникла проблема с тем, что у меня был подраздел в HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0 с именем 11.0. В этом ключе были ссылки на HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A, которого нет на моей машине. Поэтому, если ответ Джонни Кауфмана не помогает, проверьте ключ 11.0 и рассмотрите возможность его удаления.

person dutop    schedule 12.08.2013