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

В общем есть решение из нескольких проектов. Есть зависимости от сторонних библиотек. Требуется сделать так, чтобы при компиляции этого решения сборки группировались по папкам и подпапкам. Настроить выходной каталог для каждого проекта можно, но тогда части проекта не будут видеть друг друга. Например сборка А компилируется в каталог bin\debug\refA, а сборка B в bin\debug\refB, обеим этим сборкам нужна сборка С, которая просто лежит в папке bin\debug. Как это реализовать? Соответственно для режима дебаг и релиз выходные папки должны быть разными.
А другой момент, когда я меняю расширение некоторым сборкам на своё, то их перестают видеть другие сборки, которые на них ссылаются. И нигде не нашел как этого избежать. Кроме того, если попробовать загрузить такую сборку динамически, то сослаться на неё и создать объект какого-нибудь типа из этой сборки не получится. Мне нужны сборки с собственным расширением (в роли плагинов или менеджеров).
В общем в гугле есть кучи статей на тему MS-build и команд до/после построения, но практического смысла они не несут.

0

AceOfSpades, можно сделать выходной каталог в папке солюшена и копировать туда файлы с помощью post build event каждого проекта. Или если есть один главный проект который зависит от всех остальных и компилируется в последнюю очередь, то делать это в его post build event. Тогда эти действия будут собраны в одном месте.

1

Сообщение от OwenGlendower можно сделать выходной каталог в папке солюшена и копировать туда файлы с помощью post build event

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

Сообщение от OwenGlendower если есть один главный проект который зависит от всех остальных и компилируется в последнюю очередь, то делать это в его post build event

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

post build нужен только для смены расширения выходного файла. И как же потом подключить файл с не длл-овским расширением?

В общем разобрался сам. Насколько хорошо не знаю, но у меня всё работает.

В папке с файлом солюшена создал три папки _Debug, _Release, _References (подчёркивание нужно, чтобы эти папки всегда были вверху списка папок с проектами).
Соответственно в свойствах каждого проекта прописал путь вывода к папкам _Debug и _Release.
Все сторонние подключаемые библиотеки разложил по папкам (например сборки от майкрософт в папку microsoft, сборки с контролами компании Telerik в папку telerik и т.д.) и положил в папку _References. У всех проектов поставил ссылки на нужные сборки из этой папки. Флаг copy local для всех сборок и ссылок на проекты поставил false, т.к. они в любом случае будут в одном каталоге.

Теперь основная проблема - при запуске программа не видит нужных ей сборок. Это лечится с помощью обработки события AppDomain.AssemblyResolve. В аргументах события приходит имя сборки, которую не удаётся найти. Соответственно можно реализовать любую логику по нахождению этой сборки. Я сделал словарь всех доступных сборок и папок в которых они размещаются. Таким же образом решается проблема с загрузкой сборки у которой расширение не dll, а например .plugin. Ищем нужное имя в словаре, получаем папку размещения, загружаем с помощью Assembly.LoadFrom.

В итоге получил логичную и красивую структуру папок и файлов программы. Компиляция происходит мгновенно, т.к. не приходится копировать кучу ненужного.

Надо также заметить, что нельзя задать ссылку на проект на выходе которого будем менять расширение длл на своё, т.к. это вызовет ошибку компиляции. Если нужно чтобы такие проекты строились, если они были изменены, по кнопке запуск, то в свойствах решения можно выставить зависимости запускаемого проекта от этих самых. Ссылок при этом не будет и ошибка компиляции не появится.

0

AceOfSpades, проблему с поиском dll из других каталогов можно решить с помощью файла конфигурации

0

Нерационально в этом случае. К тому же конфиги переписать можно как угодно.

0