Как установить траекторию SGEN в Msbuild для целевой платформы 3.5 - PullRequest
Новая
       61

Как установить траекторию SGEN в Msbuild для целевой платформы 3.5

17 голосов
/ 01 мая 2010

Я только что обновил проект с VS2008 до VS2010, но я все еще ориентируюсь на 3.5 framework.

В моем файле проекта у меня есть пользовательское задание для запуска SGEN для генерации моего XmlSerializers.dll.Однако используемая версия sgen предназначена для платформы 4.0.В результате, когда я запускаю свое приложение, я получаю сообщение об ошибке:

«Не удалось загрузить файл или сборку« XXXX.XXXX.XmlSerializers »или одну из ее зависимостей. Эта сборка создается средой выполнения, более новой, чемтекущая загруженная среда выполнения, которую нельзя загрузить. "

Задача Sgen выглядит следующим образом: 

  <Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
    <!-- Delete the file because I can't figure out how to force the SGen task. -->
    <Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
    <SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
      <Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
    </SGen>
  </Target>

Это ToolPath =" $ (SGenToolPath) ".Как мне заставить его работать с версией, нацеленной на 3.5?

Есть похожий вопрос здесь , но мне это мало помогает.

Ответы [ 5 ]

18 голосов
/ 02 мая 2010

Я решил эту проблему, вручную настроив ToolPath так, чтобы он указывал на старую (версия 2.0.50727.3038) версию sgen.exe

На моем компьютере это находится в: C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v7.0A \ Bin

Я изменил атрибут ToolPath на: 

ToolPath="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"

и это решило проблему.

Кажется, по умолчанию он запускает новую версию фреймворка 4.0 в: C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v7.0A \ Bin \ NETFX 4.0 Tools

Надеюсь, это поможет кому-то еще.

16 голосов
/ 18 апреля 2011

MSBuild использует реестр, чтобы получить путь к инструментам v3.5. Задачи MSBuild, для которых требуются инструменты SDK версии 3.5, вернутся к пути версии 4.0, если путь к инструментам версии 3.5 не могут быть идентифицированы - посмотрите на логику, используемую для установки свойства TargetFrameworkSDKToolsDirectory в C: \ Windows \ Microsoft. NET \ Framework \ v4.0.30319 \ Microsoft.NETFramework.props, если вы действительно заинтересованы.

Вы можете диагностировать и устранить эту проблему следующим образом:

Установите Process Monitor и настройте фильтр для мониторинга доступа к реестру с помощью msbuild (Класс события: Registry, Имя процесса: msbuild.exe, все типы результатов).

Запустите сборку.

Монитор процесса поиска для доступа RegQueryValue, совпадающего с "MSBuild \ ToolsVersions \ 4.0 \ SDK35ToolsPath". Обратите внимание, что это может быть либо «HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft», либо «HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft».

Если вы посмотрите на этот ключ в реестре, вы увидите, что он псевдоним другого значения реестра, например, "$ (Реестр: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.1 \ WinSDK-NetFx35Tools-x86 @ InstallationFolder)" Вскоре после этого вы, вероятно, увидите результат «ИМЯ НЕ НАЙДЕНО». Если вы посмотрите, где должен быть ожидаемый ключ, вы увидите, что он не соответствует запрашиваемому ключу (отсутствуют дефисы и, возможно, нет ключа, заканчивающегося на «-86»).

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

Одной из причин неправильных записей реестра может быть ошибка при установке Microsoft SDK v7.1:

http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedded-resources

7 голосов
/ 15 декабря 2010

Я нашел, что это самый простой способ, и он работает с: On 

<SGenToolPath>C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin</SGenToolPath>
5 голосов
/ 30 июня 2010

@ Craig - Вы вручную устанавливали фреймворк 7.0A на свой компьютер.Если это так, ваша проблема может быть в настройках реестра, а не в msbuild.Посмотрите на LocalMachine -> Программное обеспечение -> Microsoft -> MSBuild -> ToolsVersions -> 4.0 -> SDK35ToolsPath и убедитесь, что ключ reg, на который есть ссылка, действителен.(Подсказка: убедитесь, что -x86 существует, только если существует ключ -x86.)

4 голосов
/ 12 июля 2012

Проблема в $(SGenToolPath) не установлена ​​MSBuild.Если вы используете $(TargetFrameworkSDKToolsDirectory), он попытается определить путь на основе $(TargetFrameworkVersion).

. Полезно использовать теги для отладки в стиле printf ().Добавьте следующее временно. 

<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
  <Message Text="SGenPath: $(SGenPath)" Importance="high"/>
  <Message Text="TargetFrameworkVersion: $(TargetFrameworkVersion)" Importance="high"/>
  <Message Text="TargetFrameworkSDKToolsDirectory : $(TargetFrameworkSDKToolsDirectory )" Importance="high"/>
...