Facades not correctly versioned in NETStandard.Library.Framework package

[weshaggard]

From @eerhardt

I’m seeing some odd behavior with the conflict resolution logic we have in the SDK for netstandard2.0 on desktop.

Basically, the scenario is an ASP.NET 2.0 MVC website on the desktop framework. So the following are all referenced:

1. "NETStandard.Library": "2.0.0-preview2-25316-01",
2. "NETStandard.Library.NETFramework": "2.0.0-preview2-25304-02",
3. A bunch of System.* v4.3.0 packages (through transitive references)

Looking at the build log, I see entries like the following:

Encountered conflict between 'Reference:C:\Users\eerhardt.nuget\packages\netstandard.library.netframework\2.0.0-preview2-25304-02\build\net461\ref\System.Console.dll' and 'Reference:C:\Users\eerhardt.nuget\packages\system.console\4.3.0\ref\net46\System.Console.dll'. Choosing 'Reference:C:\Users\eerhardt.nuget\packages\system.console\4.3.0\ref\net46\System.Console.dll' because AssemblyVersion '4.0.1.0' is greater than '4.0.0.0'. (TaskId:14)

I see a similar entry for the “lib” assembly.

I would have thought that the netstandard.library.netframework should win out over the v4.3.0 package assembly. Or at least, it is consistent between all of our framework assemblies. For example, if I look at the Crypto stuff, sometimes the netstandard.library.netframework assembly is winning:

Encountered conflict between 'Reference:C:\Users\eerhardt.nuget\packages\netstandard.library.netframework\2.0.0-preview2-25304-02\build\net461\ref\System.Security.Cryptography.Algorithms.dll' and 'Reference:C:\Users\eerhardt.nuget\packages\system.security.cryptography.algorithms\4.3.0\ref\net461\System.Security.Cryptography.Algorithms.dll'. Choosing 'Reference:C:\Users\eerhardt.nuget\packages\netstandard.library.netframework\2.0.0-preview2-25304-02\build\net461\ref\System.Security.Cryptography.Algorithms.dll' because AssemblyVersion '4.3.0.0' is greater than '4.1.0.0'. (TaskId:14)

And sometimes the v4.3.0 package is winning:

Encountered conflict between 'Reference:C:\Users\eerhardt.nuget\packages\netstandard.library.netframework\2.0.0-preview2-25304-02\build\net461\ref\System.Security.Cryptography.Encoding.dll' and 'Reference:C:\Users\eerhardt.nuget\packages\system.security.cryptography.encoding\4.3.0\ref\net46\System.Security.Cryptography.Encoding.dll'. Choosing 'Reference:C:\Users\eerhardt.nuget\packages\system.security.cryptography.encoding\4.3.0\ref\net46\System.Security.Cryptography.Encoding.dll' because AssemblyVersion '4.0.1.0' is greater than '4.0.0.0'. (TaskId:14)

It feels like this isn’t what we intended.

The following packages are “winning” over the netstandard.library.netframework libraries:

• System.ComponentModel.Primitives.dll
• System.Console.dll
• System.IO.FileSystem.dll
• System.IO.FileSystem.Primitives.dll
• System.IO.FileSystem.Watcher.dll
• System.Security.Cryptography.Encoding.dll
• System.Security.Cryptography.Primitives.dll
• System.Security.Cryptography.X509Certificates.dll
• System.Threading.Thread.dll

[weshaggard]

The version numbers aren't high enough for the desktop case because we usually bumped the patch version of the assembly for desktop to ensure we could ship it a new version that could win if loading from the GAC. With PR #369 we decided to raise the version of the shims to be higher then any serviced version of the shim. To do that we took the max of the assembly version between netfx and netstandard and then incremented the patch version by 1 to ensure it should have a higher version then anything we would have serviced in release/1.1.0 branches.

[ericstj]

I think you mean PR #369

[weshaggard]

Yep just updated that inline :)