Strongly named assembly issue

[CortanaAnalyticsGallery]

I'm working at Azure Machine Learning Team and we found the kit very useful for the project we've been currently working on. Unfortunately we hit a blocker when it turns out that the dlls distributed through the nuget are not signed. Because we can only consume strongly named assemblies in production environment I would like to ask if there are any plans to make official nuget distribution with the signed dlls?

Here is the exception: "An exception of type 'System.IO.FileLoadException' occurred in <theDll>.dll but was not handled in user codeAdditional information: Could not load file or assembly 'Octokit, Version=0.24.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)"

[khellang]

I think the docs explains the strategy pretty clearly, though I haven't seen any work on this yet. If you're going to read the epic thread, I suggest you get some popcorn :wink:

Lately, there's been quite a few projects pointing to StrongNamer for questions like these. The library lets you transparently and automatically sign the assemblies you reference as part of the build process.

[shiftkey]

@AzureMLTest @khellang I'm mostly neutral on this due to the fact that it doesn't hurt me in my day-to-day work, but I'll defer to @ryangribble and @mderriey who have been doing a lot of work recently on getting .NET Standard support in on whether they want to support this at some stage.

And :thumbsup: to StrongNamer as an escape hatch for this.

[mderriey]

I don't have a strong opinion on the subject as I've never used it/experienced any pain with it.

I'd lean towards StrongNamer as the process seems straightforward.

[ryangribble]

I wasn't aware of the history (definitely enjoyed reading the epic thread! :popcorn:)

I am also from the "don't have a strong opinion" stance. The fact it hasn't come up in the 15 months I've been contributing to Octokit would seem to indicate it isnt a hugely requested feature. Given there are things like StrongNamer now to let others effectively make any of their dependencies strongly named when they need it, without needing the library to be strong named for all other users... is there an actual need to do anything in octokit.net here?

@AzureMLTest are you able to use StrongNamer on your side to satisfy your requirements? If there is a valid reason why it's not suitable then we can look at implementing it here, but I didnt like the sound of locking down assembly versions (as I am shooting for full automated builds and releases to nuget) or the fact that this could cause our existing users issues with redirects etc.

[AndreyTretyak]

If I understood the decision here correctly, the plan was too strong to name Octokit before version 1.0. Any chance we would get a strong naming since the project is already at version 2.0? I'll be happy to create a PR if that is something you'll consider.

Using StrongNamer to sign Octokit.dll during the build is a constant source of flakiness for our build and debug experience. It's essentially decompiles dll and compiles it again with strong name during build. That a step I would really like to remove from our build.

Also, I don't think that adding a strong name won't create any hindrances to build/release process automation. From the discussion it looks like you would like to follow Newtonsoft.Json versioning approach which would mean just using the major part of NuGet package version for dll versioning and it should be easy to automate.

In addition, I would like to point out that other Octokit packages like Octokit.GraphQL are signed for 5 years already link and it would be such a relief to have all of them consistently signed.