SGEN: An attempt was made to load an assembly with the wrong format

Question

I have a project that can work fine on my local computer, however, when I get TFS to create it, I get the following error:

SGEN: An attempt was made to load an assembly with the wrong format:

After reading many other posts here in this thread, most people just say that I need to change the build type to x86 or Any CPU, and not to x64, but after trying countless combinations, this was not a solution. My program is also a Windows service, so setting up an application pool for 32-bit applications (as others suggest) is also not a solution.

Answer 1

My problem was finally resolved on this page - http://aplocher.wordpress.com/2012/10/12/sgen-an-attempt-was-made-to-load-an-assembly-with-an-incorrect-format -tfs-2010 /

Just in case this page ever disappears in the future, follow these steps:

• In Team Explorer, right-click on the assembly definition and select Open Process File Location
• Double click on the selected XAML file
• In the designer, select a container called Sequence (this is a top-level container that will bypass everything else).
• In the Arguments list (usually below), change the MSBuildPlatform from Microsoft.TeamFoundation.Build.Workflow.Activities.ToolPlatform.Auto to Microsoft.TeamFoundation.Build.Workflow.Activities.ToolPlatform.X86.
• Save and close the file.
• Check the file back to TFS and try again.

Answer 2

The problem disappears after installing the latest Windows SDK , which includes the 64-bit version of sgen.exe:

http://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx

Sometimes (if this does not help) an older version helps:

http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx

For some reason, the 64-bit version of sgen is not included in Microsoft Build Tools

Answer 3

I encountered the same error when I tried to compile my project (the target platform of the platform is installed in x86) in Release. It compiles fine in Debug. I came to find out that serialization build starts in Release; therefore, calling the SGen utility. The problem was that MSBuild called the x64 version of SGen against my x86 EXE, which generated an error. I had to pass this argument to MSBuild so that MSBuild would use the correct version of SGen:

/p:SGenToolPath="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools" 

Answer 4

I found this question relevant: https://github.com/dotnet/sdk/issues/1630

Pending fix in the next version, I was able to solve this problem by adding two goals to the csproj file, as suggested by https://github.com/joperezr :

 <Target Name="RemoveDesignTimeFacadesBeforeSGen" BeforeTargets="GenerateSerializationAssemblies"> <ItemGroup> <ReferencePath Remove="@(_DesignTimeFacadeAssemblies_Names->'%(OriginalIdentity)')" /> </ItemGroup> <Message Importance="normal" Text="Removing DesignTimeFacades from ReferencePath before running SGen." /> </Target> <Target Name="ReAddDesignTimeFacadesBeforeSGen" AfterTargets="GenerateSerializationAssemblies"> <ItemGroup> <ReferencePath Include="@(_DesignTimeFacadeAssemblies_Names->'%(OriginalIdentity)')" /> </ItemGroup> <Message Importance="normal" Text="Adding back DesignTimeFacades from ReferencePath now that SGen has run." /> </Target> 

Answer 5

In my case, this error occurred due to an invalid combination of x86 / x64 settings, but because of an attempt to create a project focused on a specific version of the .NET framework (v4.5.1), whose referenced assemblies were not installed on the assembly server.

A combination of the following two conditions was responsible for the error:

• In Visual Studio, on the "Project Properties" page on the "Application" tab in the "Target Structure", ".NET Framework 4.5.1" was installed;
• On the build server in the folder C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework folder named v4.5.1 was missing. (Other folders with version numbers, including v3.5, v4.0, and v4.5, were present.)

The fix was to install the Windows Development Kit (SDK) for Windows 8.1 on the build server. In the installation wizard, in the "Select the features you want to install" step, I unchecked the boxes without any except one for the ".NET Framework 4.5.1 Software Development Kit".

Starting this installation caused the v4.5.1 folder to disappear in the Reference Assemblies \ Microsoft \ Framework.NETFramework folder and the assembly to run successfully.

Answer 6

I had the same problem and looking at the output screen gave me more details. From this, I found that the Target Framework was higher than what was allowed for this type of project (I built the SQL Server CLR project). The target structure of the project was set to 4.0. Changing this question to 3.5 fixed the problem for me.

Dave

Answer 7

I upgraded the project from 4.0 to 4.5.2 and installed the Microsoft.NET Framework 4.5.2 Developer Pack on the build server. After that, it worked. You have a developer package for all other versions of .net.

https://support.microsoft.com/en-us/help/2901951/the-microsoft--net-framework-4-5-2-developer-pack-for-windows-server-2

Answer 8

I had a similar problem: I saw the SGEN error "wrong format" when building in VS or MSBuild from the command line. My x64 project, but MSBuild insisted on using the 32-bit version of the tool. (Some of my colleagues are working on this, gathering in VS 2015, but I only have VS 2017 installed, and I want to keep it that way.)

Looking at the output of the diagnostic assembly, it seems that SGEN is working from a directory named by its SdkToolsPath parameter (for me: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\ ). This is assigned from TargetFrameworkSDKToolsDirectory. Looking at the target files, this comes from the SDK40ToolsPath. And this is installed from the MSBuild.config file.

I solved this problem by editing C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe.config (requires administrator privilege) by setting the SDK40ToolsPath property using

 <property name="SDK40ToolsPath" value="$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools-x64', 'InstallationFolder', null, RegistryView.Registry32))" /> 

(Note: If you are looking for this path in the registry on a 64-bit OS, go to HKLM \ SOFTWARE \ WOW6432Node \ Microsoft ...)

The main change, of course, from x86 to x64 is the use of 64-bit tools. I also changed the structure to what we use (4.6.2). This may mean that we can reliably use the tools only for 64-bit projects and for this environment, taking into account this change. However, I hope this can help someone encounter this problem. (I'm shocked and alarmed. MSBuild does not automatically change the path of tools based on Framework & Architecture.)

Answer 9

We had this error, and the only thing that worked was to start with a new clone of our source code in a new folder, after aligning all our projects with AnyCPU (one was installed on x64). Aligning this so that they were all AnyCPUs, could not cope with the task on their own.

We think that somewhere on our build machines .Net or Visual Studio cached a different version / format of System.Buffers.dll for one of our projects that we could not clean up. Making a clean copy of our codebase seemed to get around this.

Answer 10

In my case, the solution compiled correctly in Debug, but there was a Release error in only one project.

Using this https://social.msdn.microsoft.com/Forums/en-US/13d3cc7a-88dc-476c-8a15-fa2d4c59e5aa/sgen-an-attempt-was-made-to-load-an-assembly-with- an incorrect format? forum = netfx64bit , I changed the PlatformTarget project, which was with x86 problems for any processor.

I supported the solution using the Mixed Platform, and it could be compiled in Release