Obtention de fichiers de contenu et d'une sortie principale par programme

Question

Pour une raison quelconque, nous avons un script qui crée des fichiers de commandes dans XCOPY nos assemblys compilés, des fichiers de configuration et divers autres fichiers sur un partage réseau pour nos testeurs bêta. Nous avons un programme d’installation, mais certains n’ont pas les autorisations nécessaires pour l’exécuter ou s’exécutent sur Citrix.

Si vous avez vomi sur votre bureau en mentionnant XCOPY et Citrix, utilisez-le comme excuse pour rentrer chez vous plus tôt. De rien.

Le code contient actuellement des centaines de lignes telles que:

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

Auparavant, la situation était pire, avec 20 paramètres int (un par type de fichier) indiquant s'il fallait ou non copier ce type de fichier dans le répertoire de sortie.

Ces centaines de lignes créent des fichiers de commandes de téléchargement avec des milliers de lignes XCOPY. Dans nos projets de configuration, nous pouvons référencer des éléments tels que "Sortie principale du client". et "Fichiers de contenu du client". J'adorerais pouvoir le faire par programme à partir d'un projet non configuré, mais je suis perdu.

Évidemment, MS le fait, en utilisant une API ou en analysant les fichiers .csproj. Comment pourrais-je m'y prendre? Je cherche simplement un moyen d'obtenir une liste de fichiers pour l'une des catégories d'installation, c'est-à-dire:

.

• Sortie primaire
• Ressources localisées
• Fichiers de contenu
• Fichiers de documentation

MODIFIER : J'ai un projet d'installation comme suggéré par Hath, et c'est à mi-chemin de ce que je recherche. Le seul problème qui empêche que cette solution soit parfaite est que plusieurs projets dépendent des mêmes assemblys dans leur propre dossier et que le programme d'installation ne copie le fichier qu'une seule fois.

Exemple:

Les projets Admin, Client et Server reposent tous sur ExceptionHandler.dll, et Admin et Client s'appuient tous deux sur Util.dll, contrairement à Server. Voici ce que je recherche:

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

Puisque les assemblys référencés sont tous identiques, voici ce que je reçois:

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

Cela provoque une exception FileNotFoundException lorsque Client ou Serveur ne parvient pas à trouver l'une des deux DLL attendues.

Existe-t-il une propriété d'installation qui me manque pour que le résultat soit toujours copié, même s'il est dupliqué ailleurs dans le résultat d'un autre projet?

MODIFIER À NOUVEAU : toutes les DLL référencées sont définies sur "Copier en local" et ont toujours été conservées. J'ai trouvé un article décent sur en utilisant NAnt et XSLT pour récupérer la liste des fichiers , c'est donc une solution possible, comme suggéré par neouser99.

SOLUTION ACCEPTE : Je suis pratiquement de retour là où j'ai commencé. Toutes les sorties .exe et .dll sont placées dans un "bin". répertoire dans le projet d'installation, emballé de manière lâche. Les autres dossiers par application contiennent des raccourcis vers l'exécutable de ce répertoire.

La différence est maintenant que je vais ajouter une action personnalisée à l’installateur pour utiliser la réflexion, énumérer les dépendances de chaque sortie d’exécutable et copier les fichiers .exe et .dll dans des répertoires distincts. Un peu pénible, car je pensais qu'il y avait un moyen de détecter par programme quels fichiers seraient inclus via une bibliothèque d'installation.

Answer 1

Pourquoi ne pas utiliser un autre projet de configuration et définir simplement le paramètre "Fichiers de package" sur "Fichiers en vrac non compressés (propriétés du projet de configuration>)?" puis partager le dossier .. ou quelque chose.

modifier:

Je vois, vous avez 3 dossiers pour vos sorties. mais le projet d'installation ne détecte qu'une seule fois les fichiers ExceptionHandler.dll et Util.dll. Il choisit donc le premier dossier et le place dans celui-ci.

Vous pouvez faire un projet d'installation pour chaque projet - peu ennuyeux peut-être ..

Vous pouvez ajouter manuellement les dll aux projets pour lesquels l'assembly manque soit en ajoutant dans le fichier par 'ajouter un fichier' ou 'ajouter un assemblage' ou par 'ajouter une sortie de projet' si vous avez ces projets dans la même solution .. (je doute que ce soit le cas cependant).

ou simplement les vider dans un seul répertoire de sortie ...

Answer 2

Bien qu'il soit conçu comme un outil de construction, vous pouvez trouver NAnt extrêmement utile dans votre vie. parler de. Les tâches (création, copie, déplacement, suppression, etc.) que vous pouvez définir permettent des recherches de fichiers très détaillées, allant jusqu’à des dossiers complets. Si vous intégrez également NAnt dans votre processus de création, je pense que vous constaterez que cela aide à plus d'un titre.

Answer 3

Une autre approche qui a fonctionné pour moi par le passé consiste à ajouter la ressource partagée (Assembly, DLL ou projet) en tant que référence à chacun des projets Admin, Server et Client. Ouvrez ensuite le panneau de propriétés de l’élément référencé dans chaque projet et définissez l'option "Copier local". à vrai.

Maintenant, lorsque vous construisez les projets, chacun aura sa propre instance de l’Assemblée copiée dans son dossier de sortie.

Cela devrait également entraîner la réplication des composants partagés ajoutés de cette manière dans chacun des dossiers de sortie du package d'installation.

Answer 4

Une approche complètement différente pourrait être de les configurer en tant que liens symboliques sur le partage réseau. Un lien symbolique est fondamentalement un raccourci où le système de fichiers cache le fait qu'il s'agit d'un raccourci. Ainsi, toutes les autres applications pensent en fait que le fichier a été copié ( http://fr.wikipedia.org/wiki/NTFS_symbolic_link ).

L'un des avantages de cette approche est que le fichier est mis à jour immédiatement au fur et à mesure de ses modifications, et pas uniquement lors de la construction de vos projets. Ainsi, lorsque vous enregistrez par exemple l'un des fichiers de configuration avec un éditeur de texte, la mise à jour est appliquée immédiatement.

Answer 5

La partie de script MSBuild suivante peut générer votre fichier SLN (vous pouvez le remplacer par .csproj) et affichera une liste de tous les projets générés (Dll, EXE).

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

Cela ne résout pas vraiment votre problème, mais vous obtenez une liste de tout ce qui a été construit. Vous avez également copylocal, vous pouvez donc probablement simplement assembiesBuild et copier tous les fichiers DLL et .CONFIG à partir de là.

Exemple:

AssembliesBuild = c: \ myproj \ quelque chose \ \ build.dll

vous iriez à c: \ myproj \ quelque chose1 \ et chercheriez simplement tous les fichiers * .dll et * .config et les inclure. Vous pouvez le faire assez facilement avec MSBuild ou powershell, si vous l'avez installé. Pour générer un script XCOPY à partir de MSBuild, je pense que vous devez installer le projet contrib contrib MSBuild.