Runtime: The type 'ECCurve' exists in both 'System.Core' and 'System.Security.Cryptography.Algorithms' when targeting .NET Framework 4.7

Created on 13 Jul 2017 · 17Comments · Source: dotnet/runtime

I'm currently porting my ASP.NET Core OIDC server from 1.0 to 2.0 and I'm facing a strange error that appears in a class library targeting netstandard2.0, netcoreapp2.0 and net47 and using the new ECCurve type (introduced in netstandard1.6 and net47):

The type 'ECCurve' exists in both 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'System.Security.Cryptography.Algorithms, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

https://github.com/PinpointTownes/AspNet.Security.OpenIdConnect.Server/blob/31f43c4769d5400ab0f09760a5bb631807916a75/src/AspNet.Security.OpenIdConnect.Server/AspNet.Security.OpenIdConnect.Server.csproj

https://ci.appveyor.com/project/aspnet-contrib/aspnet-security-openidconnect-server/build/1.0.0-rtm-1262#L353

I spent a few hours trying to make a repro, but unsuccessfully. Any tips that would allow me to determine why this compilation error occurs when targeting net47 would be much appreciated! :sweat_smile:

area-System.Security bug

Source

kevinchalet

Most helpful comment

We are still going through the motions of getting this into .NET Core 2.0 SDK but if you want to unblock yourself right now you can add a PackageReference to NETStandard.Library.NETFramework 2.0.0-preview3-25514-04 (https://dotnet.myget.org/feed/dotnet-core/package/nuget/NETStandard.Library.NETFramework/2.0.0-preview3-25514-04) you will need to add our myget feed (http://dotnet.myget.org/F/dotnet-core/api/v3/index.json) to your sources to resolve the package. Please do let me know if you test this and whether or not it works for you.

weshaggard on 15 Jul 2017

❤1 🎉1 👍1

All 17 comments

@weshaggard Is the problem that the unification package is built against net461? Or that you have to reference a unification package explicitly? (Or some other piece of packaging and distribution that I don't quite understand? :smile:)

bartonjs on 13 Jul 2017

cc @ericstj @terrajobst

@bartonjs this is an actual bug that we will need to address by adding a net47 configuration to System.Security.Cryptography.Algorithms as the API surface area is different between net461 (the config we have) and net47.

For .NET 4.7 the type should come from System.Core and not System.Security.Cryptography.Algorithms.

weshaggard on 13 Jul 2017

@PinpointTownes There isn't a clean workaround that I can come up with for this one. If you can get away with it you can target a lower .NET version like 4.6.1 if possible, otherwise it isn't going to work until we get a fix.

weshaggard on 13 Jul 2017

@weshaggard well, the whole point of having a net47 TFM is to be able to use the new (and awesome!) EC APIs, so targeting an old .NET version wouldn't help much (I have a netstandard2.0 TFM for apps that target net461).

Do you think the fix could be included in 2.0 RTM?

kevinchalet on 13 Jul 2017

Do you think the fix could be included in 2.0 RTM?

I highly doubt it at this point as we are essentially done with the release. However we might be able to provide a workaround once we get a better understanding of the changes. I am however going to mark it as 2.0 for now to get some attention on it.

weshaggard on 14 Jul 2017

I highly doubt it at this point as we are essentially done with the release.

Honestly, that would be absolutely terrible. This used to work fine when referencing the ASP.NET Core 1.x bits :cry:

kevinchalet on 14 Jul 2017

It still works when targeting .NET Core 2.0 it is only a problem if you are running on .NET Framework. Did it work for you when running ASP.NET Core on .NET Framework? If so I'm not sure how.

I'm looking to see what options we have for a potential workaround.

weshaggard on 14 Jul 2017

Did it work for you when running ASP.NET Core on .NET Framework?

Absolutely. It compiled fine and worked as expected at runtime.

If you take a look at https://www.nuget.org/packages/AspNet.Security.OpenIdConnect.Server/1.0.0, you'll see that the ASP.NET Core 1.0 version targets net451, net47, netstandard1.4 and netstandard1.6. Both the net47 and netstandard1.6 versions - that use the new EC APIs - work fine.

kevinchalet on 14 Jul 2017

@PinpointTownes do you know if you are consuming an .NET Standard 2.0 libraries in your project? If not perhaps a potential workaround is to set <ImplicitlyExpandNETStandardFacades>false</ImplicitlyExpandNETStandardFacades> in your project. If you are then it will require a different type of workaround.

weshaggard on 14 Jul 2017

@PinpointTownes do you know if you are consuming an .NET Standard 2.0 libraries in your project?

Unfortunately, almost all the ASP.NET Core 2.0 packages are now netstandard2.0-only. So yeah, I target a lot of .NET Standard 2.0 packages.

kevinchalet on 14 Jul 2017

I've got a PR up with the fix for this issue https://github.com/dotnet/corefx/pull/22247. I'm going to attempt to get approval to get it into our .NET Core 2.0 escrow build but if that doesn't succeed I will be able to point you at a package on our myget feed (once we get a build of my PR) that should unblock you as a work around.

weshaggard on 14 Jul 2017

👍1

@weshaggard fantastic, thanks! :clap:

kevinchalet on 14 Jul 2017

weshaggard on 15 Jul 2017

❤1 🎉1 👍1