2010-11-14 4 views
6

Die Situation ist wie folgt:Klassenbibliotheksquelle freigeben, ohne Schlüsseldatei signieren, aber Unit-Tests erfordert Zugriff auf interne Klassen, was zu tun ist?

  1. ich die volle Quelle zu einer Klassenbibliothek
  2. ich Binärdateien veröffentlichen von mir auch, unterzeichnet will freigeben will, mit einer Schlüsseldatei Ich will nicht Veröffentlichen
  3. Ich werde Batch-Dateien und Pre-Build-Stuetzen, die eine neue Schlüsseldatei lokal erstellt, wenn nicht vorhanden, so dass jeder schnell den Quellcode verwenden
  4. Das Testprojekt benötigt Verweis auf eine interne Klasse in das Hauptprojekt
  5. Um Zugriff auf die interne Klasse, ich brauche ein [assembly: InternalsVisibleTo("...")] Attribut zu den wichtigsten Projekt AssemblyInfo.cs hinzufügen
  6. Datei Da ich die Projektausgabe bin Unterzeichnung, ich brauche einen PublicKey Teil dieses Attribut angeben
  7. Dies wird dann an die gebunden werden Schlüsseldatei, die ich nicht veröffentlichen möchte

Also, wie löse ich das?

Wenn ich die Hauptprojektausgabe unterschreiben, und nicht die Testbibliothek, und nur den Namen der Assembly im InternalsVisibleTo Attribute angeben, bekomme ich diesen Fehler bei der Kompilierung:

Error 1 Friend assembly reference 'Mercurial.Net.Tests' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations. C:\Dev\VS.NET\Mercurial.Net\Mercurial.Net\Properties\AssemblyInfo.cs 22 31 Mercurial.Net

So offenbar nicht den Tests der Unterzeichnung Projektausgabe ist nicht genug.

Ist meine einzige Option, um die Einstellungen zu entfernen, die die Projekte signieren, und die Projektdateien als Teil meines Binaries Build-Skripts zu ändern? dh. jagen Sie das <SignAssembly>false</SignAssembly> Element der Projektdatei und modifizieren Sie es, bevor Sie bauen?

Antwort

2

Ist es eine Option, eine SNK-Datei zu haben, die Sie nur zum Testen freigeben?

können Sie haben dann zwei InternalsVisibleTo und Schalter, die man Sie mit einem #if verwenden, z.B .:

#if FOR_RELEASE 
[InternalsVisibleTo(... your private SNK ...)] 
#else 
[InternalsVisibleTo(... test SNK which you release ...)] 
#endif 

Sie dann FOR_RELEASE einstellen, wenn Sie erstellen Ihre Builds, die Sie veröffentlichen möchten.

+0

Ja, das klingt nach einem Plan. –

+0

Ich habe nur '#if DEBUG' verwendet, RELEASE-build benötigt nun meinen privaten Schlüssel, und ich kann diesen Teil einfach als Teil des Skripts skripten, das meine Binärdateien erzeugt. Ich bin sowieso noch nicht da, also kümmere ich mich später um diesen Teil. Gute Optionen von allen Antworten hier, aber dieses war was ich getan habe, so akzeptiert dies. –

+0

Nun, los gehts. Froh, dass ich helfen konnte. –

1

Was ich mit meinen OS-Projekten gemacht habe, ist einfach: Ich habe einen privaten SNK, den ich nur beim Erstellen der Projekte für ein Release verwende. Die Projekte werden nur signiert, wenn ich für ein Release kompiliere und normalerweise verweisen die Projekte nicht auf einen SNK. Dies erleichtert die Verwendung des Attributs InternalsVisibleTo, da dies ohne SNK immer funktioniert.

1

Ein #ifdef springt in den Sinn, mit einem "Eval" -Taste, die Sie nicht interessieren.