lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Meyers (JIRA)" <>
Subject [jira] [Commented] (LUCENENET-608) Add strong-naming to Lucene.Net to comply with Microsoft guidelines
Date Sat, 06 Jul 2019 01:12:00 GMT


Aaron Meyers commented on LUCENENET-608:

I've submitted a PR for this: []

> Add strong-naming to Lucene.Net to comply with Microsoft guidelines
> -------------------------------------------------------------------
>                 Key: LUCENENET-608
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Improvement
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Aaron Meyers
>            Priority: Minor
>             Fix For: Lucene.Net 4.8.0
> As discussed on the dev mailing list, I would like to submit a PR to add strong-naming
to all the Lucene.Net assemblies.
> Rationale:
> 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:
> [] 
> 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 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.

This message was sent by Atlassian JIRA

View raw message