Freigeben über

Starke Benennung

Starke Benennung bezieht sich auf das Signieren einer Assembly mit einem Schlüssel, wodurch eine stark benannte Assembly erzeugt wird. Wenn eine Assembly stark benannt ist, erstellt sie eine eindeutige Identität basierend auf dem Namen und der Assemblyversionsnummer, und sie kann dazu beitragen, Assemblykonflikte zu verhindern.

Der Nachteil der starken Benennung besteht darin, dass .NET Framework unter Windows das strikte Laden von Assemblys ermöglicht, sobald eine Assembly stark benannt ist. Ein stark benannter Assemblyverweis muss genau mit der Version der geladenen Assembly übereinstimmen, wodurch Entwickler gezwungen werden, Bindungsumleitungen bei Verwendung der Assembly zu konfigurieren:

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

Wenn sich .NET-Entwickler über starke Namen beschweren, beschweren sie sich in der Regel über die strikte Assembly-Ladung. Glücklicherweise ist dieses Problem in .NET Framework isoliert. .NET 5+, .NET Core, UWP und die meisten anderen .NET-Implementierungen haben kein striktes Laden von Assemblys, was der Hauptnachteil starker Namensgebung ist.

Ein wichtiger Aspekt der starken Benennung in .NET Framework besteht darin, dass es viral ist: Eine stark benannte Assembly kann nur auf andere stark benannte Assemblys verweisen. Wenn Ihre Bibliothek nicht stark benannt ist, können .NET Framework-Apps und -Bibliotheken, die eine starke Benennung benötigen, diese nicht verwenden.

Die Vorteile einer starken Benennung in .NET Framework sind:

  1. Auf die Assembly kann von anderen stark benannten Assemblies verwiesen und verwendet werden.
  2. Die Assembly kann im Global Assembly Cache (GAC) gespeichert werden.
  3. Die Assembly kann parallel mit anderen Versionen der Assembly geladen werden. Side-by-Side Assembly Loading ist in der Regel für Anwendungen mit Plug-In-Architekturen erforderlich.

Starke Benennung hat keine Vorteile für .NET Core/5+. Der C#-Compiler erzeugt eine CS8002-Warnung für stark benannte Assemblies, die auf nicht stark benannte Assemblies verweisen. Es ist in Ordnung, diese Warnung für Bibliotheken zu unterdrücken, die nur auf .NET Core/5+ abzielen.

Erstellen von starken benannten .NET-Bibliotheken

Sie sollten ihre Open-Source.NET-Bibliotheken unbedingt benennen, wenn ihre Ziele .NET Framework oder .NET Standard enthalten. Eine starke Benennung ist nicht für Bibliotheken erforderlich, die nur .NET Core/5+ verwenden.

Hinweis

Dieser Leitfaden ist spezifisch für öffentlich verteilte .NET-Bibliotheken, z. B. .NET-Bibliotheken, die auf NuGet.org veröffentlicht wurden. Eine starke Benennung ist für die meisten .NET-Anwendungen nicht erforderlich und sollte nicht standardmäßig erfolgen.

✔️ BERÜCKSICHTIGEN SIE eine starke Benennung der Assemblys Ihrer Bibliothek.

✔️ ERWÄGEN SIE, das starke Benennungsschlüsselpaar (public + private) zu Ihrem Quellcodeverwaltungssystem hinzuzufügen.

Mit einem öffentlich verfügbaren Schlüsselpaar können Entwickler den Quellcode ihrer Bibliothek mit demselben Schlüssel ändern und neu kompilieren.

Sie sollten das starke Benennungsschlüsselpaar nicht öffentlich machen, wenn es in der Vergangenheit verwendet wurde, um spezielle Berechtigungen in teilweise vertrauenswürdigen Szenarien zu erteilen. Andernfalls können Sie vorhandene Umgebungen kompromittieren.

Wenn Sie das Paar aus öffentlichem und privatem Schlüssel nicht einchecken können, dann checken Sie den öffentlichen Schlüssel ein und verwenden Sie Öffentliches Signieren für normale Builds. Mit der öffentlichen Signatur können Entwickler Ihre Bibliothek in den meisten Szenarien erneut kompilieren und verwenden.

Von Bedeutung

Wenn die Identität des Herausgebers des Codes gewünscht wird, wird Authenticode und NuGet-Paketsignierung empfohlen. Die Codezugriffssicherheit (Code Access Security, CAS) sollte nicht als Sicherheitsminderung verwendet werden.

✔️ ERWÄGEN SIE, die Assemblyversion nur bei Änderungen der Hauptversion zu erhöhen, um Benutzern zu helfen, Bindungsumleitungen zu reduzieren. Berücksichtigen Sie auch, wie oft sie aktualisiert werden.

Weitere Informationen zur Versionsverwaltung und zur Assemblyversion.

❌ FÜGEN SIE NICHT den starken Namensschlüssel hinzu, entfernen oder ändern Sie ihn.

Das Ändern des starken Namensschlüssels einer Assembly ändert die Identität der Assembly und bricht kompilierten Code auf, der ihn verwendet. Weitere Informationen finden Sie unter binären Unterbrechungsänderungen.

❌ VERÖFFENTLICHEN SIE KEINE stark benannten und nicht stark benannten Versionen Ihrer Bibliothek. Beispiel: Contoso.Api und Contoso.Api.StrongNamed.

Das Veröffentlichen von zwei Paketen spaltet Ihr Entwicklerökosystem auf. Auch kann der Entwickler auf Typennamenkonflikte stoßen, wenn eine Anwendung letztendlich von beiden Paketen abhängt. In Bezug auf .NET handelt es sich um unterschiedliche Typen in verschiedenen Assemblies.

ZurückWeiter