MSBuild Использование неверной версии sgen.exe для создания DLL-файлов XmlSerializer?

Question

Я использую TeamCity для запуска сценария MSBuild, который очищает и перестраивает одно из наших решений. При развертывании библиотек, созданных этим процессом, веб-сервер возвращает ошибку о [MyType] .XmlSerializer.dll, что «эта сборка построена в среде выполнения, более новой, чем текущая загруженная среда выполнения, и не может быть загружена». Вот мои заметки:

• Решение представляет собой решение Visual Studio 2010, предназначенное для .Net Framework 3.5.
• TeamCity настроен подражать этому. Он настроен с версией MSBuild - «.Net Framework 4.0» и MSBuild ToolsVersion - «3.5». Это говорит TeamCity использовать MSBuild 4.0, но нацеливаться на 3.5 Framework. Поскольку мы используем Visual Studio 2010, мы должны использовать MSBuild 4.0, иначе он выдаст другие ошибки (связанные с новыми кодами предупреждений, которые использует VS2010). Похоже, что он работает правильно и создает библиотеки DLL .Net 3.5 для большинства библиотек.
• Процесс MSBuild вызывает resgen.exe и sgen.exe для создания файлов ресурсов и файлов XmlSerializer соответственно. Поскольку мы используем MSBuild 4.0, он ищет Windows SDK 7.1. У меня установлена ​​эта версия. У меня также установлен Windows SDK 7.0.
• Независимо от того, что у меня есть рамки целевой, процесс сборки остановился в sgen.exe под WinSDK 7.1 и производит .Net Framework 4.0 [MyType] .XmlSerializer.dlls. Это правильно?

Насколько я могу судить, я могу:

• Если я изменю настройки на более старые, v3.5, инструменты MSBuild, VS2010 поместит предупреждения в файлы решений, что MSBuild 3.5 блокирует сборку и нарушает ее сборку. Это не совсем вариант.
• Попробуйте изменить путь в реестре до инструментов , как обсуждено в этой теме , я не вижу изменений.
• Установить VS2010 на сервере. По всей видимости, VS2010 использовал промежуточный WinSDK, v7.0A, и единственный способ получить это - установить VS2010 на сервер. Это не совсем вариант.
• Измените проекты, чтобы они не генерировали XmlSerializer.dll. Это работает, но кажется липким, так как это не решает проблему, и я также беспокоюсь о влиянии на производительность.

Я что-то упустил? Есть ли другие варианты, которые я пропустил?

Answer 1

Попробуйте установить свойство SGenToolPath для инструмента SGen, который вы хотите использовать.

Файл Microsoft.Common.targets вызывает задачу SGen следующим образом:

    <SGen
        BuildAssemblyName="$(TargetFileName)"
        BuildAssemblyPath="$(IntermediateOutputPath)"
        References="@(ReferencePath)"
        ShouldGenerateSerializer="$(SGenShouldGenerateSerializer)"
        UseProxyTypes="$(SGenUseProxyTypes)"
        KeyContainer="$(KeyContainerName)"
        KeyFile="$(KeyOriginatorFile)"
        DelaySign="$(DelaySign)"
        **ToolPath="$(SGenToolPath)"**
        SdkToolsPath="$(TargetFrameworkSDKToolsDirectory)"
        EnvironmentVariables="$(SGenEnvironment)"
        SerializationAssembly="$(IntermediateOutputPath)$(_SGenDllName)"
        Platform="$(SGenPlatformTarget)"
        Types="$(SGenSerializationTypes)">

    <Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly"/>

  </SGen>

Я смутно помню, что делал это для 64-битных сборок. Добавьте комментарий, если у вас есть какие-либо проблемы.

Answer 2

Windows SDK имеют неприятную историю проблем с установщиком. Проверьте этот ответ на правильность записи реестра.

Answer 3

На моей машине я обнаружил, что правильная версия называется C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v7.0A \ bin \ sgen.exe , но неверные целевые DLL.

Причина этого, по-моему, связана с моим sgen.exe.config, удаление следующих строк помогло решить мою проблему.

<startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0"/>
        <supportedRuntime version="v2.0.50727"/>
    </startup>