dotnet/sdk

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

.NET 4.6.1 project cannot reference a .NET Standard 1.4 project - conflicting types #514

Closed
opened this Issue Dec 16, 2016 · 15 comments

Projects
None yet
9 participants

gulbanana commented Dec 16, 2016

 Repro: https://github.com/gulbanana/repro-netstandard-httpclient These two projects were created with VS2017 RC Refresh. Neither contains any meaningful code. netstdlib builds ok, but netfxlib fails: banana@forsyth MINGW64 /c/code/repro-netstandard-httpclient/netfxlib (master) \$ dotnet build Microsoft (R) Build Engine version 15.1.458.808 Copyright (C) Microsoft Corporation. All rights reserved. netstdlib -> C:\code\repro-netstandard-httpclient\netstdlib\bin\Debug\netstandard1.4\netstdlib.dll C:\Program Files\dotnet\sdk\1.0.0-preview4-004233\Microsoft.Common.CurrentVersion.targets(1909,5): warning MSB3243: No way to resolve conflict between "System.IO.Compression, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089". Choosing "System.IO.Compression, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" arbitrarily. [C:\code\repro-netstandard-httpclient\netfxlib\netfxlib.csproj] C:\Program Files\dotnet\sdk\1.0.0-preview4-004233\Microsoft.Common.CurrentVersion.targets(1909,5): warning MSB3243: No way to resolve conflict between "System.Net.Http, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing "System.Net.Http, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily. [C:\code\repro-netstandard-httpclient\netfxlib\netfxlib.csproj] Consider app.config remapping of assembly "System.IO.Compression, Culture=neutral, PublicKeyToken=b77a5c561934e089" from Version "4.0.0.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.IO.Compression.dll] to Version "4.1.0.0" [C:\Users\banana\.nuget\packages\system.io.compression\4.1.0\ref\net46\System.IO.Compression.dll] to solve conflict and get rid of warning. Consider app.config remapping of assembly "System.Net.Http, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.0.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll] to Version "4.1.0.0" [C:\Users\banana\.nuget\packages\system.net.http\4.1.0\ref\net46\System.Net.Http.dll] to solve conflict and get rid of warning. Class1.cs(9,29): error CS0433: The type 'HttpClient' exists in both 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Net.Http, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' [C:\code\repro-netstandard-httpclient\netfxlib\netfxlib.csproj]  Warnings are present even if you don't add a line of code to either project, and if you try to use any types from System.IO.Compression or System.Net.Http it's an unfixable compile error.

qmfrederik commented Dec 22, 2016 • edited

 I'm seeing this issue as well. I tried to do what the build warning instructs me to do - I added an assembly binding redirect for S.IO.Compression & S.N.Http, and added an  for the app.config file in my .csproj file, but still get the warnings (see my config below). Is there any way we can workaround this by updating the project file? It would as I'm currently blocked by this. Extract from my csproj file:  ... ...  My app.config file:   Thanks!

qmfrederik commented Dec 22, 2016

 Perhaps worth adding that Entity Framework Core references NETStandard.Library even on net461 so anyone using Entity Framework Core is affected by this: aspnet/EntityFrameworkCore#7078

gulbanana commented Dec 23, 2016

 referencing netstandard.lib on desktop needs to be made ok to do, as it will become harder and harder to avoid. unfortunately the status quo is that you must avoid it due to issues such as the webrequest inheritance security thing. i think the exacerbating factors with new csproj are twofold: default assembly refs cause immediate clashes binding redirects are no longer a workaround option but the fundamental underlying cause is the same. a desktop-safe release of netstandard.library is needed asap - we cannot wait for the 2.0 timeframe!
Member

dsplaisted commented Dec 23, 2016

 I haven't yet looked into what's going on here, but this is definitely supposed to work and it's important for it to work. @gulbanana I haven't heard about the webrequest inheritance security thing, if there isn't already an issue open for that please also open one (probably the dotnet/standard repo would be the right place).

