search

picoe / Eto.Parse

Recursive descent LL(k) parser for .NET with Fluent API, BNF, EBNF and Gold Grammars
MIT License
148 stars 30 forks source link

Sign assemblies #8

Open thargy opened 10 years ago

thargy commented 10 years ago

In .NET signed assemblies cannot make use of unsigned assemblies. When publishing to a public NuGet if your assemblies are unsigned they cannot be easily used in projects that are signed, significantly reducing their usability and usefulness.

Signing is trivially easy and has no down sides (the signed assemblies can be used in unsigned projects). You can create a key and sign the assembly from the project properties page. Any dll that you are pushing to the NuGet should be signed.

The standard approach is to NOT upload the official key to GitHub, and instead place a note in the project to indicate to contributors that they should add their own signatures whilst building. This ensures you can validate the ownership of the NuGet.

cwensley commented 10 years ago

Strong naming the assembly has some caveats re. the assembly version number. For example, if the version number were updated, any assemblies that link to it would need a binding redirect, which is pretty ugly. In order for this to work well, we'd have to 'freeze' the assembly version, and only update the file version for each release. This is what MS does with the .net stack, and also is what json.net is doing (see here)