.NET 4.6.1/.NET Standard 2.0 build with SGen fails

[emmanuelguerin]

The context is a .NET Standard 2.0 targeted library Lib. It is referenced by a .NET Framework 4.6.1 targeted library LibNetFramework.
(see GitHub repository: https://github.com/emmanuelguerin/issue-sgen)

In LibNetFramework, serialization assemblies generation is forced by the use of the GenerateSerializationAssemblies property set to On. Typically, this would happen when adding a WebReference to the project.

The compilation fails with the message

SGEN : error : An attempt was made to load an assembly with an incorrect format: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\netfx.force.conflicts.dll.

The issue might have been corrected by the use of the patch in #1582, that is put ine the LibNetFrameworkPatched project in the GitHub repo.

But this breaks the build, as the netstandard.dll reference is no longer added to the compilation:

LibNetFrameworkPatched\Class1.cs(9,30,9,34): error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

You can find an appveyor build failing on the VS2017, and VS2017 preview:
https://ci.appveyor.com/project/emmanuelguerin/issue-sgen/build/1.0.6

[emmanuelguerin]

One thing that allowed me to go on, was to patch quite violently the GenerateSerializationAssemblies target with the following.

This removed the ref DLLs from the list of DLLs passed to the SGen task.

  <Target
    Name="GenerateSerializationAssemblies"
    Condition="'$(_SGenGenerateSerializationAssembliesConfig)' == 'On' or ('@(WebReferenceUrl)'!='' and '$(_SGenGenerateSerializationAssembliesConfig)' == 'Auto')"
    DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource"
    Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)"
    Outputs="$(IntermediateOutputPath)$(_SGenDllName)">

    <PropertyGroup>
      <SGenMSBuildArchitecture Condition="'$(SGenMSBuildArchitecture)' == ''">$(PlatformTargetAsMSBuildArchitecture)</SGenMSBuildArchitecture>
    </PropertyGroup>

    <PropertyGroup>
      <SGenRefDirectory>$([System.IO.Path]::GetDirectoryName('$(MicrosoftNETBuildExtensionsTargets.Substring(3))'))\net461\ref\</SGenRefDirectory>
    </PropertyGroup>
    <ItemGroup>
      <SGenReference Include="@(ReferencePath)" Condition="'%(Directory)' != '$(SGenRefDirectory)'" />
    </ItemGroup>

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

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

    </SGen>

  </Target>

[jnm2]

My company just ran into this. I'm not quite brave enough to use the workaround yet.

We don't run into this so long as we don't add a package reference to SourceLink.Embed.AllSourceFiles.

[emmanuelguerin]

I'll have to have a look again at this. The workaround is simple enough to implement: copy paste the target in the .csproj after the Import of the targets ().
https://github.com/emmanuelguerin/issue-sgen/blob/master/LibNetFrameworkPatched/LibNetFrameworkPatched.csproj

[jnm2]

I'm just afraid to entirely replace the target. I just found a workaround for my particular case which I'll post here.

[mouadhtrabelsi]

do your patch work for .NET Framework 4.7.1 ?
i added
<Target Name="ImplicitlyExpandNETStandardFacades" ..>
..
to my csproj , but did not fix the problem,

I get this error
error : An attempt was made to load an assembly with an incorrect format: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.1\Facades\System.IO.Compression.ZipFile.dll.

But i m not referincing this DLL in my project !

any help please ?

[livarcocc]

@joperezr can you take a look and comment?

[joperezr]

@mouadhtrabelsi that reference is automatically added in order to ensure compatibility between your .Net Framework component and your .Net standard one. Do you mind sharing a repro and also the version of VS that you are using so that I can provide a workaround?

[DanTup]

@joperezr There are some simple repro steps at dotnet/msbuild#2707

[tomek14]

I have the same problem as @mouadhtrabelsi, in my WebForms App targeting 4.7.1 when building Relase.

[mouadhtrabelsi]

I I got this error only in project having web service refrences
@tomek14 to fix it i disabled GenerateSerializationAssemblies
on teh csproj i added this line for all the build config
<GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>bin\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>
</PropertyGroup>

[tomek14]

@mouadhtrabelsi It worked! Thanks a lot!

