Получение файлов содержимого и первичного вывода программно

Question

По какой-то причине у нас есть скрипт, который создает пакетные файлы для XCOPY наших скомпилированных сборок, файлов конфигурации и различных других файлов для общего сетевого ресурса для наших бета-тестеров. У нас есть установщик, но у некоторых нет разрешений, необходимых для запуска установщика, или они работают в Citrix.

Если вас рвало по всему столу в связи с упоминаниями XCOPY и Citrix, используйте это в качестве предлога для раннего возвращения домой. Не за что.

Код в настоящее время имеет сотни строк, таких как:

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

Раньше было хуже, с 20 параметрами int (по одному на тип файла), представляющими, копировать или нет этот тип файла в выходной каталог.

Эти сотни строк создают файлы загрузки / выгрузки с тысячами строк XCOPY. В наших проектах установки мы можем ссылаться на такие вещи, как «Первичный вывод из клиента» и «Файлы содержимого из клиента». Я бы хотел сделать это программно из не-установочного проекта, но я в растерянности.

Очевидно, что MS делает это либо с помощью API, либо путем анализа файлов .csproj. Как бы я поступил так? Я просто ищу способ получить список файлов для любой из категорий установки, т. Е .:

• Первичный выход
• Локализованные ресурсы
• Файлы содержимого
• Файлы документации

EDIT : У меня есть проект установки, как предложил Хат, и он на полпути к тому, что я ищу. Единственная проблема, препятствующая тому, чтобы это было идеальным решением, состоит в том, что несколько проектов зависят от одинаковых сборок, находящихся в их собственной папке, и программа установки скопирует файл только один раз.

Пример: * * тысяча двадцать-восемь

Проекты Admin, Client и Server все полагаются на ExceptionHandler.dll, а Admin и Client оба полагаются на Util.dll, а Server - нет. Вот что я ищу:

• Администратор
  • Admin.exe
  • Admin.exe.config
  • ExceptionHandler.dll
  • Util.dll
• Клиент
  • Client.exe
  • Client.exe.config
  • ExceptionHandler.dll
  • Util.dll
• Сервер
  • Server.exe
  • Server.exe.config
  • ExceptionHandler.dll

Поскольку ссылочные сборки все одинаковые, я получаю следующее:

• Администратор
  • Admin.exe
  • Admin.exe.config
  • ExceptionHandler.dll
  • Util.dll
• Клиент
  • Client.exe
  • Client.exe.config
• Сервер
  • Server.exe
  • Server.exe.config

Это вызывает исключение FileNotFoundException, когда клиенту или серверу не удается найти одну из двух ожидаемых библиотек DLL.

Есть ли свойство настройки, которое мне не хватает, чтобы оно всегда копировало выходные данные, даже если они дублированы в другом месте в выходных данных другого проекта?

ВНОВЬ РЕДАКТИРОВАТЬ : Все библиотеки DLL, на которые есть ссылки, установлены на «Копировать локально» и всегда были такими. Я нашел приличную статью о с использованием NAnt и XSLT для получения списка файлов , так что это может быть и возможным решением, как предложил neouser99.

ПРИНЯТО РЕШЕНИЕ : Я почти вернулся к тому, с чего начал. Все выходные файлы .exe и .dll помещаются в каталог bin в проекте установки, свободно упакованный. Другие папки для приложений содержат ярлыки для исполняемого файла в этом каталоге.

Разница в том, что я собираюсь добавить в установщик настраиваемое действие для использования отражения, перечислить зависимости для каждого исполняемого файла и скопировать файлы .exe и .dll в отдельные каталоги. Немного боли, так как я только что предположил, что есть способ программно определить, какие файлы будут включены через некоторую библиотеку установки.

Answer 1

Хотя он спроектирован как инструмент для сборки, вы можете найти NAnt чрезвычайно полезным в том, о чем вы говорите. Задачи (создание, копирование, перемещение, удаление и т. Д.), Которые вы можете определить, позволяют осуществлять очень детальный поиск файлов, вплоть до общих, полных папок. Если вы также включите NAnt в свой процесс сборки, я думаю, вы обнаружите, что он помогает более чем одним способом.

Answer 2

Другой подход, который работал для меня в прошлом, заключается в добавлении общего ресурса (сборки, DLL или проекта) в качестве ссылки на каждый из проектов Admin, Server и Client. Затем откройте панель свойств для ссылочного элемента в каждом проекте и установите для параметра «Копировать локальный» значение true.

Теперь, когда вы создаете проекты, у каждого будет свой собственный экземпляр Assembly, скопированный в его выходную папку.

Это также должно привести к репликации общих компонентов, добавленных таким образом, в каждую из выходных папок в пакете установки.

Answer 3

Почему бы не использовать другой проект установки и просто установить для параметра «Пакетные файлы» значение Разблокировать несжатые файлы (настройка проекта-> свойства)? тогда поделитесь папкой .. или что-то.

редактирование:

Я вижу, у вас есть 3 папки для ваших выходов. но проект установки обнаруживает ExceptionHandler.dll и Util.dll только один раз, поэтому он просто выберет первую папку и поместит ее туда.

Вы могли бы сделать проект установки для каждого проекта - возможно, немного раздражает.

Вы можете вручную добавить в DLL к проектам, которые отсутствуют в сборке либо путем добавления в файл «добавить файл» или «добавить сборку», либо «добавить вывод проекта», если эти проекты находятся в одном решении ... (хотя я сомневаюсь, что это так).

или просто выгрузите их все в один выходной каталог ...

Answer 4

Следующая часть скрипта MSBuild может создать ваш файл SLN (вы можете заменить его на .csproj) и сообщит список всех созданных проектов (Dlls, EXE).

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

Теперь, это не решит вашу проблему, но даст вам список всего, что было собрано. У вас также есть copylocal, так что вы можете просто взять AssembiesBuild и скопировать все файлы DLL и .CONFIG оттуда.

Пример:

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

Вы перейдете в c: \ myproj \ что-то1 \ и просто найдете все файлы * .dll и * .config и включите их. Вы можете сделать это довольно легко с MSBuild или powershell, если он у вас установлен. Для вывода сценария XCOPY из MSBuild, я думаю, вам понадобится установленный проект MSBuild contrib.

Answer 5

Совершенно другой подход может заключаться в том, чтобы установить их в качестве символических ссылок на сетевом ресурсе. Символическая ссылка - это, по сути, ярлык, где файловая система скрывает тот факт, что это ярлык, поэтому все другие приложения фактически считают, что файл был скопирован (http://en.wikipedia.org/wiki/NTFS_symbolic_link).

Одним из преимуществ этого подхода является то, что файл обновляется немедленно по мере его изменения, а не только при сборке проектов. Так, например, когда вы сохраняете один из конфигурационных файлов в текстовом редакторе, обновление применяется немедленно.