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.