[scottsauber]

I am getting this on a regular ASP.NET project when I upgraded to .NET 4.7.1 and it has references to .NET Standard 2.0 libs. Is there any official guidance on how this is going to get addressed?

I'm on the latest VS - 15.5.6

[joperezr]

I believe we do know now what is happening here. In order for SGen to work correctly on 4.7.1, it will require one of two possible solutions:

• Add binding redirects to it's config file. (This is the least invasive to your project, but it does mean modifying things inside VisualStudio installation, which might break things once you upgrade to the next version of .NET, so I would advise option 2)
• Add a couple of targets to your .csproj file to make sure we don't include the design time facades when generating the serialization assemblies. In order to go with this option, simply add the following code right before the </Project> tag.

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

[oflahero]

@joperezr 's solution (thanks Jose) worked for my Debug build, but not for Release, unfortunately.

However it builds fine in Release mode on Visual Studio Online's hosted agent, so I assume it's something to do with what's installed on your local machine.

DLL hell never really went away!

[petermorlion]

It definitely must be something machine-specific (like @oflahero states). We're having this issue on one of our team member's machines, but noone else has this problem. The solution provided by @joperezr didn't work for us.

[rfcfore]

I am still using msbuild to do my builds. The issue cropped up for us after some updates to vs2017. After reading this thread, I added '/p:GenerateSerializationAssemblies=Off' to the build script and that resolved the issue with the project that was failing. Note: this was happening on the build server, and not on the developers workstations.

[petermorlion]

@rfcfore In my case, I am working on a legacy project with lots of technical debt. I'm afraid setting the GenerateSerializationAssemblies property to Off will make the application generate them on startup time and then generate the error at that moment. Which is something I definitely want to avoid. In the end, we solved it by not having a certain .NET 4.6.2 assembly reference the .NET Standard assembly.

[DrGriff]

I'm experiencing a similar issue. Please also see my post: NuGet package (.NET Standard 2.x) breaking ASP.NET MVC5 application (.NET full framework)

[rconde01]

I found a different workaround. Call sgen manually in a post build event like this:

Sgen.exe /force "$(TargetPath)" /c:"-reference:$(TargetDir)netstandard.dll"

You also need to call vcvarsall.bat or similar first so that sgen can be found

[mattwhetton]

I'm having a similar issue to @mouadhtrabelsi - GenerateSerializationAssemblies is set to 'Auto' and therefore I only get this problem in Release builds. We're running net471 - not sure if thats

I've have tried @emmanuelguerin fix, but that didn't help (either that or I'm doing it worng - I literally just put his build target into my csproj)

I have tried @joperezr fix but again, no effect (as before, unless I'm doing it wrong).

I'm looking at setting GenerateSerializationAssemblies to false, but not sure what the wider effects will be.

Anybody got an update?

[joperezr]

@mattwhetton if your machine runs on 4.7.1 (and you have installed latest windows updates) or if you are running on 4.7.2 then you shouldn't hit this issue at all. Not on Debug builds or Release builds. Do you mind trying to update your machine to make sure you have the latest Windows Updates and trying again?

[mattwhetton]

I'm running on 4.7.1 and my updates look fairely up to date. We're seeing this issue on our build serverr too.

I'm actually working within a company network where updates are controlled by group policy, and rolled out in a very managed way. Do you have any more details on specifically which update this fix was in?

Looking at my update history, the last successful update was on 29/06/2018 which was KB2693643 and there is nothing showing as outstanding.

[joperezr]

@mattwhetton I see, I can't seem to be able to repro your issue but I'm on 4.7.2. Can you send me your OS Version and the File version of the clr.dll file that gets loaded into the process? That way I can try to set up a machine with your environment and try to get a repro there. Hopefully after that I will be able to provide either a workaround, or an Update package that you are missing.

[yyjdelete]

@joperezr

System: Win10(1809 17744 Insyder)
clr.dll:4.7.3062
dotnet sdk: 2.1.400
VS: 2017 v15.9.0-pre.1.0
Msbuild(in Developer Command Prompt of VS): 15.8.166+gd4e8d81a88
sgen: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\sgen.exe

Or you mean set TargetFramework to net472, I tried net46/net472, but it always call the sgen in NETFX 4.6.1 Tools, even if there are others.
Try remove all others Tools but still failed with net472

C:\Program Files (x86)\Microsoft Visual Studio\Preview\Community\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(3533,5): warning MSB3084: 任务尝试在两个位置查找“sgen.exe”。1) 在基于 SdkToolsPath 生成的“C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\”处理器特定目录下 2)“C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\”(由 SDKToolsPath 属性指定)下的 x86 特定目录下。可以通过执行下列操作之一来解决此问题: 1) 将“SDKToolsPath”属性设置为 Microsoft Windows SDK 的位置。 [F:\~tmp\xx\x
x.csproj]
  C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\sgen.exe /assembly:"F:\~tmp\xx\obj\Debug\net472\xx.dll" /proxytypes /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\mscorlib.dll,C:\Users\***\.nuget\packages\system.buffers\4.5.0\ref\net45\System.Buffers.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Core.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Data.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Drawing.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.IO.Compression.FileSystem.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Numerics.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Runtime.Serialization.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Xml.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Xml.Linq.dll"
  错误: 试图加载的程序集的格式不正确: C:\Users\***\.nuget\packages\system.buffers\4.5.0\ref\net45\System.Buffers.dll。
    - 未能加载文件或程序集“file:///C:\Users\***\.nuget\packages\system.buffers\4.5.0\ref\net45\System.Buffers.dll”或它的某一个依赖项  。不应出于执行的目的加载引用程序集。只能在仅限反射的加载程序上下文中加载引用程序集。 (异常来自 HRESULT:0x80131058)
    - 无法加载引用程序集来执行。
