Ottenere file di contenuto e output primario a livello di codice

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

  •  03-07-2019
  •  | 
  •  

Domanda

Per qualche motivo, abbiamo uno script che crea file batch per XCOPY i nostri assembly compilati, file di configurazione e vari altri file in una condivisione di rete per i nostri beta tester. Abbiamo un programma di installazione, ma alcuni non dispongono delle autorizzazioni necessarie per eseguire il programma di installazione o sono in esecuzione su Citrix.

Se hai vomitato su tutta la scrivania alle menzioni di XCOPY e Citrix, usalo come scusa per tornare a casa presto. Prego.

Al momento il codice ha centinaia di righe come: 

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

Era peggio, con 20 parametri int (uno per tipo di file) che indica se copiare quel tipo di file nella directory di output.

Queste centinaia di linee creano file batch di upload / download con migliaia di linee XCOPY. Nei nostri progetti di installazione, possiamo fare riferimento a cose come "output primario dal client" e "File di contenuto dal client". Mi piacerebbe poterlo fare in modo programmatico da un progetto non impostato, ma sono in perdita.

Ovviamente MS lo fa, usando un'API o analizzando i file .csproj. Come potrei fare per fare questo? Sto solo cercando un modo per ottenere un elenco di file per una delle categorie di installazione, ovvero:

  • Output primario
  • Risorse localizzate
  • File di contenuti
  • File di documentazione

Modifica : Ho un progetto di installazione come ha suggerito Hath, ed è a metà strada per quello che sto cercando. L'unico problema che impedisce di essere una soluzione perfetta è che più progetti dipendono dal fatto che gli stessi assembly si trovano nella propria cartella e il programma di installazione copia il file solo una volta.

Esempio:

Progetti Admin, Client e Server si basano tutti su ExceptionHandler.dll e Admin e Client si basano entrambi su Util.dll, mentre Server no. Questo è quello che sto cercando:

  • 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

Dato che gli assembly referenziati sono tutti uguali, quello che ottengo è questo:

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

Ciò provoca un FileNotFoundException quando Client o Server non riescono a trovare una delle due DLL che si aspetta.

C'è una proprietà di installazione che mi manca per farla sempre copiare l'output, anche se è duplicato altrove nell'output di un altro progetto?

MODIFICA DI NUOVO : tutte le DLL di riferimento sono impostate su " Copia locale " ;, e lo sono sempre state. Ho trovato un articolo decente su utilizzando NAnt e XSLT per prendere l'elenco dei file , quindi potrebbe essere anche una possibile soluzione, come suggerito da neouser99.

SOLUZIONE ACCETTATA : sono praticamente tornato da dove ho iniziato. Tutte le uscite .exe e .dll sono inserite in un "bin" directory nel progetto di installazione, impacchettata. Le altre cartelle per applicazione contengono collegamenti all'eseguibile in quella directory.

La differenza ora è, ho intenzione di aggiungere un'azione personalizzata al programma di installazione per utilizzare reflection, enumerare le dipendenze per ciascun output eseguibile e copiare i file .exe e .dll in directory separate. Un po 'una seccatura, dato che ho appena pensato che ci fosse un modo per rilevare programmaticamente quali file sarebbero stati inclusi tramite una libreria di installazione.

È stato utile?

Soluzione

perché non usare un altro progetto di installazione e impostare semplicemente 'File pacchetto' su Come file non compressi come sciolti (proprietà del progetto di installazione >)? quindi condividi la cartella ... o qualcosa del genere.

modifica:

Vedo, hai 3 cartelle per le tue uscite. ma il progetto di installazione rileva ExceptionHandler.dll e Util.dll solo una volta, quindi sceglierà solo la prima cartella e la metterà lì.

Potresti fare un progetto di installazione per ogni progetto - un po 'fastidioso forse ..

È possibile aggiungere manualmente le DLL ai progetti in cui manca l'assembly o aggiungendo nel file 'aggiungi file' o 'aggiungi assembly' o 'aggiungi output del progetto' se hai quei progetti nella stessa soluzione .. (dubito che sia il caso però).

o scaricali tutti in una directory di output ...

Altri suggerimenti

Sebbene sia progettato come strumento di creazione, potresti trovare NAnt per essere estremamente utile in quello che sei parlare di. Le attività (compilazione, copia, spostamento, eliminazione, ecc.) Che è possibile definire consentono ricerche di file molto dettagliate, fino a cartelle complete e generali. Se includi anche NAnt nel tuo processo di compilazione, penso che potresti scoprire che aiuta in più modi di uno.

Un altro approccio che ha funzionato per me in passato è quello di aggiungere la risorsa condivisa (assembly, DLL o progetto) come riferimento a ciascuno dei progetti di amministrazione, server e client. Quindi apri il pannello delle proprietà per l'elemento di riferimento in ciascun progetto e imposta " Copia locale " su true.

Ora quando costruisci i progetti, ognuno avrà la propria istanza dell'Assemblea copiata nella sua cartella di output.

Ciò dovrebbe anche causare la replica dei componenti condivisi aggiunti in questo modo in ciascuna delle cartelle di output nel pacchetto di installazione.

Un approccio completamente diverso potrebbe essere quello di configurarli come collegamenti simbolici sulla condivisione di rete. Un collegamento simbolico è fondamentalmente una scorciatoia in cui il file system nasconde il fatto che è una scorciatoia, quindi tutte le altre applicazioni credono davvero che il file sia stato copiato ( http://en.wikipedia.org/wiki/NTFS_symbolic_link ).

Un vantaggio di questo approccio è che il file viene aggiornato immediatamente quando il file cambia e non solo quando si creano i progetti. Quindi, ad esempio, quando si salva uno dei file di configurazione con un editor di testo, l'aggiornamento viene applicato immediatamente.

La seguente parte dello script MSBuild può creare il tuo file SLN (puoi sostituirlo con .csproj) e riporterà un elenco di tutti i progetti che sono stati creati (DLL, EXE). 

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

Ora, questo non risolve davvero il tuo problema, ma ti fornisce un elenco di tutto ciò che è stato creato. Hai anche copylocal, quindi probabilmente potresti semplicemente prendere AssembiesBuild e copiare tutti i file DLL e .CONFIG da lì.

Esempio:

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

andresti su c: \ myproj \ something1 \ e cerchi semplicemente tutti i file * .dll e * .config e includili. Puoi farlo abbastanza facilmente con MSBuild o PowerShell, se lo hai installato. Per generare uno script XCOPY da MSBuild, penso che avrai bisogno del progetto contrib di MSBuild installato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top