Strong Name Assemblies - und wie man sie macht


Thomas Wölfer
Thomas Wölfer

07. März 2005


Das es wünschenswert ist, Assemblies mit 'strong names' zu versehen, ist vermutlich jedermann klar. Grund: Man schafft einen Ausweg aus der DLL-Hell, schafft die Vorraussetzung für Side-By-Side Execution und stellt nebenher noch sicher, das die Assembly nicht ohne weiteres (übersetzung: nicht) verändert werden kann. Prima Sache.

Dummerweise ist das wie immer nicht ganz so einfach, weil die Dokumentation zum .Net SDK und die zu Visual Studio nicht gerade wirklich hilfreich zur Hand gehen. Hier daher die Kurzzusammenfassung was man tun muss:

  • Soll eine Assembly einen 'strong name' bekommen, dann müssen auch alle referenzierten einen haben.
  • Das paar aus public und private Key kann man mit dem 'sn' Utility aus dem .Net SDK erzeugen. Das Ding wird bei der Installation von Visual Studio mit installiert. Um damit eine Datei zu erzeugen, die sowohl den öffentlichen als auch den privaten Key enthält: 'sn -k NameDerDatei.snk'
  • Dieses Key-File kann man dann in der Assembly verwenden. Bei C# und VB.Net geht das einfach, indem man den Pfad zur Datei in der 'AssemblyInfo.cs' (bzw: .vb) angibt. Dazu gibt es ein passendes Attribut (das bei C# bloederweise einen anderen Pfad erwartet, als bei VB). Bei C# gilt: [assembly: AssemblyKeyFileAttribute(@"..\..\NameDerDatei.snk")] - und zwar dann, wenn sich das 'snk' File im gleichen Verzeichnis wie die Projekt-Datei befindet.
  • Bei C++ ist das aufwendiger: Hier muss der Name der Datei bei den Linker-Optionen eingetragen werden. Es gibt dafür kein eigenes Feld, sondern man muss die Option /KEYFILE:NameDerDatei.snk bei den Linker-Optionen und 'Command Line' -> 'Additional Options' eintragen.
  • Will man nun außerdem noch hin- und wieder - zum Beispiel beim Debuggen - die Möglichkeit haben eine DLL zu übersetzen und zu verwenden, ohne das ganze Projekt neu zu bauen - dann muss man die Angabe des AssemblyKeyFileAttributes bzw. die Linker-Option nur im Rahmen der Release-Optionen angeben. Tut man das nicht, kann man die eigenen Anwendung nicht mehr mit einer 'separat' übersetzen DLL starten.
  • Schließlich gibt es noch das Problem von COM-Komponenten oder OCXen, die man gerne verwenden will. Dazu gehört zum Beispiel das IE Browser-Control. Das kann man zwar mehr oder weniger einfach auf eine Windows.Forms Form ziehen - aber die zugehörigen, von Visual Studio erzeugten DLLs haben dann leider keinen 'strong name'. Für solche Objekte muss man unter den Eigenschaften des Projektes nochmals den Namen einer SNK-Datei angeben: Die wird dann vom VS verwendet, wenn es die Wrapper-Assemblies für COM-Objekte generiert.