Signed assemblies do hurt projects that use unsigned assemblies. Binding redirects are painful.
There seems to be a lot of discussion around this issue for other projects: * https://github.com/octokit/octokit.net/issues/405 * https://twitter.com/search?q=%23nomorestrongnaming&src=hash * http://shouldiusestrongnaming.azurewebsites.net/ * the aforementioned post from Jeremy Miller. There are pain points on both sides of the issue which is why there is a big discussion happening in the .NET community. The real solution might need the community to step up and change the package manager nuget in order to accommodate a single feed that allows for signed and unsigned assemblies and a way to filter on them. -M On Tue, Apr 29, 2014 at 5:30 AM, Alexey Shcherbachev < [email protected]> wrote: > Hi, > > I would strongly opt to keep assemblies signed by default too. Due to > platform constrains our solution is forced to install assemblies into the > GAC, which means that everything has to be signed. > > I would note, that number of projects that depends on Lucene.Net being > signed is considerably higher than number of assemblies referenced by > Lucene itself. So it is easier to keep them signed rather than force > everybody who needs a signed version to do that themselves or use > alternative distribution. And since keeping Lucene.Net signed won't hurt > projects that use unsigned assemblies, but it will hurt everybody who uses > signed version, it sounds more reasonable to keep everything as is. > > Regards, > Alexey Shcherbachev > US: 408.600.2737 > Russia (mobile): +7 (905) 47-97-677 > Russia (office): +7 (863) 266-50-67 > Skype: Leha-2304 > LinkedIn: http://linkedin.com/in/shcherbachev > > > On Tue, Apr 29, 2014 at 11:39 AM, Magnus Stråle < > [email protected] > > wrote: > > > Hi, > > > > I've been following this mailing list for a long time with the intent of > > eventually become more actively involved. Professionally I use Lucene.NET > > and we are relying on the NuGet distribution both internally and for our > > customers / partners that are building on our platform. > > > > Removing strong naming / signing of the assemblies shipped in the NuGet > > feed will be a *big* pain for us. > > > > 1. We have signed assemblies that have dependencies on lucene.net. > > 2. We have a large number of installations that are set up with NuGet > > dependencies to Lucene > > 3. We push updates on a fairly regular basis (weekly). > > 4. Some of our partners implement various solutions based on Lucene.Net > > > > The combination of 1 & 4 used to be a big problem, but now (mostly) just > > works thanks to NuGet. > > > > As I see our only practical option would be to create our own Lucene.net > > NuGet package and get all our customers/partners to take dependency on > > that version. > > > > Please, please - keep the main distribution signed. If you really have to > > go to an unsigned distribution, at least wait until the 4.x release and > > continue to provide signed 3.x releases. > > > > ...and yes - this is the time for me to step up. What would be the best > > area for me to start help out with Lucene.Net? Automation of the NuGet > > release process with signed assemblies? > > > > Magnus Stråle > > EPiServer AB > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > On > > Behalf Of Itamar Syn-Hershko > > Sent: den 28 april 2014 19:07 > > To: [email protected] > > Cc: [email protected] > > Subject: Re: Removing signing of assemblies (starting in v4) > > > > Yes, and this is why we are going to provide signed versions as downloads > > + scripts to sign the sources, just not in the main distribution stream > > which is nuget. > > > > We will take a canary testing kind of approach where we will do a > > pre-release of v4 and a bugfix release of v3 both usigned and see how > much > > people will complain. > > > > -- > > > > Itamar Syn-Hershko > > http://code972.com | @synhershko <https://twitter.com/synhershko> > > Freelance Developer & Consultant Author of RavenDB in Action < > > http://manning.com/synhershko/> > > > > > > On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <[email protected]> wrote: > > > > > +1 to Oren's point here > > > > > > Remember the signing dependency issue works both ways, there are lots > > > of other projects that depend on Lucene.Net which do sign their > > > dependencies and so changing whether the project is signed breaks > > > upstream consumers of the library > > > > > > An unsigned assembly can happily depend on a signed assembly whereas > > > the opposite is not true > > > > > > Regardless of how effective/valuable SN signing is we are > > > unfortunately stuck with it in the .Net world and you will only get > > grief. > > > > > > My own project got rid of signing for a while and had to bring it back > > > because we got too many user complaints about this. For comparison my > > > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I > > > would strongly suspect you will get far more user complaints far more > > > quickly if you drop signing in future releases. > > > > > > Rob > > > > > > > > > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <[email protected]> > > > wrote: > > > > > > >I'm many corporate environment that is a big requirement In a library > > > >like Lucene, where other people depend on it, a sign build is > > > >important On Apr 23, 2014 2:27 PM, "Petar Repac" > > > ><[email protected]> wrote: > > > > > > > >> There is a long discussion about SN here: > > > >> https://nuget.codeplex.com/discussions/247827 > > > >> > > > >> I'd suggest that even if decision is not to sign, there should be > > > >>an easy way to get signed assemblies. > > > >> > > > >> Like: > > > >> 1. clone repo (signing keys are publicly accessible in repository) > > > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....) 3. c/p > > > >> files from /build folder > > > >> > > > >> I stopped signing my assemblies long ago, but probably there still > > > >>are many that still do and less obstacles in adopting Lucene.NET > > > >>the better. > > > >> > > > >> Regards, > > > >> Petar Repac > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko > > > >> <[email protected] > > > >> >wrote: > > > >> > > > >> > All Lucene.NET assemblies are signed, aka strongly named. > > > >> > > > > >> > We are starting to run into problems with dependencies which not > > > >> > being signed. What's becoming more common in the .NET world (OSS > > > >> > mainly) is > > > >>to > > > >> > stop signing assemblies because its pretty< > > > >> > > > > >> > > > >> > > > http://stackoverflow.com/questions/20105103/are-signed-net-assemblies- > > > eve > > > >>r-fully-verified-when-loaded-to-check-they-haven > > > >> > > > > > >> > much< > > > >> > > > > >> > > > >> > > > http://stackoverflow.com/questions/1197133/anything-wrong-with-not-sig > > > nin > > > >>g-a-net-assembly > > > >> > > > > > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> > > > >> > (in > > > >>the > > > >> > last link: What Strong Names Can't Do). > > > >> > > > > >> > Regardless of the argument about SN it seems to bring more > > > >> > fraction > > > >>and > > > >> > trouble than anything good, especially considering we are an > > > >>open-source > > > >> > library. > > > >> > > > > >> > Case in question, I'm moving to updating the spatial module and > > > >> > want > > > >>to > > > >> > fetch dependencies from nuget. While spatial4n is signed (so it > > > >> > can be > > > >> used > > > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get > > > >> > signed > > > >>any > > > >> > time soon. Since signed assemblies cannot reference > > > >> > non-strongly-named assemblies, I can't currently do that - not > > through nuget at least. > > > >>This > > > >> > introduces a lot of frustration and tons of fraction which I'd > > > >> > like to > > > >> have > > > >> > removed. > > > >> > > > > >> > Ideally I'd want to move to removing strong-naming from all > > > >> > Lucene.NET assemblies (v4 and forward), and having a wiki page > > > >> > that describes why signing is pointless and how to manually sign > it > > if you insist. > > > >> > > > > >> > I can see 2 disadvantages for not signing, both of which I doubt > > > >>really > > > >> > matter nowadays and given our usage scenarios: > > > >> > > > > >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed > > > >> > assemblies can be SN or ILMerged as part of the install process) > > > >> > > > > >> > 2. Signed assemblies / project won't be able to get Lucene.NET > > > >> > from > > > >>nuget > > > >> > directly because they'll have to sign it before referencing it. > > > >> > Or > > > >>lose > > > >> SN > > > >> > themselves. > > > >> > > > > >> > Thoughts? > > > >> > > > > >> > -- > > > >> > > > > >> > Itamar Syn-Hershko > > > >> > http://code972.com | @synhershko <https://twitter.com/synhershko> > > > >> > Freelance Developer & Consultant Author of RavenDB in Action > > > >> > <http://manning.com/synhershko/> > > > >> > > > > >> > > > > > > > > > > > > > > > > > >
