Программное создание пользовательского файла MSBuild .Targets

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

Мне нужно решение, которое запускается после успешной сборки библиотеки, чтобы я не получал неприятных ошибок при попытке вызвать свои пользовательские задачи из других проектов.

У меня есть несколько идей о том, как это сделать, но я хотел бы сначала посмотреть, что придумают другие. :-)


msbuild msbuild-4.0
person Sameer Singh    schedule 22.11.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

У вас может быть отдельный файл .targets, содержащий только ссылки на ваши задачи. С одной стороны, свяжите его в своем основном файле .targets. С другой стороны, перезапишите его, выполнив другую «основную» пользовательскую задачу в вашей AfterBuild цели решения задач. Эта «мастерская» задача получит все классы, реализующие ITask, из вновь созданной сборки и запишет их в файл .targets.
Но, честно говоря, мне это кажется излишним. Вам все равно придется отредактировать файл .targets, чтобы использовать новые задачи. Написание такой «основной» задачи и ее поддержка могут занять у вас больше времени.

Я могу фантазировать еще о нескольких автоматизированных решениях, но соображения «вложенного времени»/«времени, сэкономленного за счет автоматизации» останавливают полет моего воображения. знак равно

person alpha-mouse    schedule 22.11.2010
comment
Я нашел решение с использованием PowerShell, отражения сборки и XML. Я запускаю сценарий PowerShell в цели AfterBuild проекта, и файл .Targets создается, как и ожидалось. Однако это не кажется мне элегантным решением... Есть какие-нибудь мысли по этому поводу или альтернативы? знак равно - person Sameer Singh; 23.11.2010
comment
Вы можете перемещать .Targets, созданные с помощью Powershell и отражения, по (сетевому) пути, к которому может получить доступ любой разработчик. Затем в сценарии сборки ваших проектов вы всегда ссылаетесь на свой главный файл .Targets. Что касается использования Powershell и отражения, мне это не кажется неэлегантным. Вы также можете использовать комментарии xml вместо рефлексии, но для этого потребуется дополнительная работа. - person Benjamin Baumann; 24.11.2010

arrow_upward
0
arrow_downward

Что ж, я нашел более удобный способ добиться этого с помощью задачи сообщества MSBuild TaskSchema:

<TaskSchema Assemblies="@(MyTaskAssembly)" 
            OutputPath="%(MyTaskAssembly.RootDir)%(MyTaskAssembly.Directory)" 
            CreateTaskList="true"
            IgnoreMsBuildSchema="true"
            Includes="Microsoft.Build.Commontypes.xsd"/>

Я просто удостоверяюсь, что импортировал файл MSBuild.Community.Tasks.Targets, создаю ItemGroup с именем MyTaskAssembly, содержащий все мои сборки задач (шокер), а затем вставляю указанный выше вызов задачи в цель AfterBuild моего проекта. Сладкий! :)

person Sameer Singh    schedule 28.05.2012