Бездействующие сборки с C #

Question

Я только что закончил настройку системы компоновки для нашего существующего кода C ++, используя унаследованные листы свойств, особенность, которая кажется специфической для продукта Visual C ++. Построение не на своем месте требует изменения многих параметров проекта, а унаследованные листы свойств позволили мне изменить все необходимые параметры, просто прикрепив лист свойств к проекту. Я перевожу нашу команду с C ++ / MFC для пользовательского интерфейса на C # и WPF, но мне нужно предоставить те же функциональные возможности сборки вне места, надеюсь, с тем же удобством. Кажется, я не могу найти способ сделать это с C # проектами - сначала я посмотрел, могу ли я сослаться на файл целей MsBuild, но не смог найти способ сделать это. Я знаю, что мог бы просто использовать MsBuild для всего этого, но это кажется более сложным, чем необходимо. Есть ли способ, которым я могу определить макрос для каталога и использовать его в пути вывода, например?

Answer 1

Я не совсем уверен, что такое "неуместная" система сборки, но если вам просто нужна возможность копировать скомпилированные файлы (или другие ресурсы) в другие каталоги, вы можете сделать это, привязав Цели сборки MSBuild.

В наших проектах мы перемещаем скомпилированные библиотеки в папки lib и помещаем файлы в нужные места после завершения сборки. Для этого мы создали специальный файл .target сборки, который создает Target, Property и ItemGroup, которые мы затем используем для заполнения нашей внешней выходной папки.

Наш файл пользовательских целей выглядит примерно так:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <ProjectName>TheProject</ProjectName>
        <ProjectDepthPath>..\..\</ProjectDepthPath>
        <ProjectsLibFolder>..\..\lib\</ProjectsLibFolder>

        <LibFolder>$(ProjectsLibFolder)$(ProjectName)\$(Configuration)\</LibFolder>
    </PropertyGroup>

    <Target Name="DeleteLibFiles">
        <Delete Files="@(LibFiles-> '$(ProjectDepthPath)$(LibFolder)%(filename)%(extension)')" TreatErrorsAsWarnings="true" />
    </Target>
    <Target Name="CopyLibFiles">
        <Copy SourceFiles="@(LibFiles)" DestinationFolder="$(ProjectDepthPath)$(LibFolder)" SkipUnchangedFiles="True" />
    </Target>

    <ItemGroup>
        <LibFiles Include=" ">
            <Visible>false</Visible>
        </LibFiles>
    </ItemGroup>
</Project>

Файл .csproj в Visual Studio затем интегрируется с этим пользовательским целевым файлом:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" ... >
    ...
    <Import Project="..\..\..\..\build\OurBuildTargets.targets" />
      <ItemGroup>
        <LibFiles Include="$(OutputPath)$(AssemblyName).dll">
          <Visible>false</Visible>
        </LibFiles>
      </ItemGroup>
    <Target Name="BeforeClean" DependsOnTargets="DeleteLibFiles" />
    <Target Name="AfterBuild" DependsOnTargets="CopyLibFiles" />
</Project>

Короче говоря, этот скрипт сборки сначала говорит MSBuild загрузить наш собственный скрипт сборки, затем добавляет скомпилированный файл в LibFiles ItemGroup и, наконец, связывает наши пользовательские цели сборки, DeleteLibFiles и CopyLibFiles, в Процесс сборки. Мы настроили это для каждого проекта в нашем решении, поэтому только файлы, которые обновляются, удаляются / копируются, и каждый проект отвечает за свои собственные файлы (библиотеки, изображения и т. Д.).

Надеюсь, это поможет. Я прошу прощения, если я неправильно понял, что вы имеете в виду, говоря о системе компоновки вне места, и это совершенно бесполезно для вас!

Answer 2

На самом деле, события до и после сборки кажутся исключительно местом для добавления команд типа пакетного файла. К сожалению, это не помогло бы мне настроить стандартные каталоги для наших проектов. И создание этих событий командных файлов похоже на подход 1980-х годов для современного языка, такого как C #, IMO.

После еще нескольких копаний и экспериментов я обнаружил, что вы можете добавить директиву в ваш файл .csproj. Когда вы делаете это, в среде IDE появляется диалоговое окно с предупреждением о том, что в вашем проекте есть небезопасная точка входа, но вы можете проигнорировать это и сделать так, чтобы она вообще не появлялась, очевидно, редактируя запись в реестре. Так что это дало бы мне возможность получить переменные, содержащие нужные мне пути к каталогам, в файл .csproj.

Теперь чтобы получить выходной путь для ссылки на него - к сожалению, когда вы добавляете строку типа «$ (MySpecialPath) / Debug» в поле «Выходной путь» и сохраняете проект, символы $ и () преобразуются в шестнадцатеричные и ваш файл get помещается в каталог Debug в каталоге с именем $ (MySpecialPath). Arrgghh. Если вы отредактируете файл .csproj в текстовом редакторе, вы можете установить его правильно, однако, и он будет работать до тех пор, пока тег появляется перед , содержащим путь вывода.

Поэтому я думаю, что для меня решение будет заключаться в создании стандартного файла MsBuild OurTeam.targets в стандартном месте, добавлении установщика для изменения реестра, чтобы он не помечал предупреждения, а затем создании пользовательских шаблонов проектов, которые этот файл, а также задайте путь вывода, чтобы использовать свойства, определенные в файле OurTeam.targets. К сожалению, это более трудоемкое и менее изящное решение, чем механизм наследования листов свойств в C ++.

Answer 3

Есть ли способ определить макрос для каталога и использовать его в выходном пути

Вы смотрели события проекта до и после сборки?