I wrote a piece about this a very long time ago, when I was still a Microsoft MVP: https://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net
As I'm not really involved with Lucene.NET anymore, my opinion might matter less - but that is my 2 cents on the topic. Cheers, -- Itamar Syn-Hershko CTO, Founder BigData Boutique <http://bigdataboutique.com/> Elasticsearch Consulting Partner Microsoft MVP | Lucene.NET PMC http://code972.com | @synhershko <https://twitter.com/synhershko> On Mon, Mar 4, 2019 at 5:19 PM Aaron Meyers <[email protected]> wrote: > Hi all, > > Excited to see the renewed interest in Lucene.Net lately! As we're looking > toward the 4.8.0 release, I wanted to re-open a discussion about > strong-naming the Lucene.Net assemblies. > > I know there are debates about whether strong-naming is needed or provides > any value, but purely from a practical standpoint, the short story is that > we (and many other teams at Microsoft) still strong-name all the assemblies > that we build (and this isn't likely to change, if only because the cost to > do so is high). Because we do this, we can't reference any assemblies that > aren't strong-named. Anyone else that still uses strong-naming on > assemblies is in the same situation (and major OSS libraries like > Newtonsoft.Json are strong-named as a result). > > For this reason we currently have to maintain our own copy of the > Lucene.Net assembly with strong-name added. I would love to be able to use > the official release of 4.8.0 instead (and official releases moving > forward) as this simplifies our process of consuming updates to Lucene.Net > (and incentives our developers to contribute fixes back to mainline rather > than making local fixes). > > I've never heard any practical argument against strong-naming an OSS > assembly (only philosophical ones) since a strong-name in no way means that > consumers of the assembly need to use strong names at all. > > So - are there any objections to adding strong-naming to the Lucene.Net > assemblies? We already have a key checked into the repository and I'm happy > to submit a PR for this. The previous official release (3.0.3) had strong > naming using the checked in key. > > Thanks! > > Aaron Meyers > Principal Software Engineer > Microsoft Power BI > > > P.S. For completeness sake, we don't rely on strong-naming as a security > feature. We also apply Authenticode digital signatures to all the binaries > that we ship (including third-party ones like Lucene.Net) but this is an > automated part of our official build process so it doesn't prevent me from > referencing the official Lucene.Net nuget directly. Strong-naming on the > other hand impacts developer debug builds because it affects assembly > identity and so we can't just apply one retroactively. >
