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

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

В моем файле проекта у меня есть настраиваемая задача для запуска 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?

Здесь есть аналогичный вопрос , но мне это не очень помогает.

Ответ 1

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

На моей машине это находится в: C:\Program Files (x86)\Microsoft SDK\Windows\v7.0A\Bin

Я изменил атрибут ToolPath следующим образом:

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

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

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

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

Ответ 2

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

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

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

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

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

Если вы посмотрите на этот ключ в реестре, вы увидите, что он псевдонизирует другое значение реестра, например. "$ (Реестр: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDK\Windows\v7.1\WinSDK-NetFx35Tools-x86 @InstallationFolder)" Вскоре после этого вы, вероятно, увидите результат "NAME NOT FOUND". Если вы посмотрите, где должен быть ожидаемый ключ, вы увидите, что они не соответствуют запрашиваемому ключу (отсутствуют дефисы и, возможно, нет ключа, заканчивающегося на "-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

Ответ 3

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

<SGenToolPath>C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin</SGenToolPath>

Ответ 4

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

Ответ 5

Задача $(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"/>