lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shad Storhaug (JIRA)" <>
Subject [jira] [Resolved] (LUCENENET-608) Add strong-naming to Lucene.Net to comply with Microsoft guidelines
Date Tue, 13 Aug 2019 05:37:00 GMT


Shad Storhaug resolved LUCENENET-608.
    Resolution: Fixed

Thanks for the PR. This is now in release 4.8.0-beta00006.

> 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