Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Sterke naamgeving verwijst naar het ondertekenen van een assembly met een sleutel, waardoor een assembly met een sterke naam 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, gaat het meestal over het strikte laden van assembly's. Gelukkig is dit probleem geïsoleerd van .NET Framework. .NET 5+, .NET Core, 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:
- Andere sterk benoemde assembly's kunnen naar de assembly verwijzen en deze gebruiken.
- De assembly kan worden opgeslagen in de Global Assembly Cache (GAC).
- De samenstelling kan naast andere versies van de samenstelling 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 sterk benoemde assembly's. Het is prima om deze waarschuwing te onderdrukken voor bibliotheken die alleen gericht zijn op .NET Core/5+.
Sterk 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+.
Opmerking
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 het sterke naamgevingssleutelpaar (openbaar + privé) toe te voegen aan uw broncodebeheersysteem.
Met een openbaar beschikbaar sleutelpaar kunnen ontwikkelaars de broncode van uw bibliotheek wijzigen en opnieuw compileren met dezelfde sleutel.
U moet het sterke naamgevingssleutelpaar niet openbaar maken als het in het verleden is gebruikt om speciale machtigingen te verlenen in scenario's met gedeeltelijke vertrouwensrelaties. Anders kunt u inbreuk maken op bestaande omgevingen.
Als u het openbare + persoonlijke sleutelpaar niet kunt indienen, dien dan de openbare sleutel in en gebruik openbare ondertekening voor reguliere builds. Met openbare ondertekening kunnen ontwikkelaars uw bibliotheek nog steeds opnieuw compileren en gebruiken in de meeste scenario's.
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 alleen te verhogen bij grote versie wijzigingen, zodat gebruikers het aantal 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 brekende wijzigingen voor meer informatie.
❌ PUBLICEER GEEN versies met een sterke naam en versies zonder sterke naam van uw bibliotheek. Bijvoorbeeld Contoso.Api
en Contoso.Api.StrongNamed
.
Het publiceren van twee pakketten forks uw ontwikkelaars eco-systeem. Als een toepassing afhankelijk wordt van beide pakketten, kan de ontwikkelaar typenaamconflicten tegenkomen. Wat .NET betreft, gaat het om verschillende typen in verschillende assemblages.