C:\Program Files (x86)\Microsoft Visual Studio\Preview\Community\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(3533,5): error MSB6006: “sgen.exe”已退出，代码为 1。 [F:\~tmp\xx\xx.csproj]

C:.
├─v10.0A
│  └─bin
│      ├─NETFX 4.6 Tools
...
│      ├─NETFX 4.6.1 Tools
│      │  ├─x64
...
│      ├─NETFX 4.6.2 Tools
│      │  ├─x64
...
│      ├─NETFX 4.7 Tools
│      │  ├─x64
...
│      ├─NETFX 4.7.1 Tools
│      │  ├─x64
...
│      └─NETFX 4.7.2 Tools
│          ├─x64
...
├─v7.0A
│  └─Bin
│      ├─x64
...
├─v8.0A
│  └─bin
│      └─NETFX 4.0 Tools
│          └─x64
...
└─v8.1A
    └─bin
        └─NETFX 4.5.1 Tools
            ├─x64
...

projects

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
    <GenerateSerializationAssemblies>on</GenerateSerializationAssemblies><!--1. Add this-->
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Buffers" Version="4.5.0" /><!--2. Add this-->
  </ItemGroup>

</Project>

[joperezr]

Or you mean set TargetFramework to net472, I tried net46/net472, but it always call the sgen in NETFX 4.6.1 Tools, even if there are others.

There is no SGen specifically for net4.7.2, what I meant is that if you were running on 4.7.2 (meaning that you have .NET Framework 4.7.2 installed on your machine) then you wouldn't hit this issue, even when running the tool which targets 4.6.1. Is it possible for you to upgrade to a newer framework in your machine and try again?

[yyjdelete]

@joperezr It's already 4.7.2 for #1630 (comment)

[joperezr]

I don't mean target .NET Framework 4.7.2, I mean you have to run on .NET Framework 4.7.2. In order to easily check which Framework you are running on (or which one is installed in your machine, simply check the following REGKEY: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\ and check which is the latest .NET Framework version listed there. Whichever is the latest, that should be the framework you are running on.

[yyjdelete]

@joperezr Yes, I have one 4.7.2 here, and one clr.dll with version 4.7.3062(already 4.7.2 rtm)
And HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Release is 461814(0x70bf6)

But according to https://blogs.msdn.microsoft.com/dotnet/2018/07/10/net-framework-4-7-2-is-available-on-windows-update-wsus-and-mu-catalog/ , seems there is still an new version of net472 with 4.7.3081. If I can found it(not found in windows update, or maybe not available for insider build and 1803 of win10) and try again later.

