Shannon, I should be able to submit a PR for this soon (hopefully sometime next week).
-----Original Message----- From: Darcy Thomas <[email protected]> Sent: Wednesday, March 27, 2019 10:15 PM To: [email protected] Subject: Re: Strong-naming Lucene.Net assemblies For those who are stuck with needing to have all their dependent assemblies (hi there SSIS) you can use Brutal Strong Namer https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbrutaldev%2FStrongNameSigner&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C8b7044c6d32a4d0a5aa608d6b33c4fa4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636893468951535776&sdata=5sstIU7hl7mQGV7Q%2BelOo5fZptfSDtpfsaRa4Ydn9Yg%3D&reserved=0 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > .microsoft.com%2Fen-us%2Fdotnet%2Fstandard%2Flibrary-guidance%2Fstrong > -naming&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C8b7044c6d32a > 4d0a5aa608d6b33c4fa4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6368 > 93468951535776&sdata=IJYExhEc8vjKEad3%2FLQ%2BiExsFeeqDaW5cHPQujV3r > c0%3D&reserved=0 > > > > 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%2Fcode > 972.com%2Fblog%2F2014%2F04%2F68-ditching-strong-naming-for-lucene-net& > amp;data=02%7C01%7CAaron.Meyers%40microsoft.com%7C8b7044c6d32a4d0a5aa6 > 08d6b33c4fa4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893468951 > 535776&sdata=BENWP3QYAKGabsQcEUCgUEKoTLYWgzwDslOxqSNTnfc%3D&re > served=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%2Fbigda > taboutique.com%2F&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C8b > 7044c6d32a4d0a5aa608d6b33c4fa4%7C72f988bf86f141af91ab2d7cd011db47%7C1% > 7C0%7C636893468951535776&sdata=eMt%2FKqXiNwZPSkKlYue841ZAlmVCejLlT > OznvE8m5VA%3D&reserved=0 > > > > > Elasticsearch Consulting Partner > > Microsoft MVP | Lucene.NET PMC > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode9 > 72.com&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C8b7044c6d32a4 > d0a5aa608d6b33c4fa4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63689 > 3468951545770&sdata=9iAXqcjuBq%2BKuTVOoeMPSPlcuXe84yGVJiyAls5atH0% > 3D&reserved=0 > > | @synhershko < > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwit > ter.com%2Fsynhershko&data=02%7C01%7CAaron.Meyers%40microsoft.com%7 > C8b7044c6d32a4d0a5aa608d6b33c4fa4%7C72f988bf86f141af91ab2d7cd011db47%7 > C1%7C0%7C636893468951545770&sdata=%2Fj2QEnRuD1%2BnJB6JPvkgX%2BghjU > cZWr7y%2F4PnnZybSBE%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. > > > > > >
