Ich versuche ein Plugin (eigentlich ein Visual Studio Template Wizard, der das Plugin generiert) für eine existierende Anwendung zu schreiben. Im Rahmen der Plugin-Installation muss ich Einträge in eine Konfigurationsdatenbank einfügen. Häufig gibt es mehrere DLLs, die verschiedenen Teilen der Funktionalität entsprechen, wobei manchmal jeweils Einträge in den gleichen Tabellen erforderlich sind, aber normalerweise mit verschiedenen Kombinationen von Tabelleneinträgen. Ich muss diese von meinem Installer hinzufügen.
Alles ist aus politischen Gründen in C #.
Ich verwende derzeit Visual Studio Installer (VS2010) um das Installationsprogramm zu erstellen. Ich würde es vorziehen, etwas zu verwenden, das wahrscheinlich auf dem Computer des Benutzers installiert wird, um die Installation des Templates / Wizards einfach zu halten, aber ich könnte (falls notwendig) eine Open-Source- (oder zumindest frei vertreibbare) Alternative bündeln / ketten Installer.
Um beispielsweise einen Menüeintrag zur Anwendung hinzuzufügen, muss ich Einträge in ein paar Tabellen einfügen. In der Vergangenheit habe ich dies mithilfe eines Installer-Helfers (manchmal eine Anwendung, manchmal ein Installer-Klasse ), die von der Installer-Anwendung aufgerufen wird. In diesem Entwurf würde ich die Einstellungen, die ich den Konfigurationstabellen hinzufügen muss, in den Installer-Helper einbetten und dann SQL (über C # :-)) ausführen, um das Hinzufügen tatsächlich durchzuführen.
Das Problem ist, dass dies dazu führt, dass dieselben Informationen an zwei Stellen wiederholt werden, und dass es in einer Assistentenumgebung nicht sehr wartbar oder sauber ist. Ich würde diese Informationen lieber von einigen Attributen aus betrachten, die ich in den Plug-in-Assemblies einstellen kann.
Ich bin jedoch über den ersten Schritt gestolpert - wie kann meine Installer-Klasse herausfinden, welche Assemblies durch diese Installation installiert wurden (oder werden)?
Ich habe erwogen, die Liste der DLLs in eine benutzerdefinierte Installer-Eigenschaft einzubetten, aber das wird auch von meinem Plugin-Assistenten schwer zu generieren sein. Idealerweise würde es ein existierendes Ereignis geben, für das ich mich registrieren kann, oder eine existierende Eigenschaft, die ich lesen kann, aber ich habe es noch nicht entdeckt.
Ich weiß nicht genau, was zwischen dem Ausführen des Assistenten und dem Anzeigen der .msi-Datei passiert. (Ist die Ausgabe des Assistenten ein VS-Projekt oder die .msi selbst [in diesem Fall würde der Endbenutzer VS überhaupt nicht benötigen]?) Aber, fangen wir an ...
Ihr Flaschenhals scheint der Visual Studio Installer zu sein. Es ist auch eine Zeitbombe, weil es mit VS2010 sterben wird. Viele Projekte (z. B. Visual Studio selbst) verwenden stattdessen das WiX-Toolset. Für Benutzer von Visual Studio und SharpDevelop wird WiX "wahrscheinlich auf dem Computer des Benutzers installiert" und ist "Open Source". Es ist als Binärdateien verfügbar, die Sie in Ihren Assistenten aufnehmen können, oder das vollständige Produkt kann (einschließlich einer VS-Erweiterung) von NuGet, Chocolatey oder exe von oder für den Benutzer installiert werden.
Mit WiX schreiben oder generieren Sie XML-Dateien, die den Inhalt, die Benutzeroberfläche und die Aktionsfolge eines Windows Installer-Pakets beschreiben. WiX-Executables werden aufgerufen, um den eigentlichen Build auszuführen. Wenn Sie die MSBuild-Dateien von WiX installieren, können Sie ein MSBuild-Projekt verwenden, um den Build zu orchestrieren. Wenn Sie die VS-Erweiterung von WiX installieren, können Sie das Projekt mit VS bearbeiten. (Ein modernes VS-Projekt ist ein MSBuild-Projekt.) MSBuild kommt mit .NET (bis zur nächsten Version, wo es ein separates Addon sein wird).
So kann der Assistent Dateien für WiX basierend auf Benutzereingaben und Daten von den Plugins generieren. Es kann auch das MSI bauen. Sie könnten Ihren Install Helper trotzdem verwenden, aber es wäre besser, die benutzerdefinierten SQL-Server-Aktionen von WiX zu verwenden (wenn diese in Ihrem Fall zutreffen), um die Deinstallation und das Upgrade zuverlässig zu unterstützen.
Da zumindest einige der Installations- und Konfigurationsdaten des Plugins von den Plugins stammen, können Sie die Plug-in-Projekte generieren, damit sie mit Ihrem Assistenten installiert werden können. WiX unterstützt das Platzieren von Informationen für separate Komponenten in separaten Dateien, sodass Sie keine kombinierte Datei für Ihren Assistenten verwalten müssen. Wenn die Informationen einfach sind, könnte der Autor des Plugins sie manuell pflegen. Andernfalls kann es bei der Bearbeitungszeit des Plugins oder der Buildzeit des Plugins generiert werden. Zur Bearbeitungszeit können Sie eine T4-Vorlage verwenden (Inhalt gemischt mit C # -Code). Während der Erstellung können Sie eine inline oder kompilierte benutzerdefinierte MSBuild-Task (in C # geschrieben) verwenden. [.csproj-Dateien sind MSBuild-Projekte.] Auch hier würde das Installationsprogramm des Assistenten die generierten Dateien zusammen mit der Plugin-DLL abrufen, um sie auf dem Computer zu installieren, auf dem der Assistent ausgeführt wird.
Sie können WiX auch zur Installation Ihres Assistenten verwenden. Wenn Ihr Assistent ein VSIX-Paket ist, verwenden Sie die benutzerdefinierte VSIX-Aktion von WiX. Verdammt, Sie könnten wahrscheinlich die Wix-Dateien für die Plugins sowohl für das Installationsprogramm des Assistenten als auch für das für den Benutzer erstellte Installationsprogramm verwenden.
Sie können die Windows Installer-API verwenden, um alle darin enthaltenen DLLs zu sichern ein bestimmtes MSI-Paket.
In C # stehen verschiedene Bibliotheken oder Beispielcode zur Verfügung.
Hier werde ich die Open-Source-DLLs des Wix-Toolsets Projekts verwenden. Sie müssen also nur die Binärdateien (nicht das Wix-Installationsprogramm) herunterladen, ein Projekt erstellen und Referenzen zu Microsoft.Deployment.WindowsInstaller.dll und Microsoft.Deployment.WindowsInstaller.Package.dl l in diesem Binärverzeichnis hinzufügen
Hier ist ein Beispielprogramm, das alle DLL-Dateien Teile des Pakets schreibt.
%Vor%}
Tags und Links c# visual-studio-2010 windows-installer