[theCorb1nator]

I am also having this issue with an on-prem windows 10 VSTS build agent

SGEN(0,0): Error : An attempt was made to load an assembly with an incorrect format: C:\Users\BUILD\.nuget\packages\system.memory\4.5.1\ref\netstandard2.0\System.Memory.dll.

Tried all sorts of fixes but had no luck, been trying to fix the issue for 3 days, please help

I am running on .NET 4.7.2, have installed the latest win 10 SDK

[theCorb1nator]

Heres a dump of the verbose msbuild log, tried all workarounds

Task Parameter:ShouldGenerateSerializer=True (TaskId:103) 5> Task Parameter:UseProxyTypes=True (TaskId:103) 5> Task Parameter:UseKeep=False (TaskId:103) 5> Task Parameter:SdkToolsPath=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\ (TaskId:103) 5> Task Parameter:SerializationAssembly=obj\Release\DmsControls.XmlSerializers.dll (TaskId:103) 5> C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\sgen.exe /assembly:"C:\Projects\DevOps\Navigator Devops Test\DmsControls\obj\Release\DmsControls.dll" /proxytypes /reference:"C:\Users\corbi\.nuget\packages\devexpress.data\18.1.7\lib\net40\DevExpress.Data.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.images\18.1.7\lib\net40\DevExpress.Images.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.office.core\18.1.7\lib\net40\DevExpress.Office.v18.1.Core.dll,C:\Users\corbi\.nuget\packages\devexpress.pdf.core\18.1.7\lib\net40\DevExpress.Pdf.v18.1.Core.dll,C:\Users\corbi\.nuget\packages\devexpress.pivotgrid.core\18.1.7\lib\net40\DevExpress.PivotGrid.v18.1.Core.dll,C:\Users\corbi\.nuget\packages\devexpress.printing.core\18.1.7\lib\net40\DevExpress.Printing.v18.1.Core.dll,C:\Users\corbi\.nuget\packages\devexpress.richedit.core\18.1.7\lib\net40\DevExpress.RichEdit.v18.1.Core.dll,C:\Users\corbi\.nuget\packages\devexpress.richedit.export\18.1.7\lib\net40\DevExpress.RichEdit.v18.1.Export.dll,C:\Users\corbi\.nuget\packages\devexpress.sparkline.core\18.1.7\lib\net40\DevExpress.Sparkline.v18.1.Core.dll,C:\Users\corbi\.nuget\packages\devexpress.utils\18.1.7\lib\net40\DevExpress.Utils.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraBars.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraEditors.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraGrid.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraLayout.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraNavBar.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraPivotGrid.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraPrinting.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraTreeList.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraVerticalGrid.v18.1.dll,C:\Users\corbi\.nuget\packages\devexpress.win\18.1.7\lib\net40\DevExpress.XtraWizard.v18.1.dll,C:\Projects\DevOps\Navigator Devops Test\Core\DmsEncryption.dll,C:\Projects\DevOps\Navigator Devops Test\DmsPickUtilities\bin\Release\DmsPickUtilities.dll,C:\Projects\DevOps\Navigator Devops Test\DmsServer\bin\Release\DmsServer.dll,C:\Users\corbi\.nuget\packages\easendmail\7.3.1.9\lib\net45\EASendMail45.dll,C:\Users\corbi\.nuget\packages\edtftpnet\1.2.2\lib\edtftpnet-1.2.2.dll,C:\Projects\DevOps\Navigator Devops Test\Extensions\bin\Release\Extensions.dll,C:\Users\corbi\.nuget\packages\tweetsharp-unofficial\2.3.1.2\lib\4.0\Hammock.dll,C:\Users\corbi\.nuget\packages\microsoft.extensions.dependencyinjection.abstractions\2.2.0\lib\netstandard2.0\Microsoft.Extensions.DependencyInjection.Abstractions.dll,C:\Users\corbi\.nuget\packages\microsoft.extensions.dependencyinjection\2.2.0\lib\net461\Microsoft.Extensions.DependencyInjection.dll,C:\Users\corbi\.nuget\packages\microsoft.extensions.options\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Options.dll,C:\Users\corbi\.nuget\packages\microsoft.extensions.primitives\2.2.0\lib\netstandard2.0\Microsoft.Extensions.Primitives.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\mscorlib.dll,C:\Users\corbi\.nuget\packages\navigator.plugins.authentication.oauth2\2.0.0\lib\netstandard2.0\Navigator.Plugins.Authentication.Oauth2.dll,C:\Projects\DevOps\Navigator Devops Test\NavigatorPaymentSense\bin\Release\NavigatorPaymentSense.dll,C:\Users\corbi\.nuget\packages\newtonsoft.json\11.0.2\lib\net45\Newtonsoft.Json.dll,C:\Users\corbi\.nuget\packages\system.componentmodel.annotations\4.5.0\ref\net461\System.ComponentModel.Annotations.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.ComponentModel.DataAnnotations.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Core.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Data.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Drawing.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.EnterpriseServices.dll,C:\Users\corbi\.nuget\packages\system.memory\4.5.1\ref\netstandard2.0\System.Memory.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Net.Http.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Numerics.dll,C:\Users\corbi\.nuget\packages\system.runtime.compilerservices.unsafe\4.5.1\ref\netstandard2.0\System.Runtime.CompilerServices.Unsafe.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Runtime.Remoting.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Web.Services.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Windows.Forms.dll,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Xml.dll,C:\Users\corbi\.nuget\packages\tweetsharp-unofficial\2.3.1.2\lib\4.0\TweetSharp.dll" (TaskId:103) 5> Microsoft (R) Xml Serialization support utility (TaskId:103) 5> [Microsoft (R) .NET Framework, Version 4.6.1055.0] (TaskId:103) 5> Copyright (C) Microsoft Corporation. All rights reserved. (TaskId:103) 5>SGEN : error : An attempt was made to load an assembly with an incorrect format: C:\Users\corbi\.nuget\packages\system.memory\4.5.1\ref\netstandard2.0\System.Memory.dll. 5> - Could not load file or assembly 'file:///C:\Users\corbi\.nuget\packages\system.memory\4.5.1\ref\netstandard2.0\System.Memory.dll' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) (TaskId:103)

