Sign LibGit2Sharp.dll by a strong name

[kostrse]

VSPackage (Visual Studio extensions) development requires usage of strongly-named assemblies.
As result, NuGet package version of the library cannot be used out of box in such scenarios.

It would be very helpful to add singing of the library on the build server and distribute the signed version.
As it would solve my problem, also it give ability to distinguish the "official" releases from custom built binaries by other members of community.

The process of signing can be made absolutely transparent: private key can be stored on a build server, as well as *.csproj files can be patched with necessary strong name properties directly during CI build.

I can provide all the necessary information how to implement this and help with modification of MSBuild script.

Thanks,

[nulltoken]

It would be very helpful to add singing of the library on the build server and distribute the signed version.

@kostrse Hmm. I'm really not sure about this... It looks like the community hasn't reach a clear-cut agreement on this:

• @thecodejunkie "General rule of thumb: Never strong-name open-source code or kittens will die" (here and here)
• @davidebbo "The assembly strong naming conundrum" (nuget discussion)
• @JamesNK "Json.NET Strong Naming and Assembly Version Numbers" (blog post)

I can provide all the necessary information how to implement this and help with modification of MSBuild script.

I'm very far from being an expert on this subject, so provided some agreement is being reached on this topic, I'll be really thankful for all the help you'll be able to provide this project with :)

[anaisbetts]

If you need strongly named assemblies, you'll have to do it yourself. Strong Naming causes a ton of issues with open-source software and impedes contribution.

Think of the kittens Sergey. The kittens.

[anaisbetts]

So, on a more helpful and less "Nope"y note, the easiest way for you to get this working is to fork and git submodule libgit2sharp, then just add it to your build. That way you can set up libgit2sharp to be strongly named using your own key without spending hours fiddling with post-build stuff.

It's also a reasonable idea because libgit2 / libgit2sharp move at a pretty quick rate of development, so it's nice to have new features faster (and to be able to request bug fixes then quickly incorporate them).

Let me know if the submodule stuff doesn't make any sense and we can help you out to get this working

[JamesNK]

How to keep the most people happy: Sign the assembly, don't change the AssemblyVersionAttribute and use AssemblyFileVersionAttribute to represent the current version instead.

No assembly binding redirect issues and people who need a strong named assembly have it.

[jaredpar]

@kostrse the Visual Studio Package infrastructure doesn't require a strong name. The default template for packages creates one but it's actually unnecessary. Once the wizard finishes you can open up the project and delete all references to strong naming and the project will continue to run.

There are indeed cases where strong naming is necessary in a Visual Studio extension. But this is generally only if you have a utility library that is versioned. Even then the package consuming the library doesn't need to be versioned, only the library itself does

[nulltoken]

@xpaulbettsx @JamesNK @jaredpar Thanks a lot for your feedback!

@kostrse I'm afraid LibGit2Sharp assembly won't be strong-named in the near future. However, from what I read you should be able to work around this quite easily.

Closing this now.

[deadlydog]

For others who encounter this issue and are disappointed too, this is how you can sign the assembly yourself: http://www.codeproject.com/Tips/341645/Referenced-assembly-does-not-have-a-strong-name

[anaisbetts]

I also offer strong naming as a service, should you not want to handle this issue yourself:

http://log.paulbetts.org/a-modest-proposal-strong-naming-carbon-offsets/

[deadlydog]

Turns out that every few builds the assembly would somehow lose it's strongly signed status for some reason and I would have to strongly sign it again. I ended up just adding the following code to the "Pre-build event command line:" box in the project property page's Build Events tab to sign the assembly before every build.

:: Strongly sign the LibGit2Sharp.dll, as every few builds it gets overwritten, and VS Extensions want strongly signed assemblies.
:: http://www.codeproject.com/Tips/341645/Referenced-assembly-does-not-have-a-strong-name
cd "$(SolutionDir)packages\LibGit2Sharp.0.20.0.0\lib\net40\"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\ildasm.exe" /all /out=LibGit2Sharp.il LibGit2Sharp.dll
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\sn.exe" -k MyLibGit2SharpKey.snk
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe" /dll /key=MyLibGit2SharpKey.snk LibGit2Sharp.il

Notice that the LibGit2Sharp NuGet package version is hard-coded in here, so this code will need to be updated each time you update the NuGet package. Also, the paths for ildasm.exe, sn.exe, and ilasm.exe are where they were located on my machine; they may be located somewhere else on your machine.

[nulltoken]

@deadlydog Thanks for sharing this with us ✨

@paulcbetts 🆒 Do you foresee any price cut for Black Friday?