lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Meyers <>
Subject Strong-naming Lucene.Net assemblies
Date Mon, 04 Mar 2019 15:19:31 GMT
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

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.


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