All geek questions in one place

MSBuild Using the wrong version of sgen.exe to generate the XmlSerializer DLL?

I use TeamCity to run an MSBuild script that cleans and restores one of our solutions. When I deploy the DLL files created by this process, the web server returns an error about [MyType] .XmlSerializer.dll that "this assembly was built using a runtime that is newer than the current loaded runtime and cannot be loaded." Here are my notes:

  • The solution is a Visual Studio 2010 solution designed for the .NET Framework 3.5.
  • TeamCity is configured this way. It is configured for the version of MSBuild - ".Net Framework 4.0" and MSBuild ToolsVersion - "3.5". This means that TeamCity uses MSBuild 4.0, but targets the 3.5 Framework. Since we are using Visual Studio 2010, we must use MSBuild 4.0 or produce other errors (related to the new warning codes that VS2010 uses). It seems to work correctly and creates 3.5 DLL files for most DLLs.
  • The MSBuild process calls the resgen.exe and sgen.exe files to create resource files and XmlSerializer files, respectively. Since we are using MSBuild 4.0, it is looking for the Windows SDK 7.1. I have this version installed. I also have the Windows SDK 7.0 installed.
  • No matter what kind of framework I have, the build process is closed to sgen.exe under WinSDK 7.1 and creates .Net Framework 4.0 [MyType] .XmlSerializer.dlls. It is right?

As far as I can tell, my options are:

  • If I change things intended for older, v3.5, MSBuild tools, VS2010 puts warnings in the solution files that MSBuild 3.5 pinches and breaks the assembly. This is not an option.
  • Try changing the registry path to the tools as described in this section , I do not see any changes.
  • Install VS2010 on the server. Apparently, VS2010 used the intermediate WinSDK, v7.0A, and they are the only way to get this to install VS2010 on the server. This is not an option.
  • Modify your projects to not generate XmlSerializer.dll. This works, but it seems sticky because it does not completely fix the problem, and I am also concerned about the performance implications.

Am I missing something? Are there any other options that I missed?

+4
source share
3 answers

Try setting the SGenToolPath property to the SGen tool you want to use.

The Microsoft.Common.targets file calls the SGen task as follows:

<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>

I vaguely remember that it is necessary to do this for 64-bit assemblies. Add a comment if you have any problems.

+3
source

The Windows SDK had an unpleasant history of problems with the installer. Check this answer for the correct registry entry.

+1
source

On my machine, I found that the correct version is called C: \ Program Files (x86) \ Microsoft SDK \ Windows \ v7.0A \ bin \ sgen.exe , but the target DLL is incorrect.

The reason for this, I think, is because of my sgen.exe.config, deleting the following lines helped fix my problem.

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

Source: https://habr.com/ru/post/976913/

More articles:


All Articles