lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Meyers <>
Subject RE: Strong-naming Lucene.Net assemblies
Date Mon, 04 Mar 2019 15:38:35 GMT
Thanks Itamar, yes I remember your article. The current reality though is that Microsoft still
recommends that libraries (but not applications) use strong-names. Modern frameworks like
.NET Core/Xamarin/UWP have relaxed the assembly binding policy so that pain point is gone
moving forward, but .NET Core still strong-names its assemblies which effectively means this
ship has sailed (if anything was going to change further it would have changed in .NET Core).

I would strongly advocate that we follow the published guidance on this:

You should strong name your open-source .NET libraries. Strong naming an assembly ensures
the most people can use it, and strict assembly loading only affects the .NET Framework.
This guidance is specific to publicly distributed .NET libraries, such as .NET libraries published
on Strong naming is not required by most .NET applications and should not be done
by default.

DO NOT publish strong-named and non-strong-named versions of your library. For example, Contoso.Api
and Contoso.Api.StrongNamed.
Publishing two packages forks your developer eco-system. Also, if an application ends up depending
on both packages the developer can encounter type name conflicts. As far as .NET is concerned
they are different types in different assemblies.

Aaron Meyers

-----Original Message-----
From: Itamar Syn-Hershko <> 
Sent: Monday, March 4, 2019 7:23 AM
Subject: Re: Strong-naming Lucene.Net assemblies

I wrote a piece about this a very long time ago, when I was still a Microsoft MVP:;;sdata=68kr4JrzAvqTYRmP0lAV2eObRlmsWPt0JjvfpX8xXPU%3D&amp;reserved=0

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 <;;sdata=s1ncKq6BqlfwMdVGFSjLcKrFN51UCcdSjrQzzCYOmQU%3D&amp;reserved=0>
Elasticsearch Consulting Partner
Microsoft MVP | Lucene.NET PMC;;sdata=lV3CAeGAr9VeXDO0Drt51k%2BYSJs0Mo%2B5joKbZSMo4dw%3D&amp;reserved=0
| @synhershko <;;sdata=kjoFfOcDWUtWtlXdShwlHROZ3S%2BSzdFKnzff6TS%2FSJs%3D&amp;reserved=0>

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.
View raw message