And compile every component we use in (spatial4n, NTS, etc) and kill every opportunity for people to enhance Lucene.NET on their own? no thanks
-- 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 7:15 PM, Petar Repac <[email protected]> wrote: > > http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/ > > ILMerge ? > > > On Mon, Apr 28, 2014 at 7: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-signin > > >>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/> > > >> > > > >> > > > > > > > > > > >
