search

jamietre / CsQuery

CsQuery is a complete CSS selector engine, HTML parser, and jQuery port for C# and .NET 4.
Other
1.15k stars 249 forks source link

Adding the NuGet package to a signed project/assembly #71

Closed marcofranssen closed 11 years ago

marcofranssen commented 11 years ago

When referencing this project / adding the nuget package to a signed assembly (outlook connector) I get the following error.

Error 9 Assembly generation failed -- Referenced assembly 'CsQuery' does not have a strong name

I also referenced other open source stuff like Castle Windsor... These just work fine. Can this be solved for CsQuery?

jamietre commented 11 years ago

Never bothered to sign the assembly! This is easy enough to do, I just pushed up signed CsQuery.dll if you want to grab it. I am going to be updating nuget most likely this afternoon (because of Issue #69) -- i'll start signing future releases.

jamietre commented 11 years ago

@marcofranssen - getting ready to release 1.3.3 I did some more research on this issue. It's not quite as simple as just signing it, since this also seems to create new constraints. There is a very, very long discussion here about how people think this should be handled with nuget.

http://nuget.codeplex.com/discussions/247827

For now I am not going to sign CsQuery binaries on nuget because it ssems as if it has the potential to cause other users to have difficulty upgrading between versions. So, the only solution for you would seem to be to compile & sign the code yourself from source. This is easy enough, but, of course, it eliminates the benefits of nuget package manager. I might change this in the future if I can better understand the consequences and/or nuget offers a facility to offer different versions (which seems to be the direction).

marcofranssen commented 11 years ago

Castle Windsor is working in my assembly, maybe you can compare what they did to make it work. I also included it with Nuget.

jamietre commented 11 years ago

Well, it is a decision that is made by each project owner, the issue (for me) is mostly that I really don't have a good handle yet on the consequences of signing. There is a lot of ideology out there on both sides and it scares me to make a change that could potentially affect lots of people without really understanding what might happen.

For example read this:

http://coderjournal.com/2012/04/json-net-strong-naming-and-nuget-woes/

regarding JSON.NET and signing. His solution ultimately is to not update version numbers.

Some people feel very strongly you should never sign nuget packages. Others feel just the opposite. More people seem to be on the side of not signing, since it causes DLL version problems and most people don't work in signed project environments.

Honestly I still don't feel like I understand it well enough to make an informed decision about this project. So I feel it would be irresponsible to make a change that could negatively affect many users without understanding it better.

jamietre commented 11 years ago

Struck my last comment after getting some more feedback from a significant dependent (Nancy)... I'm going to leave CsQuery unsigned for now.

It might be possible for me to sign without breaking dependencies using the JSON.NET approach, but there's definitely a great deal of opposition to signing from people who have a lot more first hand experience with the issue than I do.

So, I guess for you, you'll just have to compile CsQuery yourself and sign it. Hopefully NuGet will support inline singing sometime soon.

jamietre commented 11 years ago

One more comment... I see that some packages (e.g. Fluent Validation, SignalR) have both signed and unsigned repos on Nuget.

This is a possibility for CsQuery, I don't push updates too often and it's mostly automated so I could probably do this.

jamietre commented 11 years ago

I have decided to take the following approach for now. I will push signed releases to NuGet using the following conventions.

1) The package name is "CsQuery.Signed" 2) The releases will be versioned like "1.3.3-signed"

the upshot of #2 is that they will be considered a "prerelease" by nuget. This means you need to choose "include prerelease" from the UI or add the flag -Pre in package manager console.

If this works out OK i will drop the prereease versioning in the future, I am just wary of muddying the waters on the first go-round here.

1.3.3 is now available on nuget as package ID "CsQuery.Signed" in prerlease version 1.3.3-signed.