Signing

[mgoertz-msft]

Strongname signing of assemblies as well as potential Authenticode signing.

[pedrolamas]

As far as I can see, this has unfortunately already been done...

I started a discussion about why this shouldn't be done here, please fell free to follow and share your thoughts also!

[commonsensesoftware]

Expanding my own support to UWP Behaviors, I just hit this issue. I see absolutely no reason why this library should not be strong-named. Not strong-naming breaks those that want strong naming, but the inverse is not true.

1. Strong naming is for identification only; it really has nothing to do with security
2. Strong naming is critical for binding redirection policies a. No policy can be applied for weak-named assemblies; the CLR just assumes it will work
3. Strong naming doesn't have to be hard: a. Don't use delayed signing; that pretty much removes all the pain points an author might have b. Don't treat the *.snk as a security mechanism; just check it in to your repo i. There are countless examples of Microsoft OSS libraries that do this

I've been strong naming since the days of 1.0 and haven't encountered all the myriad of issues people report. The only real breaking scenario I can think of is consumers that use Reflection to load assemblies because the CLR assembly loader uses different policies for strong-named versus weak-named assemblies (if I'm not mistaken). Using Reflection to imperatively load assemblies should be avoided. Even for plug-in models, it's best to define the appropriate probing paths and let the CLR do it's thing to correctly load assemblies. Regardless, when the Reflection APIs are used correctly, it is possible to load strong-named assemblies the same as weak-named assemblies.

As a long-time author of OSS .NET libraries, I've never had someone ask me to provide a weak-named version of an assembly; however, I see quite the opposite littered throughout the web. If no consensus can be reached, then I'd recommend publishing official weak and strong-named flavors of the package as some other authors have done.

[pedrolamas]

Not strong-naming breaks those that want strong naming, but the inverse is not true.

I've been strong naming since the days of 1.0 and haven't encountered all the myriad of issues people report.

Well, I guess I can assume you never developed for Windows Phone 7.x, where binding redirection wasn't actually available - but in any case, were are talking about UWP here!

Assembly Binding Redirection is not available in UWP, but then again apparently it doesn't need it: CoreCLR/.NET Native will gladly take a higher version of an assembly if it is supplied.

I haven't tested it thoroughly, but my understanding of this is that for UWP it doesn't matter if an assembly is strongly signed or not.

Having said that, most libraries related with UWP are not strong signed (some examples: Json.net, MVVMLight, UWP Toolkit, Template10, Cimbalino Toolkit, MVVMCross, ...).

To quickly fix your problem, have you heard of StrongNamer?

[commonsensesoftware]

Actually, I worked on Silverlight long before the Window Phone days, which began my long journey down the multi-targeting path; however, I've done plenty of Windows Phone too. ;) You're right that binding redirects weren't supported, but that's because CoreCLR added improvements (that have carried forward) making the process unnecessary.

I guess it's all those years of Code Analysis beating me over the head and telling me that I need to add a strong name. =P Honestly, I feel much of this debate would be put to bed with a well-thought out policy. This shouldn't just be for this repo, but for UWP development in general (obviously, linked here). For example, the .NET Core libraries have a clear policy on strong naming and why. All of the .NET Core libraries are strong-named for compatibility and servicing.

I don't really want to go with an option that requires esoteric work on my part, such as artificially applying a strong name with StrongNamer just so I can have my assembly strong named. To quickly fix my solution, I just need to not strong name when the build targets UWP. I can get onboard with not using strong names, given a well-articulated policy. If this is the recommended guidance for UWP, then Microsoft should not only closely adhere to the policy, but also formally document it as the practice that UWP library authors should follow. If such a policy already exists, please feel free to straighten me out with a link to it.

To this point, my observations about To Strong Name or Not to Strong Name have entered the realm of Tabs vs Spaces, Private Fields Should Be Prefixed Underscores, ICloneable is a Worthless Inteface, and similar debates. The true pain strong naming, or lack thereof, seems to be more anecdotal.