Strong Name NuGet package

[SamuelMcAravey]

Currently the NuGet package is not strong named, causing incompatibilities with other public NuGet packages that are strong named. Microsoft Guidance suggests that public packages be strong named:
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming#create-strong-named-net-libraries

Is this a feasible idea? Would it help if I sent in a pull request?

[zihotki]

As it was mentioned in the issue #13228 to the linked page, there are some issues with that recommendation. They say that one shouldn't put a signed and unsigned versions on nuget. But signed versions cause a plenty of issues in many cases. MS folks AFAIK are adressing the issue but it will take some time. So my advice for now is to leave it as is and use https://www.nuget.org/packages/StrongNamer/ in your project which requires strong naming.

[clemensv]

I'm on the fence on strong naming for the library unless we would make official builds with proper code signing, but I don't know how the CNCF mechanics for that work, at present.

[fabiocav]

@clemensv if following the latest .NET guidance (and new .NET/ASP.NET/Azure projects), you can just have the public and private keys in the repo and sign at build, eliminating the requirement for a signing service. This is also causing a problem for us as we need to publish a library that is strong named and would like to take a dependency on this.

Guidance: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md

[jskeet]

I've just run into this as well, while building https://github.com/GoogleCloudPlatform/functions-framework-dotnet

Strong names provide identity rather than security - they're very different from code signing.

The lack of a strongly-named release means that no other strongly-named packages can depend on CloudNative.CloudEvents at the moment :(

[jskeet]

@zihotki: Could you give some concrete examples of the issues caused by strong naming in modern environments? (In particular, with .NET Core, assembly binding redirects aren't nearly the problem they once were.) I've published NodaTime with strong names since 1.0 in 2012, and I don't remember any issues being filed about that at all. While Noda Time is no Json.NET, I would have thought if strongly-named assemblies really caused a lot of problems, I'd have heard about it.

I'd far rather have a "regular" strongly-named assembly than rely on a tool which starts changing assemblies at build time - that sounds far more likely to cause issues to me. (At the very least, I'd need to look into it a lot more carefully - do we really want every consumer to have to do that research?)

[jskeet]

Ping for this? The sooner this is settled, the better IMO. @clemensv are you the decision maker here? Would it be worth trying to set up a meeting to discuss this?

Note that currently assemblies in Azure NuGet packages (e.g. Microsoft.Azure.Functions.Extensions) all have strong names - so if Microsoft ever wants to publish NuGet packages that refer to this SDK (and I'm assuming they will), they'll either face being inconsistent about strong names, or resort to StrongNamer (which I suspect means that all consumers would need to use StrongNamer too).

One interesting point to consider: if we move from not-strong-names to strong-names, does that require a major version bump? I've a sneaking suspicion it might, which I appreciate is unpalatable, but better to do now (less than 6 months since 1.0, and when downloads are only in the thousands) than later on.

[clemensv]

We should do it and figure out the right way and whether we think the key needs protecting.

[zihotki]

@jskeet Indeed for .Net Core everything is more or less fine now. Although virality of strong naming is still a huge thing. If there is a need to implement an additional transport to cloud events then it'll make more effort to push the mainteiners for the transport library to apply a strong name.

But according to MS guidelines they also recommend to sign open source libraries:
https://docs.microsoft.com/en-gb/dotnet/standard/library-guidance/strong-naming
https://github.com/dotnet/runtime/blob/master/docs/project/strong-name-signing.md

[jskeet]

If there is a need to implement an additional transport to cloud events then it'll make more effort to push the mainteiners for the transport library to apply a strong name.

Agreed. I think there will be fewer cases of that compared with "I want to depend on the CloudEvents SDK but my assembly is signed" issues like this. Like so many things, it ends up being a balance.

I'm going to do some testing to see whether this change counts as breaking - I don't think it will, but basically my plan is:

• Build a local NuGet package with a signed version of the SDK, and call it 1.4.0
• Create an application that depends directly on 1.4.0, (signed) and indirectly on 1.3.80 (unsigned) via Google.Cloud.Functions.Framework 1.0.0-alpha05
• Check that we don't run into assembly loading issues

If that works, I'll do a slightly more complex test for net471. (I can't use the exact same setup as Google.Cloud.Functions.Framework is .NET Core 3.1 only.)

[jskeet]

Humbug: it really isn't binary-compatible:

Function.cs(11,29): error CS0012: The type 'CloudEvent' is defined in an assembly that is not referenced. You must add a reference to assembly 'CloudNative.CloudEvents, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. 

So we'd probably need to take a new major version in order to do this - which I still think we should do.

Rather than rush a 2.0 out of the door, I think we probably want to do an audit of everything we've learned in 1.x, and be really careful with a 2.0 release. Examples of breaking changes we should consider:

• Keeping the "core" package dependency-free, but moving JsonEventFormatter into different packages for different implementations (Json.NET vs System.Text.Json)
• Removing InternalsVisibleTo
• Strong naming
• Potentially giving more information about CloudEvent.Data via the type system - would a CloudEvent<TData> make sense, for example? It's not at all clear what users can expect at the moment.

At the time of this writing, 1.3.80 has 151K downloads. That makes 2.0 "somewhat painful, but doable" - but it probably means it's the last chance we have to make breaking changes for quite a while, possibly ever, without causing massive disruption.

If folks agree with this assessment, I'll create a new issue that's basically to collect "stuff we'd like to fix in 2.0".

[jskeet]

If folks agree with this assessment, I'll create a new issue that's basically to collect "stuff we'd like to fix in 2.0".

Rather than an issue, I've created a 2.0 milestone: https://github.com/cloudevents/sdk-csharp/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0