Erste Inhaltsdateien und Primary Output programmatisch

StackOverflow https://stackoverflow.com/questions/811691

  •  03-07-2019
  •  | 
  •  

Frage

Aus irgendeinem Grund haben wir ein Skript, das Batch-Dateien erstellt unsere kompilierten Assemblys XCOPY, Konfigurationsdateien und verschiedene andere Dateien auf einer Netzwerkfreigabe für unsere Beta-Tester. Wir machen einen Installer, aber einige haben nicht die erforderlichen Berechtigungen für das Installationsprogramm ausführen, oder sie laufen über Citrix.

Wenn Sie alle über Ihren Schreibtisch erbrochen auf die Erwähnungen von XCOPY und Citrix, verwenden Sie es als Vorwand früh nach Hause zu gehen. Nichts zu danken.

Der Code hat derzeit Hunderte von Zeilen wie: 

CreateScripts(basePath, "Client", outputDir, FileType.EXE | FileType.DLL | FileType.XML | FileType.CONFIG);

Es wird verwendet, schlechter zu sein, mit 20 int Parameter (eine pro Dateityp) darstellt, ob oder nicht diesen Dateityp in das Ausgabeverzeichnis kopiert werden.

Diese Hunderte von Zeilen erstellen Upload / Download-Batch-Dateien mit Tausenden von XCOPY Linien. In unseren Setup-Projekten können wir Dinge wie „Primäre Ausgabe von Client“ und „Content Dateien von Client“ verweisen. Ich würde gerne in der Lage sein, dass von einem nicht-Setup-Projekt programmatisch zu tun, aber ich bin ratlos.

Offensichtlich MS tut es, entweder über eine API oder durch die CSPROJ Dateien Parsen. Wie würde ich mich über das tun dies? Ich bin nur der Suche nach einer Möglichkeit, eine Liste von Dateien für alle Setup-Kategorien zu erhalten, das heißt:.

  • Primary Output
  • Lokalisierte Ressourcen
  • Inhaltsdateien
  • Dokumentationsdateien

Bearbeiten : Ich habe ein Setup-Projekt wie Hath vorgeschlagen, und es ist auf halbem Weg zu dem, was ich suche. Das einzige Problem, dass die Beibehaltung von einer perfekten Lösung ist, dass mehrere Projekte hängen von den gleichen Baugruppen in einem eigenen Ordner zu sein, und das Setup wird die Datei nur einmal kopiert werden.

Beispiel:

Projekte Admin, Client und Server alle auf ExceptionHandler.dll verlassen, und Admin und Kunde sowohl auf Util.dll verlassen, während Server nicht der Fall ist. Dies ist, was ich suche:

  • Admin
    • Admin.exe
    • Admin.exe.config
    • ExceptionHandler.dll
    • Util.dll
  • Client
    • Client.exe
    • Client.exe.config
    • ExceptionHandler.dll
    • Util.dll
  • Server
    • Server.exe
    • Server.exe.config
    • ExceptionHandler.dll

Da die referenzierten Baugruppen sind alle gleich, was ich bekommen, ist dies:

  • Admin
    • Admin.exe
    • Admin.exe.config
    • ExceptionHandler.dll
    • Util.dll
  • Client
    • Client.exe
    • Client.exe.config
  • Server
    • Server.exe
    • Server.exe.config

Dies bewirkt eine FileNotFoundException, wenn entweder Client oder Server nicht einer der beiden DLLs finden es erwartet.

Gibt es eine Setup-Eigenschaft I fehlen bin es immer die Ausgabe machen kopieren, auch wenn es in einem anderen Projekt der Ausgabe an anderer Stelle kopiert wird?

Erneut bearbeiten : Alle referenzierten DLLs sind "Copy Local" gesetzt, und immer gewesen. Ich fand einen anständigen Artikel über mit NAnt und XSLT die Liste der Dateien greifen , das kann so eine mögliche Lösung als auch sein, wie neouser99 vorgeschlagen.

akzeptierte Lösung : Ich bin ziemlich viel zurück, wo ich angefangen hat. Alle EXE- und DLL-Ausgänge werden in ein Verzeichnis „bin“ im Setup-Projekt gesteckt, lose verpackt. Die anderen pro-Anwendungsordner enthalten Verknüpfungen zu der ausführbaren Datei in diesem Verzeichnis.

