12

We are trying to update the framework of our program. We currently have it in version 4.5.2 and we want to update it to version 4.7.1

We have changed all the csproj of the solution, and when we compile in debug, the application compiles and works correctly. But when we do it in release, it fails us with the following 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

We don't really know what's wrong, does anyone know what it could be?

Thank you very much.

Meldrel
  • 155
  • 1
  • 2
  • 9
  • Very hard to explain how this could only fail in the Release build. But you need to take a look at the file, it looks corrupted. Use ildasm.exe for a basic smell. – Hans Passant Mar 15 '18 at 15:24
  • Try to check if System.IO.Compression.ZipFile is references to your solution as a nuget package. Have you also tried to check if your config file contains a . Of course this tag directed to the ZipFile dll. If it is redirecting to another version this could be your problem. Please let me know. – Rodrigo Werlang Mar 15 '18 at 15:31

3 Answers3

22

UPDATE: As Josh suggests below, now that 4.7.2 is available, upgrade to that .NET version for the best resolution of this problem.

If stuck with 4.7.1: This probably isn't addressing the root of the problem, but if you want to get over this for the moment, then find the offending project and edit its settings (rclick project, 'Properties', then 'Build' tab.)

Set 'Generate serialization assemblies' to 'Off' for Release mode.

If it still complains, try adding the following <Target>s to your .csproj file (e.g. towards the bottom, just inside the enclosing </Project> root 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
  • 1,268
  • 10
  • 17
  • 2
    This is a performance build step for [Serializable] classes. Setting the setting to 'Off' is basically saying - trust the serialization classes available at runtime, so it won't affect your actual code output. I hit this issue building locally also, but VSTS hosted build server (Visual Studio Online) has no issues. So it's a 'build machine' problem. Presumably because VSTS uses a nice containerized clean build environment, not my sludgy old updated-a-million-times-with-DLLs-all-over-the-place laptop. :) – oflahero Mar 16 '18 at 16:08
  • 3
    I have set Set `Generate serialization assemblies' to `Off' for Release mode in both projects, and now it works correctly. Thank you very much. – Meldrel Mar 20 '18 at 15:43
  • 1
    for those that are still getting this error (like me), the new workaround is to install the .net 4.7.2 Developer Pack. Source; https://github.com/dotnet/sdk/issues/1630#issuecomment-415811457 – josh Oct 15 '18 at 13:35
  • @josh -- thank you! Google brought us here, and your comment solved our issue. Please add it as a full fledged answer. – 9Rune5 Oct 16 '18 at 12:07
  • 1
    I am using net472, and still had the issue. Turning off solved it. It seems is related to imported web service references (I did not have this issue in any other project). – Kat Lim Ruiz Sep 26 '19 at 14:09
6

This issue is fixed in the latest .net dev pack 4.7.2:

https://github.com/dotnet/sdk/issues/1630#issuecomment-415811457

https://www.microsoft.com/net/download/thank-you/net472-developer-pack

josh
  • 1,231
  • 1
  • 12
  • 28
  • 1
    Fix: 1) Remove web/app.config binding redirects 2) Remove NuGet package for System.Net.Http 3) Open "Add New Reference" and directly link to the new 4.2.0.0 build that ships with .NET 4.7.2 – EnocNRoll - AnandaGopal Pardue Jan 10 '19 at 22:16
  • Try just removing the redirect in app/web.config. This alone worked for me after the issue arose upgrading to 4.7.2 – Derrick Jan 10 '20 at 23:13
5

The root of the issue is that the assembly you are seeing in the error message has an incorrect entry in the .NET Framework unification table.

That incorrect entry causes the assembly reference to not correctly unify with the assembly in the framework and leads to that error. This is documented as a known issue in .NET Framework 4.7.1.

As a workaround you can add these targets to your project. They will remove the DesignFacadesToFilter from the list of references passed to SGEN (and add them back once SGEN is done)

    <Target Name="RemoveDesignTimeFacadesBeforeSGen" BeforeTargets="GenerateSerializationAssemblies">
      <ItemGroup>
        <DesignFacadesToFilter Include="System.IO.Compression.ZipFile" />
        <_FilterOutFromReferencePath Include="@(_DesignTimeFacadeAssemblies_Names->'%(OriginalIdentity)')" 
            Condition="'@(DesignFacadesToFilter)' == '@(_DesignTimeFacadeAssemblies_Names)' and '%(Identity)' != ''" /> 
        <ReferencePath Remove="@(_FilterOutFromReferencePath)" />
      </ItemGroup>
      <Message Importance="normal" Text="Removing DesignTimeFacades from ReferencePath before running SGen." /> </Target>

    <Target Name="ReAddDesignTimeFacadesBeforeSGen" AfterTargets="GenerateSerializationAssemblies">
      <ItemGroup>
        <ReferencePath Include="@(_FilterOutFromReferencePath)" />
      </ItemGroup>
      <Message Importance="normal" Text="Adding back DesignTimeFacades from ReferencePath now that SGen has ran." />
    </Target>

Edit: If the above doesn't work, please share a detailed msbuild log to help understand why the target doesn't work.

Another option (machine wide) is to add the following binding redirect to sgen.exe.config:

    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="System.IO.Compression.ZipFile" publicKeyToken="b77a5c561934e089" culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>

This will only work on machines with .NET Framework 4.7.1. installed. Once .NET Framework 4.7.2 is installed on that machine, this workaround should be removed.

Alex Ghiondea - MSFT
  • 3,182
  • 1
  • 8
  • 11
  • 1
    I first hit this issue when compiling in Debug mode, and I added the remove-before-SGEN-and-readd targets to my project, which fixed it - but not for Release mode, oddly. Only setting 'Generate serialization assemblies' to 'Off' finally sorted the Release mode error. – oflahero Mar 21 '18 at 16:37
  • 1
    Interesting... Could you share a project where this repros? The targets should apply to both Release and Debug configurations and so SGEN should continue to work in both. A detailed build log for this would also be very helpful in understanding why SGEN continues to pick up the reference assemblies for that. – Alex Ghiondea - MSFT Mar 22 '18 at 19:02
  • I've tried Alex, and of course I can't :) It looks like it was a transient issue related to my own machine. You're correct of course about the targets applying to all build modes. Right now I can successfully compile my affected solution in both Debug and Release with 'Generate serialization assemblies' at Auto. I don't understand it - looks like you know more about the area than me - but I'm looking forward to 4.7.2 (or switching to .NET Core!) – oflahero Mar 23 '18 at 17:34
  • 1
    Just to add to the SO knowledge - here's an [interesting Github comment](https://github.com/dotnet/standard/issues/514) where someone else is seeing a disparity between Debug and Release builds in this case - conficient's comment, 5 April 2018. S/he narrows it down further to the case where the project has a webservice reference - which was also the case for me. – oflahero Apr 05 '18 at 10:05