[oflahero]

Frustrating. Are you sure all your projects are targeting 4.7.2 as well as just having it installed?

I know the Remove/ReAddDesignTimeFacadesBeforeSGen fix of joperezr's (Feb 5 above) is specifically a workaround for 4.7.1, but have you tried that too? Desperate times, etc.

[theCorb1nator]

Frustrating aint the word, starting to contemplate my career choice lol, tried all work arounds :(, no luck..
Seems to complain about the 1 reference

10> - Could not load file or assembly 'file:///C:\Users\corbi\.nuget\packages\system.memory\4.5.1\ref\netstandard2.0\System.Memory.dll' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) (TaskId:154)

[mouadhtrabelsi]

@theCorb1nator did you try to deactivate GenerateSerializationAssemblies

<GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>

from the log you sent, i think its activated

Task Parameter:ShouldGenerateSerializer=True

[theCorb1nator]

@theCorb1nator did you try to deactivate GenerateSerializationAssemblies

<GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>

from the log you sent, i think its activated

Task Parameter:ShouldGenerateSerializer=True

@mouadhtrabelsi i can confirm turning that param off the application does compile correctly. however surely this will have an affect on application performance at runtime? and possible runtime errors?

im happy for this to be a temporary solution, but is there a planned fix?

Thanks

[mouadhtrabelsi]

@theCorb1nator for sure there will be an impact on performance at runtime , but i did not get any runtime errors,
it was the only fix i found

[theCorb1nator]

@theCorb1nator for sure there will be an impact on performance at runtime , but i did not get any runtime errors,
it was the only fix i found

Okay looks like this is the only fix for now then. i dont think we do much with XmlSerializer now anyways, its predominately JSON using newtonsoft. so hopefully not too much overhead

Thanks for the help

[theCorb1nator]

looks like the issue is still open here

dotnet/msbuild#2707

[gisiona]

Dear,
It has a web application developed in C # and WebForms that was initially developed in Dot.Net 2.0 and later migrated to Dot.Net 3.5.

