Sterke naamgeving

Sterke naamgeving verwijst naar het ondertekenen van een assembly met een sleutel, waardoor een sterk benoemde assembly wordt geproduceerd. Wanneer een assembly een sterke naam heeft, wordt er een unieke identiteit gemaakt op basis van de naam en het versienummer van de assembly en kunnen assemblyconflicten worden voorkomen.

Het nadeel van sterke naamgeving is dat .NET Framework in Windows het strikt laden van assembly's mogelijk maakt zodra een assembly een sterke naam heeft. Een sterk benoemde assemblyverwijzing moet exact overeenkomen met de versie van de geladen assembly, waardoor ontwikkelaars bindingsomleidingen moeten configureren bij gebruik van de assembly:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="myAssembly" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Wanneer .NET-ontwikkelaars klagen over sterke naamgeving, is wat ze meestal klagen over strikt laden van assembly's. Gelukkig is dit probleem geïsoleerd van .NET Framework. .NET 5+, .NET Core, Xamarin, UWP en de meeste andere .NET-implementaties hebben geen strikte assemblybelasting, wat het belangrijkste nadeel is van sterke naamgeving.

Een belangrijk aspect van sterke naamgeving in .NET Framework is dat het viral is: een sterk benoemde assembly kan alleen verwijzen naar andere assembly's met een sterke naam. Als uw bibliotheek geen sterke naam heeft, kunnen .NET Framework-apps en -bibliotheken die sterke naamgeving nodig hebben, deze niet gebruiken.

De voordelen van sterke naamgeving in .NET Framework zijn:

1. Er kan naar de assembly worden verwezen en gebruikt door andere sterk benoemde assembly's.
2. De assembly kan worden opgeslagen in de Global Assembly Cache (GAC).
3. De assembly kan naast andere versies van de assembly worden geladen. Het laden van assembly's naast elkaar is vaak vereist voor toepassingen met invoegtoepassingsarchitecturen.

Sterke naamgeving heeft geen voordelen voor .NET Core/5+. C#-compiler produceert CS8002-waarschuwing voor sterk benoemde assembly's die verwijzen naar niet-sterke benoemde assembly's. Het is prima om deze waarschuwing te onderdrukken voor bibliotheken die alleen gericht zijn op .NET Core/5+.

Sterke benoemde .NET-bibliotheken maken

Geef uw opensource .NET-bibliotheken een sterke naam als hun doelen .NET Framework of .NET Standard bevatten. Sterke naamgeving is niet vereist voor bibliotheken die zich alleen richten op .NET Core/5+.

Notitie

Deze richtlijnen zijn specifiek voor openbaar gedistribueerde .NET-bibliotheken, zoals .NET-bibliotheken die zijn gepubliceerd op NuGet.org. Sterke naamgeving is niet vereist voor de meeste .NET-toepassingen en mag niet standaard worden uitgevoerd.

✔️ OVERWEEG een sterke naam te geven aan de assembly's van uw bibliotheek.

✔️ OVERWEEG de sterke naamgevingssleutel toe te voegen aan uw broncodebeheersysteem.

Met een openbaar beschikbare sleutel kunnen ontwikkelaars de broncode van uw bibliotheek wijzigen en opnieuw compileren met dezelfde sleutel.

U moet de sterke naamgevingssleutel niet openbaar maken als deze in het verleden is gebruikt om speciale machtigingen te verlenen in scenario's met gedeeltelijke vertrouwensrelaties. Anders kunt u inbreuk maken op bestaande omgevingen.

Belangrijk

Wanneer de identiteit van de uitgever van de code gewenst is, worden Authenticode en NuGet-pakketondertekening aanbevolen. Cas (Code Access Security) mag niet worden gebruikt als een beveiligingsbeperking.

✔️ OVERWEEG om de assemblyversie te verhogen op alleen wijzigingen in de primaire versie, zodat gebruikers bindingsomleidingen kunnen verminderen en hoe vaak ze worden bijgewerkt.

Lees meer over versiebeheer en de assemblyversie.

❌ VOEG NIET de sterke naamgevingssleutel toe, verwijder of wijzig deze.

Als u de sterke naamgevingssleutel van een assembly wijzigt, wordt de identiteit van de assembly gewijzigd en wordt de gecompileerde code onderbreekt die deze gebruikt. Zie binaire wijzigingen die fouten veroorzaken voor meer informatie.

❌ PUBLICEER GEEN versies met een sterke naam en niet-sterk benoemde versies van uw bibliotheek. Bijvoorbeeld Contoso.Api en Contoso.Api.StrongNamed.

Het publiceren van twee pakketten forks uw ontwikkelaars eco-systeem. Als een toepassing eindigt, afhankelijk van beide pakketten, kan de ontwikkelaar ook typenaamconflicten tegenkomen. Wat .NET betreft, zijn ze verschillende typen in verschillende assembly's.

VorigeVolgende