lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <>
Subject Re: Strong-naming Lucene.Net assemblies
Date Mon, 04 Mar 2019 15:22:44 GMT
I wrote a piece about this a very long time ago, when I was still a
Microsoft MVP:

As I'm not really involved with Lucene.NET anymore, my opinion might matter
less - but that is my 2 cents on the topic.



Itamar Syn-Hershko
CTO, Founder
BigData Boutique <>
Elasticsearch Consulting Partner
Microsoft MVP | Lucene.NET PMC | @synhershko <>

On Mon, Mar 4, 2019 at 5:19 PM Aaron Meyers
<> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message