However, the client can migrate a build of the components to the 64-bit version, although it is somewhat exposed to some scripts.

An attempt was made to load an assembly with an incorrect format: c: \ windows \ microsoft.net \ framework \ v2.0.50727 \ System.Data.dll

Can someone please help me solve this problem definitively.

[morrisond91]

he word, starting to contemplate my career choice lol, tried all work arounds :(, no luck..
Seems to complain about the 1 reference

I love this, it happens to me all of the time, and when you get a solution you appreciate hanging in there :)

[tamlin-mike]

I have too been bitten by this (netstandard2.1 assembly, but otherwise equivalent).

It has now been over two years since this issue was opened, and not even a hint of what Microsoft is doing about this (indication is rather that Microsoft isn't doing anything about it). To put it mildly, that's absurd.

Is this the kind of quality and apathy one should now expect from Microsoft. We're talking about over two years!

Have you just given up, moved on to greener pastures, abadoning your customers? Wouldn't be the first time, but if so you could at least man up and tell us so!

off-topic, but since it seems you (Microsoft representatives) don't realize this, perhaps it can be an eye-opener:
One shouldn't have to wait two weeks for a fix for this. Two years is like you're laughingly pissing your customers in the face without even the curtesy of calling it rain.

Do you (Microsoft representatives) even realize how bad this reflects on Microsoft as a whole? Apathy like this is what makes friends tell friends to "Stay the hell away from .NET (and while at it get rid of anything Microsoft)".

Is that the message you want to send your customers? 'cause that's the message you do send them by apathy like this.

Is that the message you want Microsoft to be known for?

Is that the message you can proudly proclaim for your boss, the boss' boss, all the way up to CEO and shareholders, with a smile and completely unwarranted pride with loud a clear voice state "We don't give a fuck about neither our products nor our customers!".

(yes, I'm pissed off, and so would you be after you've went through the same shit due to this buggy crap - it's a clusterf... of such proportions we've seriously started considering porting everything to Java, just to get rid of you)

[toebens]

dotnet/msbuild#2707 (comment)

[chm-tm]

For me, a similar work around like Joses helped. I'm just temporarily removing all reference assemblies.

<Target Name="RemoveReferenceAssembliesBeforeSGen" BeforeTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <_Ref_NoSgenPaths Include="%(ReferencePath.Identity)" Condition="@(ReferencePath->Contains('\ref\'))"/>
    <ReferencePath Remove="%(ReferencePath.Identity)" Condition="@(ReferencePath->Contains('\ref\'))" />
  </ItemGroup>
</Target>

<Target Name="ReAddReferenceAssembliesAfterSGen" AfterTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <ReferencePath Include="@(_Ref_NoSgenPaths)"/>
  </ItemGroup>
</Target>

Thanks for the MSBuild Structured Log Viewer making it possible to efficiently analyze issues like this.

[johnridley]

Just had this issue for the first time doing a release build of a solution that has built correctly for years:
Severity Code Description Project File Line Suppression State
Error An attempt was made to load an assembly with an incorrect format: C:\Users\johnr.nuget\packages\microsoft.bcl.asyncinterfaces\1.1.0\ref\net461\Microsoft.Bcl.AsyncInterfaces.dll. WebServiceManager C:\Tenengen\Development\DevelopmentVS\Development\05 ENS\WebServiceManager\SGEN

This is in a project that has WCF web service references, The project is targeting anyCPU and .net Framework 4.7.2. The latest installed .Net Framework on my PC is 4.8, as well as 4.7.2.

Recent changes since I last did a release build: Upgraded to VS 16.8.1, migrated from packages.config to PackageReferences using the tool in Visual Studio
I fixed the issue by changing the GenerateSerializationAssemblies option from Auto to Off but that is a rather unsatisfactory workaround.

[marcpopMSFT]

This document has more information on how to do this in .NET Core https://docs.microsoft.com/en-us/dotnet/core/additional-tools/xml-serializer-generator

[thorhamma]

I I got this error only in project having web service refrences
@tomek14 to fix it i disabled GenerateSerializationAssemblies
on teh csproj i added this line for all the build config
<GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>bin\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>
</PropertyGroup>

Worked PERFECTLY