search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.24k stars 1.35k forks source link

ImplicitlyExpandNETStandardFacades option on MSBuild Extensions corrupts build #2527

Closed egbertn closed 2 years ago

egbertn commented 7 years ago

https://social.msdn.microsoft.com/Forums/en-US/51dc828b-43ca-4177-b68e-7a6a9cf81db5/ms-build-extensions-file-corrupt-my-bin-web-api-folder?forum=msbuild

Hi All, It seems that when my .NET 4.7 (or 4.61+) has dependencies to .NEt standard 1.1 or higher, MSBuild merges some Libraries from this path to the bin folder (Web API project) C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib

These DLLs however, are OLDER than the ones that Nuget gets for for example, System.Net.Http , System.Runtime, System.Runtime.InteropServices etc Many assemblies thus, are corrupted with incorrect, older 4.61 assemblies.

My projects are set to work for .NEt 4.7. The libraries that require dotnetstandard are not mine, but from MS, to say, OData 6.1 (and 6.0 also). So I cannot get rid of them.

Please somebody has a workaround or a fix?

Thanks

(My workaround now, is to drop these DLLs into the bin folder, which are the correct DLls that Nuget retrieves) drag

egbertn commented 7 years ago

These warning icons in the references section in my Visual STudio 2017 15.3.4 also drag so is indication of the conflicting files. It's quite huge.

sergey-litvinov commented 7 years ago

The same happens for me though i have 4.6.2 MVC project. It has NuGet reference to System.Runtime 4.3, but with VS 2017 15.3.5 it always uses old System.Runtime from C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib and due that my build fails.

And the same warning icons are displayed for me too.

sergey-litvinov commented 7 years ago

And also the same issue is mentioned here - https://dzone.com/articles/net-core-dll-hell-is-here-can-net-core-20-save-us

dsplaisted commented 7 years ago

You can find an overview of some of what is going on here and what issues there are here: https://github.com/dotnet/standard/issues/481

What makes you think that older DLLs are being chosen in place of newer ones? Are you looking at the timestamp, assembly version, or what? Generally we should choose the assembly with the higher version number, and we don't look at the timestamp.

sergey-litvinov commented 7 years ago

ok, here is my case. I have a couple of class libraries. They use Microsoft.CodeAnalysis 2.0.0-rc5-61501-05 package that has reference to Microsoft.CodeAnalysis.Common that has reference to System.Runtime. We use Roslyn package from myget feed as we needed VB Script fucntionality that wasn't present in main nuget package.

These packages are used in web app that also has web api.

Part of packages.config for webapp:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.AspNet.Mvc" version="4.0.40804.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.Mvc.FixedDisplayModes" version="1.0.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.Providers.Core" version="1.2" targetFramework="net45" />
  <package id="Microsoft.AspNet.Providers.LocalDB" version="1.1" targetFramework="net45" />
  <package id="Microsoft.AspNet.Razor" version="2.0.20715.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.Web.Optimization" version="1.0.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi" version="4.0.20710.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi.Client" version="4.0.30506.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi.Core" version="4.0.20710.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi.WebHost" version="4.0.20710.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebPages" version="2.0.20710.0" targetFramework="net45" />
  <package id="Microsoft.Azure.KeyVault.Core" version="1.0.0" targetFramework="net45" />
  <package id="Microsoft.Bcl" version="1.1.7" targetFramework="net45" />
  <package id="Microsoft.Bcl.Build" version="1.0.14" targetFramework="net45" />
  <package id="Microsoft.Bcl.Immutable" version="1.1.20-beta" targetFramework="net45" />
  <package id="Microsoft.Bcl.Metadata" version="1.0.9-alpha" targetFramework="net45" />
  <package id="Microsoft.CodeAnalysis.Analyzers" version="1.2.0-beta2" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.Common" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.CSharp" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.CSharp.Scripting" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.CSharp.Workspaces" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.Elfie" version="0.10.6-rc2" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.Scripting.Common" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.VisualBasic" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.VisualBasic.Scripting" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.VisualBasic.Workspaces" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.CodeAnalysis.Workspaces.Common" version="2.0.0-rc5-61501-05" targetFramework="net462" />
  <package id="Microsoft.Composition" version="1.0.27" targetFramework="net45" />
  <package id="System.AppContext" version="4.3.0" targetFramework="net462" />
  <package id="System.Console" version="4.3.0" targetFramework="net462" />
  <package id="System.IO" version="4.3.0" targetFramework="net462" />
  <package id="System.IO.Compression" version="4.3.0" targetFramework="net462" />
  <package id="System.IO.Compression.ZipFile" version="4.0.1" targetFramework="net462" />
  <package id="System.IO.FileSystem" version="4.3.0" targetFramework="net462" />
  <package id="System.IO.FileSystem.Primitives" version="4.3.0" targetFramework="net462" />
  <package id="System.Reflection" version="4.3.0" targetFramework="net462" />
  <package id="System.Reflection.Extensions" version="4.3.0" targetFramework="net462" />
  <package id="System.Reflection.Metadata" version="1.4.2" targetFramework="net462" />
  <package id="System.Reflection.Primitives" version="4.0.1" targetFramework="net462" />
  <package id="System.Resources.ResourceManager" version="4.3.0" targetFramework="net462" />
  <package id="System.Runtime" version="4.3.0" targetFramework="net462" />
  <package id="System.Runtime.Extensions" version="4.3.0" targetFramework="net462" />
  <package id="System.Runtime.Handles" version="4.0.1" targetFramework="net462" />
  <package id="System.Runtime.InteropServices" version="4.3.0" targetFramework="net462" />
  <package id="System.Runtime.InteropServices.RuntimeInformation" version="4.0.0" targetFramework="net462" />
  <package id="System.Runtime.Numerics" version="4.3.0" targetFramework="net462" />
