title: NuGet package (.NET Standard 2.x) breaking ASP.NET MVC5 application (.NET full framework)
body: <p>(updated - see below)</p>
  
  <p>I have an ASP.NET MVC5 application (multiple Assemblies) all addressing the .NET Full Framework 4.7.1</p>
  
  <p>I recently added a (private) NuGet package that we built using .NET Standard 2.  From <a href="https://docs.microsoft.com/en-us/nuget/quickstart/create-and-publish-a-package-using-visual-studio-net-framework" rel="noreferrer" title="Microsoft">Quickstart: Create and publish a package using Visual Studio (.NET Framework)</a>:</p>
  
  <blockquote>
    <p>Unless you have a reason to choose otherwise, .NET Standard is the preferred target for NuGet packages, as it provides compatibility with the widest range of consuming projects. </p>
  </blockquote>
  
  <p>Since then, things just haven't been the same.....there are a list of errors that I mention below, but I suspect they're all symptoms of the same issue (discussed at the end).</p>
  
  <p><em>Please note</em>: I'm using Visual Studio 15.7.1, and all NuGet packages use the package.config manage format rather than PackageReference.</p>
  
  <p><strong>First problem</strong></p>
  
  <blockquote>
    <p>Method not found:
    'System.Collections.ObjectModel.Collection`1
    System.Web.Http.HttpConfiguration.get_MessageHandlers()'</p>
  </blockquote>
  
  <p>My guess here is that there's a .NET Standard version of System.Web.Http that doesn't have this method, and my application has chosen to address this rather than the 4.7.1 framework.</p>
  
  <p>I <em>partially</em> fixed this by adding the following to my web.config file:</p>
  
  <pre><code>&lt;dependentAssembly&gt;
      &lt;assemblyIdentity name="System.Net.Http" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" /&gt;
      &lt;bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" /&gt;
  &lt;/dependentAssembly&gt;
  </code></pre>
  
  <p>I say "partially" fixed it, this fixes the problem when run in my DEV environment (with Visual Studio) but when published to our QA environment, the issue remains.  Any ideas on how to fix this?</p>
  
  <p><em>Note</em>: The MVC project's reference to System.Net.Http exists in the following path (it is NOT a NuGet package):</p>
  
  <blockquote>
    <p>C:\Program Files (x86)\Microsoft Visual
    Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Net.Http.dll</p>
  </blockquote>
  
  <p><strong>Second problem</strong>
  Two of the Assemblies are involved with pulling data from various web-sources (WCF, web-api, web-service).  When compiling these in RELEASE mode (where I have code analysis etc turned on) I get the following error reported:</p>
  
  <blockquote>
    <p>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.    {Name
    of the assembly}  {Path to the assembly}\SGEN</p>
  </blockquote>
  
  <p>I found one <a href="http://blog.bitcollectors.com/adam/2012/10/sgen-an-attempt-was-made-to-load-an-assembly-with-an-incorrect-format-tfs-2010/" rel="noreferrer" title="post">post</a> had the following suggestion:</p>
  
  <blockquote>
    <p>Another suggestion I saw (which didn’t help me at all), was to disable
    the project from creating a serialization assembly.  Follow these
    steps to do that (it may or may not help, but it’s worth a try):</p>
    
    <ol>
    <li>In Solution Explorer, right click on the project that has the error and go to Properties.</li>
    <li>In the Build tab, scroll to the very bottom and change Generate
    Serialization Assembly to Off</li>
    </ol>
  </blockquote>
  
  <p>I tried this and yes, it worked for me.  However, these are the two projects that are serializing objects to send to these various web sources, so the last thing I want to be doing is un-optimizing serialization within my application...</p>
  
  <p>Any suggestions on what might be wrong, or how I should best proceed?</p>
  
  <p><strong>UPDATE 14-May-2018</strong>
  I found a great article from <a href="https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx" rel="noreferrer" title="Referencing .NET Standard Assemblies from both .NET Core and .NET Framework">Scot Hanselman</a> regarding NuGet packages which states:</p>
  
  <blockquote>
    <p>As Oren wisely says:</p>
    
    <p>"Using .NET Standard requires you to use PackageReference to eliminate
    the pain of “lots of packages” as well as properly handle transitive
    dependencies. While you may be able to use .NET Standard without
    PackageReference, I wouldn’t recommend it."</p>
  </blockquote>
  
  <p>However, there's a catch.... In Visual Studio, there is now an easy way to migrate an assembly from the older package.config to PackageReference as detailed in this <a href="https://blog.nuget.org/20180409/migrate-packages-config-to-package-reference.html" rel="noreferrer" title="Migrate to PackageReference with 3 clicks">link</a>, but that article clearly states:</p>
  
  <blockquote>
    <p>Note that the migrator does not presently support C++, JavaScript, and ASP.NET (.NET Framework) projects.</p>
  </blockquote>
  
  <p>And when attempting this, the migration tool duly notified me that for the NuGet packages Microsoft.AspNet.Mvc and Microsoft.AspNet.WebPages:</p>
  
  <blockquote>
    <p>"content" assets are not available when the package is installed after the migration</p>
  </blockquote>
  
  <p><strong>UPDATE 23-May-2018</strong> I found several other people are experiencing a similar issue.  From GitHub: <a href="https://github.com/dotnet/sdk/issues/1630" rel="noreferrer">.NET 4.6.1/.NET Standard 2.0 build with SGen fails #1630</a>.  Their "solution" was again to disable the serialization (see above) which would ruin performance on my application.</p>
  
  <blockquote>
    <p>&lt;GenerateSerializationAssemblies&gt;Off&lt;/GenerateSerializationAssemblies&gt;</p>
  </blockquote>
  
  <p><strong>Conclusion?</strong></p>
  
  <p>So, am I right to conclude that to consume a .NET Standard 2.x NuGet package in a .NET FullFramework application, I need to use PackageReference rather than package.config and this is currently not possible with AspNet.MVC applications?  In other words, it's not currently possible.</p>