Dela via

Stark namngivning

  • Artikel

Stark namngivning syftar på signering av en sammansättning med en nyckel, vilket ger en stark namngiven sammansättning. När en sammansättning är starkt namngiven skapar den en unik identitet baserat på namn och sammansättningsversionsnummer, och den kan bidra till att förhindra sammansättningskonflikter.

Nackdelen med stark namngivning är att .NET Framework i Windows möjliggör strikt inläsning av sammansättningar när en sammansättning är stark med namnet. En starkt namngiven sammansättningsreferens måste exakt matcha versionen av den inlästa sammansättningen, vilket tvingar utvecklare att konfigurera bindningsomdirigeringar när de använder sammansättningen:

<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>

När .NET-utvecklare klagar på stark namngivning klagar de vanligtvis på strikt sammansättningsinläsning. Lyckligtvis är det här problemet isolerat till .NET Framework. .NET 5+, .NET Core, Xamarin, UWP och de flesta andra .NET-implementeringar har inte strikt sammansättningsinläsning, vilket är den huvudsakliga nackdelen med stark namngivning.

En viktig aspekt av stark namngivning på .NET Framework är att den är viral: en starkt namngiven sammansättning kan bara referera till andra starka namngivna sammansättningar. Om biblioteket inte är starkt namngivet kan .NET Framework-appar och bibliotek som behöver stark namngivning inte använda det.

Fördelarna med stark namngivning på .NET Framework är:

  1. Sammansättningen kan refereras till och användas av andra starka namngivna sammansättningar.
  2. Sammansättningen kan lagras i den globala sammansättningscachen (GAC).
  3. Sammansättningen kan läsas in sida vid sida med andra versioner av sammansättningen. Separat monteringsinläsning krävs ofta av program med plugin-arkitekturer.

Stark namngivning har inga fördelar med .NET Core/5+. C#-kompilatorn genererar CS8002-varning för starkt namngivna sammansättningar som refererar till icke-starka namngivna sammansättningar. Det går bra att utelämna den här varningen för bibliotek som endast riktar in sig på .NET Core/5+.

Skapa starka .NET-bibliotek

Du bör ge dina .NET-bibliotek med öppen källkod ett starkt namn om deras mål inkluderar .NET Framework eller .NET Standard. Stark namngivning krävs inte för bibliotek som endast riktar in sig på .NET Core/5+.

Kommentar

Den här vägledningen är specifik för offentligt distribuerade .NET-bibliotek, till exempel .NET-bibliotek som publicerats på NuGet.org. Stark namngivning krävs inte av de flesta .NET-program och bör inte göras som standard.

✔️ ÖVERVÄG att namnge bibliotekets sammansättningar.

✔️ ÖVERVÄG att lägga till den starka namngivningsnyckeln i källkontrollsystemet.

Med en offentligt tillgänglig nyckel kan utvecklare ändra och kompilera om bibliotekets källkod med samma nyckel.

Du bör inte göra den starka namngivningsnyckeln offentlig om den tidigare har använts för att ge särskilda behörigheter i scenarier med partiellt förtroende. Annars kan du kompromettera befintliga miljöer.

Viktigt!

När identiteten för kodens utgivare önskas rekommenderas Authenticode - och NuGet-paketsignering . Code Access Security (CAS) bör inte användas som en säkerhetsreducering.

✔️ ÖVERVÄG att öka sammansättningsversionen på endast större versionsändringar för att hjälpa användare att minska bindningsomdirigeringar och hur ofta de uppdateras.

Läs mer om versionshantering och sammansättningsversionen.

❌ Lägg INTE till, ta bort eller ändra den starka namngivningsnyckeln.

Om du ändrar en sammansättnings starka namnnyckel ändras sammansättningens identitet och bryter kompilerad kod som använder den. Mer information finns i binära icke-bakåtkompatibla ändringar.

❌ Publicera INTE starkt namngivna och icke-starka namngivna versioner av biblioteket. Till exempel Contoso.Api och Contoso.Api.StrongNamed.

När du publicerar två paket förgrenas utvecklarens ekosystem. Om ett program hamnar beroende på båda paketen kan utvecklaren dessutom stöta på typnamnskonflikter. När det gäller .NET är de olika typer i olika sammansättningar.

FöregåendeNästa