</packages>

So it references to System.Runtime 4.3.0. Locally it's stored at packages\System.Runtime.4.3.0\lib\net462\System.Runtime.dll and it has size of 29880 bytes. dotPeek shows that actual assembly version is System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.

My web app csproj part looks like

<Reference Include="System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
    <HintPath>..\packages\System.Runtime.4.3.0\lib\net462\System.Runtime.dll</HintPath>
    <Private>True</Private>
</Reference>

And i don't have AutoGenerateBindingRedirects and GenerateBindingRedirectsOutputType there or in other class libraries. I also have such lines in web.config:

<system.web>
    <httpRuntime maxQueryStringLength="8192" maxUrlLength="8192" enable="true" maxRequestLength="1048576" targetFramework="4.6.2" />
    <compilation debug="true" targetFramework="4.6.2">
        <assemblies>
            <add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
        </assemblies>
    </compilation>
...
<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

So it has redirect to the same 4.1.1.0 version so it looks good.

When i do actual build i got warning 1> Consider app.config remapping of assembly "System.Runtime, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.1.0" [SomeWeb.Web\bin\System.Runtime.dll] to Version "4.1.2.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\\net461\ref\System.Runtime.dll] to solve conflict and get rid of warning. . It still compiles fine, but when app starts i'm getting

Parser Error Message: Could not load file or assembly 'System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Source Error: 

Line 67:     <compilation debug="true" targetFramework="4.6.2">
Line 68:       <assemblies>
Line 69:         <add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Line 70:       </assemblies>
Line 71:     </compilation>

After the build in web app bin folder i'm seeing different System.Runtime assembly with size of 29386 bytes. And dotPeek shows such information System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

So my project references to System.Runtime 4.3 (actual version 4.1.1.0), but during build it is replaced to 4.1.2.0.

If i add <ImplicitlyExpandNETStandardFacades>false</ImplicitlyExpandNETStandardFacades> like @egbertn mentions, then it fixes issue and it doesn't replace my assemblies. I'm not totally sure as i don't touch this project too often, but it might be that issue came with VS 2017 update 3. And for latest VS 2017 15.3.5 it still happens.

jogibear9988 commented 7 years ago

I've the same issue as @sergey-litvinov describes. I've found out, the 4.1.2.0 Version of System.Runtime is the one wich is in the NetStandart2.0.1 Nuget Package.

centur commented 6 years ago

In the same boat as people above. Number of libraries from 4.6.1 Extensions overwrite referenced libs and causing some dll hell. Any update on when it can be properly fixed ?

Going to try this <ImplicitlyExpandNETStandardFacades>false</ImplicitlyExpandNETStandardFacades> workaround.

haiduong87 commented 2 years ago

My own solution (for a .net 4.6.2 winform solution):

Question: Is there any way to apply <ImplicitlyExpandNETStandardFacades>false</ImplicitlyExpandNETStandardFacades> for solution?

egbertn commented 2 years ago

Obviously not monintored anymore, so close.