gulbanana commented Dec 23, 2016

 There is already an issue with plenty of work being done :) It's at dotnet/corefx#11100 The only reason I mentioned it here is that it's another reason we can't yet safely reference netstandard.library from desktop, and therefore a reason that overriding the default reference set doesn't fully work around this issue.

qmfrederik commented Dec 23, 2016

 @gulbanana Just wanted to make sure I understand correctly: what you are saying is that there is another issue which also blocks projects which reference NETStandard.Library working reliably on .NET FX, not that this issue is a duplicate of dotnet/corefx#11100, correct? By looking at dotnet/corefx#11100, it seems that dotnet/corefx#11100 is a runtime issue, whereas this is a compile time issue There is a workaround for dotnet/corefx#11100 via manually setting the assembly redirects; whereas this issue is about the dotnet build (msbuild/SDK/CLI) somehow not picking up the assembly binding redirects and the compilation to fail. My understanding is that the workaround for dotnet/corefx#11100 does not apply here and there is no known workaround for this one, effectively preventing compilation of csproj projects which reference NETStandard.Library for the net461 runtime. Any workaround for this (or pointers to what we can do to provide a fix - happy to create a PR if needed) would be greatly appreciated :)

Closed

Member

dsplaisted commented Jan 4, 2017

 I think this is the same issue as Microsoft/msbuild#1329

Closed

gulbanana commented Jan 5, 2017

 I think that's a component of the problem, but bear in mind the warning is not spurious - it is correctly indicating that you will not be able to use those types.

Closed

Member

ericstj commented Jan 6, 2017

 This looks to me like the SDK is missing this code that existed in the previous NuGet targets: https://github.com/NuGet/NuGet.BuildTasks/blob/cb9b1a1559efac311b84aacc5f605004ad9e8562/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets#L216-L218 That is what made this work in NuGet 3. RAR is getting a simple name reference which resolves to the targeting pack and the NuGet reference then not resolving the conflicts between the two since they are both primary. We do need RAR to fix that moving forward, so you can let Microsoft/msbuild#1329 track that fix.

jdluzen commented Jan 8, 2017 • edited

 Also getting this with a brand new project. Library targeting .NETStandard1.6 Tests for the library targeting .NET4.6.1 Windows 10, VS2015.3, .NET Core 1.1.0 SDK 1.0.0 Preview 2.1, .NET Core 1.0.1 VS 2015 tooling Preview 2 Edit: I can continue for now by going down to 1.4.

Merged

dsplaisted added a commit to dsplaisted/sdk that referenced this issue Jan 16, 2017

 Remove simple name references matching references that come from NuGe… 
…t packages

Fixes #514
 be46669 
Contributor

natidea commented Jan 16, 2017

 Similar issue seen in https://github.com/Intellitect/coalesce /cc @MarkMichaelis @GrantErickson

Merged

Closed

gulbanana commented Jan 17, 2017

 looks like the fix will be that the implicitly added ref will be dropped by the sdk when a packageref adds the same library, so we'll end up with just the netstandard version of these dlls in my original scenario. is that a reasonable understanding of #662?

Merged

Contributor

natidea commented Jan 18, 2017

 Yes, the fixes in #662 and #671 will prefer any DLLs supplied through the NuGet assets file over implicit framework references. So for the following, the first entry will be chosen:  Assemblies= C:\Users\dev\.nuget\packages\system.net.http\4.1.0\ref\net46\System.Net.Http.dll NuGetIsFrameworkReference=false NuGetSourceType=Package Private=false System.Net.Http NuGetIsFrameworkReference=true NuGetSourceType=Package Private=false 

gulbanana commented Jan 19, 2017

 sounds good, thanks

Closed

oliverjanik commented May 15, 2017

 When will this fix land?
to join this conversation on GitHub. Already have an account? Sign in to comment