You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Aaron Meyers <Aa...@microsoft.com.INVALID> on 2019/03/04 15:19:31 UTC
Strong-naming Lucene.Net assemblies
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.
RE: Strong-naming Lucene.Net assemblies
Posted by Aaron Meyers <Aa...@microsoft.com.INVALID>.
Shannon, I should be able to submit a PR for this soon (hopefully sometime next week).
-----Original Message-----
From: Darcy Thomas <da...@darcythomas.com>
Sent: Wednesday, March 27, 2019 10:15 PM
To: dev@lucenenet.apache.org
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 <sh...@umbraco.dk> 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
> <Aa...@microsoft.com.invalid> 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 <it...@code972.com>
> > Sent: Monday, March 4, 2019 7:23 AM
> > To: dev@lucenenet.apache.org
> > 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
> > <Aaron.Meyers@microsoft.com
> .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.
> > >
> >
>
Re: Strong-naming Lucene.Net assemblies
Posted by Darcy Thomas <da...@darcythomas.com>.
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 <sh...@umbraco.dk> 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
> <Aa...@microsoft.com.invalid> 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 <it...@code972.com>
> > Sent: Monday, March 4, 2019 7:23 AM
> > To: dev@lucenenet.apache.org
> > 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 <Aaron.Meyers@microsoft.com
> .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.
> > >
> >
>
Re: Strong-naming Lucene.Net assemblies
Posted by Shannon Deminick <sh...@umbraco.dk>.
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
<Aa...@microsoft.com.invalid> 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 <it...@code972.com>
> Sent: Monday, March 4, 2019 7:23 AM
> To: dev@lucenenet.apache.org
> 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 <Aa...@microsoft.com.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.
> >
>
RE: Strong-naming Lucene.Net assemblies
Posted by Aaron Meyers <Aa...@microsoft.com.INVALID>.
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 <it...@code972.com>
Sent: Monday, March 4, 2019 7:23 AM
To: dev@lucenenet.apache.org
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 <Aa...@microsoft.com.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.
>
Re: Strong-naming Lucene.Net assemblies
Posted by Itamar Syn-Hershko <it...@code972.com>.
I wrote a piece about this a very long time ago, when I was still a
Microsoft MVP:
https://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net
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 <http://bigdataboutique.com/>
Elasticsearch Consulting Partner
Microsoft MVP | Lucene.NET PMC
http://code972.com | @synhershko <https://twitter.com/synhershko>
On Mon, Mar 4, 2019 at 5:19 PM Aaron Meyers
<Aa...@microsoft.com.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.
>