Create strong named project

[bothzoli]

Hey @mcintyre321,

This is a proof of concept for creating a strong named version of the base OneOf NuGet package.
See also #192.

Please let me know your thoughts about it. I'm happy to help setting this up for the other projects too.

[AArnott]

I do not recommend taking this approach of offering both strong named and non-strong-named packages. The problem is that a project may end up with a dependency graph that includes both, and then that project will have trouble consuming either one because the C# compiler won't be able to disambiguate them.

It's far better to just strong name the one existing library. The only downside is that it'll be a one-time binary breaking change for .NET Framework users. (.NET processes don't care about strong names, so it isn't a breaking change for them).

[bothzoli]

I may be missing something here, but if a project is strong named, it'll only be able to use strong named dependencies (including transitive ones). So, isn't the only way that this could cause an issue if a non-strongly named dependency uses a strongly named version of OneOf? 🤔

[AArnott]

if a project is strong named, it'll only be able to use strong named dependencies

True. But a non-strong named assembly can consume either one. Consider this dependency graph:

flowchart TD
    OneOf --> A
    OneOf.StrongName --> B
    A --> C
    B --> C

Loading

A and B are arbitrary 3rd party libraries. One or both of them may be strong named.
C likes the functionality of A and B and consumes both. C either is not strong-named itself or only target .NET, such that consuming non-strong named dependencies is an option (which is a requirement of consuming A).

Now C is consuming both OneOf and OneOf.StrongName assemblies. This confuses the compiler, at best, and causes deployment problems for the app (A or its consumer) at worst.

This is why in general, you never want to ship the same assembly in two different nuget packages.

C (or the app) could try to resolve this by choosing which OneOf to consume and denying the other:

<PackageReference Include="OneOf" ExcludeAssets="all" />

This would resolve the compiler problem and the deployment problem for C. But it's a pain, and not obvious to discover. And I don't think it would help an app that consumes "C", so the app itself would have to re-discover this hacky workaround and apply it as well. So would C's tests, etc.