lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
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:
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
<Aaron.Meyers@microsoft.com.invalid> 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.
>

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