2009-08-17 3 views
2

Ich habe ein paar Excel 2003/2007 Add-Ins mit VSTO geschrieben, und ich am Ende referenzieren .NET DLLs im VSTO-Projekt (in der Regel Code, den ich über Projekte wiederverwenden).
Ich stieß auf das folgende Problem. Während die Aufrufe der DLL im Debug-Modus oder auf dem Entwicklungscomputer einwandfrei funktionieren, wird die DLL beim Hinzufügen des Add-Ins über ein MSI-Installationsprogramm zum Ordner des Add-Ins hinzugefügt, das Add-In jedoch nicht scheinen die dll anrufen zu können.
Nach einigen Schwierigkeiten habe ich einen Weg gefunden: Neben der benutzerdefinierten Aktion im Installationsprogramm, die dem Add-In Sicherheit gewährt, füge ich eine weitere benutzerdefinierte Aktion hinzu, die jeder einzelnen DLL, die vom Add-In aufgerufen wird, Sicherheit gewährt die Schritte, die in
http://msdn.microsoft.com/en-us/library/bb332052.aspxWie wird eine referenzierte Assembly zur Bereitstellung eines VSTO-Projekts hinzugefügt?

Mein Problem ist, dass, während es funktioniert, ich nicht überzeugt bin, dass ich es richtig mache. Es ist super-langweilig, und ich bekomme auch eine Warnung, wenn ich baue, was von dem, was ich machen kann, tatsächlich darauf hinweist, dass die Sicherheit zweimal am selben Ort gewährt wird.
Jeder hier kann mir sagen, ob ich es richtig mache oder nicht, und was ist der bessere Weg, wenn es einen gibt?

Antwort

1

In meinem Fall habe ich eine Reihe von Add-Ins unter MyCompany.Office.

Ich habe eine gemeinsame Bibliothek der Kernfunktionalität namens MyCompany.Office.dll, die von MyCompany.Office.Word.dll und MyCompany.Office.Excel.dll referenziert wird, die beide Add-Ins sind (Sie könnten leicht haben mehrere Add-Ins für Excel statt eines für Word und eines für Excel oder was auch immer Sie wollen).

Was ich getan habe, war eine starke Namen-Keyfile für die Lösung zu erstellen und verknüpfte es in allen drei Projekten. Ich habe dann alle drei Bibliotheken mit dem gleichen starken Namen Keyfile signiert.

Ich erstellte dann eine Installer-Aktion, die einen CAS-Eintrag mit dem öffentlichen Schlüssel als Beweis und nicht als Speicherort der Datei hinzufügt. Meine benutzerdefinierte Aktion ruft also letztendlich caspol.exe -m -q -ag "My_Computer_Zone" -strong -hex <my public key> -noname -noversion FullTrust -n "MyCompany_Office" -d "Code group for MyCompany.Office add-ins." auf. Dies gibt FullTrust für alle Bibliotheken mit diesem öffentlichen Schlüssel an.

Sie können den öffentlichen Schlüssel anzeigen, indem Sie eine Eingabeaufforderung öffnen, zum Speicherort der Schlüsseldatei navigieren und sn -Tp mykeyfile.snk eingeben. Wenn Sie den öffentlichen Schlüssel pro grammatisch (wie erstreckt setSecurity) erhalten möchten, können Sie folgenden Code verwenden:

private static String GetPublicKeyHexString(String assemblyPath) 
{ 
    AssemblyName assmName = Assembly.LoadFile(assemblyPath).GetName(); 
    StringBuilder output = new StringBuilder(); 
    Byte[] publicKey = assmName.GetPublicKey(); 

    foreach(Byte byte in publicKey) 
    { 
     output.Append(byte.ToString("x").PadLeft(2, '0')); 
    } 

    return output.ToString(); 
} 
+0

Ich brauche das ausprobieren, bevor diese als gültige Antwort-Kennzeichnung, aber das sieht sinnvoll. – Mathias

+0

Sie können auch eine URL als Beweis verwenden und die URL zu Ihrem Installationsverzeichnis festlegen. Dadurch erhalten alle Assemblies in diesem Ordner FullTrust. Ich empfehle das jedoch nicht. Jemand könnte eine böswillige Assembly in Ihrem Installationsordner ablegen, die ihm volles Vertrauen schenkt, und dann könnte Ihnen jemand die Schuld an einer Sicherheitslücke geben. Ich erwähne das nur für den Fall, dass jemand es vorschlägt, damit Sie sehen, warum das keine gute Idee ist. – HackedByChinese

+0

Danke, ich glaube es funktioniert. Ich fand diesen Beitrag tatsächlich im msdn-Forum, das eine kleine Modifikation des SetSecurity-Projekts vorschlägt, die es erlaubt, eine durch Kommas getrennte Liste von DLLs anstelle einer einzelnen DLL (Lex007-Beitrag im Thread) hinzuzufügen. Auf diese Weise müssen Sie nicht den gleichen Schlüssel teilen. http://social.msdn.microsoft.com/forums/en-US/vsto/thread/cec6abb6-4716-4bde-91f2-25fb68abd54e/ – Mathias

Verwandte Themen