Best Practices zum Signieren von Assemblys mit mehreren Projekten und Entwicklern

Question

Ich suche Empfehlungen und Best Practices für die Anwendung signierter Assemblies in einer Organisation mit mehr als 30 Entwicklern, 20+ Lösungen und 60+ Projekten. Wir verwenden Visual Studio Team System 2008 und TFS.

Während die Erstellung eines Schlüssels und das Signieren der Assembly eine sehr einfache und unkomplizierte Prozedur ist, bin ich besorgt, wie wir das am besten schaffen.

Meine Gedanken so weit:

• Jede Lösung, die in der Regel zwischen 3 und 20 Projekte hat, wird eine einzige PFX Schlüsseldatei in der Lösung Stammordner platziert haben.
• Jede Lösung wird ein eindeutiges starkes Passwort für den Schlüssel haben.

Werden wir bei diesem Ansatz auf Probleme stoßen?

Einige andere Ideen:

• Verwenden Sie die gleiche Schlüsseldatei für alle Projekte über Lösungen. Wird uns das leichter machen? Ist das eine schlechte Idee? Ist es überhaupt möglich?
• Sollte jedes Projekt seinen eigenen eindeutigen Schlüssel haben? Warum Warum nicht?

Jeder Eingang, gute/schlechte Erfahrungen und Empfehlungen sind willkommen. :)

Answer 1

In der Vergangenheit habe ich einen einzelnen Schlüssel für mehrere Lösungen und Projekte sehr effektiv verwendet. Es ist ein einfacher Ansatz, der sicherstellt, dass nur Personen mit Zugriff auf die private Schlüsseldatei einen Build veröffentlichen können, der die Prüfung des starken Namens besteht.

Hinweis: Um die einzelne Schlüsseldatei zu verwenden, fanden wir es am einfachsten, die Datei als Verknüpfung zu jedem Projekt hinzuzufügen.

Der einzige Nachteil, den ich sehe, ist, dass die Schlüsseldatei für Ihre Entwickler bedeutet, dass es nicht so privat ist, wie es sein sollte. Im Idealfall sollten so wenige Personen wie möglich (zB nur der Build-Prozess) Zugriff auf das Passwort haben.

Der Single-File-Ansatz hält die Verwaltung der Schlüssel einfach (es gibt nur einen), während die Vorteile der starken Benennung weiterhin berücksichtigt werden.

Answer 2

Wir verwenden derzeit den gleichen starken Schlüssel (.SNK) für jedes Projekt in unserer Lösung. Abhängig von Ihrem Projekt verwalten Sie unterschiedliche Schlüssel für jedes Projekt.

Wenn Sie höhere Sicherheit wünschen, können Sie den Schlüssel für jedes Projekt neu erstellen, aber es wird ein Albtraum sein, zu verwalten. Denken Sie daran, dass der SNK am Ende des Tages nur zeigt, dass der Code von Ihrem Unternehmen stammt, und verhindert, dass die Assemblies geändert werden. Dies ist kein großes internes Sicherheitsmerkmal.

Dafür sollten Sie Ihre Quellcodeverwaltung beschränken und mit einem Build-Server etc. aussehen, wenn Sie nicht vertrauen/nicht wollen, dass die Entwickler Code erstellen.

Answer 3

Sie können den starken Namensschlüssel auch in einem Ordner auf Stammebene auf der gleichen Ebene wie alle Projektordner behalten. Wenn Sie diese Datei in den Projekteigenschaften -> Registerkarte "Signieren" auswählen, wird die Schlüsseldatei in den Projektordner kopiert. Löschen Sie diese Datei. Öffnen Sie die .csproj-Datei im Editor.Suchen Sie nach dem folgenden Tag mykey.snk Manuell den Pfad der Schlüsseldatei bearbeiten, stellen Sie sicher, dass Sie einen relativen Pfad aus Projektordner angeben. Speicher die Datei. Öffnen Sie nun die Projekteigenschaften in Visual Studio. Sie können den Pfad so anzeigen, dass er auf den korrekten Speicherort verweist.