For those who are stuck with needing to have all their dependent assemblies (hi there SSIS) you can use Brutal Strong Namer https://github.com/brutaldev/StrongNameSigner
Which let's you add a simple build step, which finds all of the unsigned (nuget or other) and signed them with your key. A simple way around the problem On Thu, Mar 28, 2019, 17:18 Shannon Deminick <[email protected]> wrote: > I'm fine with strong naming and we can't change it after release so best to > get it in there. Anyone have any time to submit a PR for this? > > On Tue, Mar 5, 2019 at 2:38 AM Aaron Meyers > <[email protected]> wrote: > > > 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] > .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. > > > > > >
