Возможно создание кольцевых модулей в рамках MSBuild и Visual Studio; однако при этом существует очень ограниченный набор ситуаций, в которых это будет допустимо.
Один из ключевых способов сделать это, если вы планируете использовать Xaml в своем коде, это удалить аспект Sources тега Csc и сгенерировать собственный файл .response, который фактически указывает на код Вы хотите ввести. В атрибутах тега Csc вы сами указываете этот файл в атрибуте ResponseFiles.
В вашем файле .response вы затем разбите свое приложение на компоненты сборки и сетевого модуля, убедившись, что сначала всегда включаются файлы сборки ядра. Обычно атрибуты тега Csc напрямую переводятся в параметры командной строки Csc.exe. Имена параметров не всегда совпадают. Ради разрешения лучше использовать полные, не относительные пути при обращении к файлам (например, частичный , .response ниже):
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\SearchContexts\StringSearchType.cs"
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\UI\Themes\Themes.cs"
/target:module /out:bin\x86\Debug\InternalName.UI.dll
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\UI\EditDatabaseImageControl.xaml.cs"
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\obj\x86\Debug\UI\EditDatabaseImageControl.g.cs"
Вы заметите, что в конечном итоге вы объедините несколько наборов целей в один, и я сам включил сгенерированный xaml-код. Это частично, почему вы удаляете аспект Sources, так как часть генератора страниц Xaml задачи MSBuild автоматически внедряет информацию в набор @ (Compile). Поскольку существует конфигурация отладки / выпуска, в области, где вы определяете файл ответов для использования, я создаю две версии ответа (поскольку я использую шаблон T4):
ResponseFiles="$(CompilerResponseFile);InternalName.$(Configuration).response"
Если вы намеревались включить в свой код более одной платформы, вам, вероятно, потребуются файлы ответов C * P, где C - это количество конфигураций (Debug | Release), а P - количество платформ (x86, x64, AnyCpu). ). Решением такого рода, вероятно, будет только вменяемый метод с использованием генератора.
Краткая версия этого: можно создавать циклические модули, если вы можете гарантировать, что вы скомпилируете все это за один шаг. Чтобы обеспечить поддержку функциональности сборки, которая предоставляется вам на этапе сборки Xaml, лучше всего начать с обычного проекта C # и создать собственный файл .Targets из $(MSBuildToolsPath)\Microsoft.CSharp.targets в теге <Import .... возле дна. Вам также, вероятно, понадобится вторичный csproj для целей проектирования, поскольку большая часть intellisense теряется при использовании этого временного решения (или используйте атрибут csproj Condition, где цель выбирается с помощью установленного вами флага). Вы также заметите, что некоторым редакторам Xaml не нравится привязка к пространствам имен сетевых модулей, поэтому, если вы привязываетесь к типам в сетевом модуле, вам, вероятно, придется делать их в коде (я не тестировал обходные пути для этого, так как обычно обходят статическую привязку пространства имен)
По какой-то причине во всем этом .baml скомпилированные файлы .xaml неявно понимаются компилятором Csc, я не смог выяснить, откуда он это выводит из аргумента команды, или если он просто неявный дизайн. Если бы мне пришлось угадывать, что они выводятся из файлов g.cs, связанных с тем, что вы включаете в список включенных файлов.