Есть ли способ автоматически генерировать дополнительные зависимости для пользовательской сборки в Visual Studio?

У меня есть пользовательский шаг сборки в решении Visual Studio 2013. Шаг пользовательской сборки вызывает скрипт Python для текстового файла, который ссылается на несколько других файлов в моем решении. Я хочу, чтобы пользовательский этап сборки вызывался всякий раз, когда изменяется какой-либо из этих файлов или когда отсутствует вывод моего скрипта. Однако я не хочу вручную поддерживать поля «дополнительные зависимости» и «выходные данные» пользовательского инструмента.

Я могу легко заставить скрипт генерировать список зависимостей так же, как gcc может генерировать файл .d при передаче в -MM. Есть ли способ использовать вывод .d моего скрипта для автоматического заполнения «Дополнительных зависимостей» на моем шаге пользовательской сборки? Есть ли другой способ избежать сохранения полей «дополнительные зависимости» и «выходные данные»?

На странице справки показано только, как добавлять отдельные файлы.


visual-studio visual-studio-2013 custom-build-step
person Carlos Pinto Coelho    schedule 18.03.2013    source источник

Ответы (1)


arrow_upward
10
arrow_downward

Предполагая, что ваш сценарий для создания .d файлов может генерировать файлы в любом желаемом формате, вы должны быть в состоянии достичь нужных вам результатов с помощью Import:

  1. Напишите сценарий, который создает небольшой файл проекта вместо файла .d. Результатом вашего сценария будет небольшой файл проекта, содержащий поля «дополнительные зависимости» и «выходные данные».
  2. Используйте тег Import, чтобы сделать сгенерированный файл зависимостью вашего основного проекта.
  3. Запускайте скрипт по мере необходимости, когда изменяется состав ваших зависимостей.

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

person Sergey Kalinichenko    schedule 10.06.2014
comment
Вы действительно считаете, что сценарий, который создает вторичный файл проекта для последующего импорта его из основного проекта, является более простым подходом, чем просто программное добавление необходимых зависимостей в основной XML-файл проекта?? - person Pat; 10.06.2014
comment
@Pat Почему, я не думаю, я знаю точно, что этот подход намного чище и намного стабильнее в долгосрочной перспективе. - person Sergey Kalinichenko; 11.06.2014
comment
при всем уважении ваш ответ не хорош; вы предлагаете программно создать новый проект для импорта проекта, для импорта зависимостей с ним; мой ответ напрямую добавляет зависимости в основной файл проекта; Я думаю, что ваш ответ не конкурирует с моим; вы только что взяли часть моей и сделали ее более запутанной и сложной. - person Pat; 11.06.2014
comment
@ Пэт, я почистил комментарии, потому что они выходили из-под контроля. Если у вас есть проблема, пожалуйста, сообщите об этом в чат или поднимите ее на Meta. Пожалуйста, не продолжайте спорить об этом здесь, это неконструктивно, и вы высказали свою точку зрения в оставшихся комментариях. - person Taryn; 11.06.2014