search

michielpost / Q42.HueApi

C# helper library to talk to the Philips Hue bridge
MIT License
411 stars 114 forks source link

Please Sign Nuget Distribution #58

Closed ccicchitelli closed 8 years ago

ccicchitelli commented 8 years ago

Hello, first off thank you for the continued great work! We'd appreciate if you could sign the Nuget distribution so that it makes keeping up to date with the updates much simpler. Currently, we have to download the source code and do our own builds with signing enabled.

Distributing signed code via Nuget is the best practice. We're aware it could possible cause issues with some projects - but again the best practice is for those projects to download the source code, rather than the other way around.

Thanks again for the great work!!!

michielpost commented 8 years ago

I knew this day would come :) I'll do some investigation on how I can properly set this up. I want to be able to have AppVeyor build and release to NuGet, also the signed NuGet. But I guess I can't check in the private keys that are needed to build the signed NuGet. So not sure yet what's the best way to do this.

michielpost commented 8 years ago

What's the reason you need a signed dll? To install it in the GAC? Are you creating your own signed assembly and depending on Q42.HueApi? Just figuring out what's the use case, because I see there are lots of different reasons and solutions for signing assemblies for open source projects.

There's also this great service which will manage the process for you :) http://log.paulbetts.org/a-modest-proposal-strong-naming-carbon-offsets/

ccicchitelli commented 8 years ago

Our app is installed as a Windows Service, and strong naming is required for all services. You'll never find a "strong name or no strong name" debate in the commercial sector ;) In addition, as a commercial app, signing is recommended and required depending on the user who is installing it (i.e. group policy for businesses). Also, because you distribute on Nuget, it's best practice to distribute the signed version. The good news is there are no dependencies in this project that aren't signed, so it's simply a matter of checking the box.

I don't think this will negatively affect anyone using the project since there are no dependencies to cause issue..

Alternatively, you can do what Emby does and offer both signed and unsigned Nuget packages.

michielpost commented 8 years ago

I'm not going to sign the assembly for the main release of Q42.HueApi. I've read some more and there are disadvantages, like binding redirects if you want to use another version of json.net etc. I'm not going to go that way.

My suggestion is that you create a workflow that makes it easy for you to sign the assembly. Using the workflow described here you can sign an already build assembly: http://stackoverflow.com/questions/1379954/how-i-do-a-sign-an-assembly-that-has-already-been-built-into-a-dll-specifically

if you've got that working, you can create a pull request that contains a .bat file that signs the assembly and a .nuspec file for Q42.HueApi.Signed. If the bat file works and signes the assembly and creates a NuGet package, I'll integrate that with the buildserver / AppVeyor and release a signed version with every new release.

michielpost commented 8 years ago

This also might help: https://www.nuget.org/packages/Nivot.StrongNaming