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: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming specifically: 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 NuGet.org. Strong naming is not required by most .NET applications and should not be done by default. Also: 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. Thanks, Aaron Meyers -----Original Message----- From: Itamar Syn-Hershko <[email protected]> Sent: Monday, March 4, 2019 7:23 AM To: [email protected] 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: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcode972.com%2Fblog%2F2014%2F04%2F68-ditching-strong-naming-for-lucene-net&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C149ff355ccce47dca0ac08d6a0b54d21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873097879673510&sdata=68kr4JrzAvqTYRmP0lAV2eObRlmsWPt0JjvfpX8xXPU%3D&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. Cheers, -- Itamar Syn-Hershko CTO, Founder BigData Boutique <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbigdataboutique.com%2F&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C149ff355ccce47dca0ac08d6a0b54d21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873097879673510&sdata=s1ncKq6BqlfwMdVGFSjLcKrFN51UCcdSjrQzzCYOmQU%3D&reserved=0> Elasticsearch Consulting Partner Microsoft MVP | Lucene.NET PMC https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode972.com&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C149ff355ccce47dca0ac08d6a0b54d21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873097879683500&sdata=lV3CAeGAr9VeXDO0Drt51k%2BYSJs0Mo%2B5joKbZSMo4dw%3D&reserved=0 | @synhershko <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fsynhershko&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C149ff355ccce47dca0ac08d6a0b54d21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873097879683500&sdata=kjoFfOcDWUtWtlXdShwlHROZ3S%2BSzdFKnzff6TS%2FSJs%3D&reserved=0> On Mon, Mar 4, 2019 at 5:19 PM Aaron Meyers <[email protected]> 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. >