Der Unterschied ist jetzt, ich werde eine benutzerdefinierte Aktion für den Installateur hinzufügen Reflexion zu verwenden, um die Abhängigkeiten für jede ausführbare Ausgabe aufzuzählen, und die EXE und DLL-Dateien auf die einzelnen Verzeichnisse kopieren. Wenig Schmerzen, wie ich war nur angenommen, es eine Möglichkeit, programmatisch zu erkennen, welche Dateien würden über einige Setup-Bibliothek aufgenommen werden.

War es hilfreich?

Lösung

warum nicht ein anderes Setup-Projekt verwenden und nur die ‚Paketdateien‘ Einstellung als lose unkomprimierte Dateien (Setup-Ausbau-> Eigenschaften) eingestellt? dann den Ordner teilen .. oder so.

edit:

Ich sehe, Sie haben 3 Ordner für die Ausgänge. aber das Setup-Projekt erkennt nur den ExceptionHandler.dll und Util.dll einmal, so wird es nur die ersten Ordner auswählen und legt es dort.

Sie können für jedes Projekt ein Setup-Projekt tun - etwas nervig vielleicht ..

Sie können manuell in den DLL zu den Projekten hinzufügen, die die Assembly fehlen indem sie entweder in der Datei des Hinzufügen von ‚Datei hinzufügen‘ oder ‚hinzufügen Assembly‘ oder ‚Projektausgaben‘, wenn Sie die Projekte in der gleichen Lösung haben .. (ich bezweifle, dass der Fall ist, obwohl).

oder nur Dump alle von ihnen in ein Ausgabeverzeichnis ...

Andere Tipps

Obwohl es als Build-Tool entwickelt hat, finden Sie vielleicht NAnt als äußerst nützlich, was Sie sind sprechen über. Die Aufgaben (Build, kopieren, verschieben, löschen, etc.), die Sie für sehr feinkörnig Datei Lookups ermöglichen definieren können, bis zu allgemeinen vollständige Ordner. Wenn Sie auch NAnt in Ihren Build-Prozess integrieren, glaube, ich könnte Sie feststellen, dass es in vielerlei Hinsicht hilft heraus dann ein.

Ein weiterer Ansatz, der für mich in der Vergangenheit gearbeitet hat, ist die gemeinsam genutzte Ressource (Assembly, DLL oder Projekt) als Verweis auf jede der Admin, Server und Client-Projekten hinzuzufügen. Dann öffnen Sie das Fenster Eigenschaften für das referenzierte Element in jedem Projekt und stellen Sie „Copy Local“ auf true gesetzt.

Wenn Sie nun die Projekte, bei denen jeweils seine eigene Instanz der Assembly in seine Ausgabeordner kopiert haben.

Dies sollte auch dazu führen, die gemeinsam genutzten Komponenten auf diese Weise hinzugefügt in jedem des Ausgabeordners in dem Setup-Paket repliziert werden.

Ein völlig anderer Ansatz könnte sein, sich als symbolische Links auf der Netzwerkfreigabe einzurichten. Ein symbolischer Link ist im Grunde eine Abkürzung wo die Datei-System die Tatsache versteckt, dass es eine Abkürzung ist, so dass alle anderen Anwendungen glaubt tatsächlich, dass die Datei ( http://en.wikipedia.org/wiki/NTFS_symbolic_link ).

Ein Vorteil dieses Ansatzes besteht darin, dass die Datei sofort als die Dateiänderungen aktualisiert wird, und nicht nur, wenn Sie Ihre Projekte bauen. Also, wenn Sie zB mit einem Text-Editor eine der config-Dateien speichern das Update sofort angewendet wird.

Der folgende MSBuild-Skript Teil Ihrer SLN-Datei erstellen kann (Sie es mit CSPROJ ersetzen können) und eine Liste aller Projekte berichten, die gebaut wurden (DLLs, EXE-Dateien). 

 <MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">
    <Output TaskParameter="TargetOutputs"
                ItemName="AssembliesBuilt" />
    </MSBuild>

Nun, bedeutet dies nicht wirklich lösen Ihr Problem, aber es wird Ihnen eine Liste von allem, was zu bauen war. Sie haben auch Copylocal, so könnte man wahrscheinlich nur AssembiesBuild nehmen und alle DLL und .CONFIG Dateien von dort kopiert werden.

Beispiel:

AssembliesBuild = c: \ myproj \ something1 \ build.dll

würden Sie gehen Sie zu c: \ myproj \ something1 \ und suchen Sie einfach für alle * .dll und * .config-Dateien und schließen sie. Sie können dies ziemlich leicht mit MSBuild oder Powershell, wenn Sie es installiert haben. Zur Ausgabe von MSBuild einem XCOPY Skript, ich glaube, Sie MSBuild contrib projct installiert benötigen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top