Скопируйте DLL-файлы при создании многорежимного приложения MEF

Question

Я использую Visual Studio 2010 для разработки и построения .NET Framework 4.0. Я также использую Managed Extensibility Framework для базовой системы плагинов.

У меня есть 2 решения:

Основное решение с 6 проектов, один исполняемый другой 5 являются библиотеки классов. Они ссылаются друг на друга, и они встроены в папку bin уровня решения (папка bin находится рядом с папками проекта). Таким образом, все встроенные файлы bin находятся в одной папке, а MEF может собирать все DLL-файлы в простой каталог каталогов.

Это прекрасно работает (за исключением 1 вещи, что запуск приложения не перестраивает все остальные проекты, так как они не являются зависимостями, но это не тот вопрос, о котором идет речь).

Другое (расширение) решение имеет 2 проекта, они являются библиотеками классов и должны быть каким-то образом добавлены в каталог, который MEF использует для создания своего каталога.

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

Так вопросы решить, являются:

1. проектов эталонных проектов удлиняющего решения, от первого решения, поэтому я перемещаться бен папкой основного решения на надстройки эталонного экрана и добавлена ​​все необходимые ссылки. Будут ли ссылки обновляться при построении основного решения, или мне нужно будет как-то скопировать DLL-файлы вручную?

   • Intellisense должен признать изменение, поэтому после изменения и построения основное решение должно быть распознано, а intellisense должен обновляться при редактировании решения расширения.
   • Главное решение построено на собственном уровне и ничего не знает о расширении. Давайте так и будем. Я бы не писал задачу сборки для основного решения, которое копирует dll в папку другого решения.
   • Решения размещены на сервере SVN. Было бы большим плюсом, если бы получить решения с ankhsvn на новом компьютере и построить оба решения не потребует дальнейшей настройки.

2. При создании проектов решения расширения DLL-файлы должны быть скопированы в каталог, который MEF использует для своего каталога (каталог bin основного решения). Было бы хорошо, если бы он также работал над тем, чтобы получить свежую информацию из svn. Это можно сделать с помощью задачи сборки, но что является лучшим способом ссылки на папку другого решения?

   • Я думаю, что это не будет большой компромисс, если решения каталоги должны быть рядом друг с другом (и имеют имя по умолчанию), чтобы работать (таким образом я мог бы просто использовать другой уровень ../ ссылаться на нее). Это достойное решение? Есть ли недостатки, о которых я не знаю?

Answer 1

Существует другой подход для решения вопроса 1:

• Добавьте необходимые проекты из Main.sln в Extension.sln. Вы можете сделать это, выбрав «Добавить существующий проект» из контекстного меню решения.
• Обновите ссылки проектов расширения на добавленные проекты, а не на их выходные DLL. Visual Studio будет нести ответственность за поиск выходных библиотек и принятие решения о том, когда ваши проекты должны быть построены.
• Вы также можете добавить solution folder под названием «Зависимости» или что-то в этом роде и переместить туда все проекты от Main.sln. Таким образом, вы можете узнать, какие проекты являются «гостями».

Это позволит решить все пули выпуска 1 но вам нужно быть осторожным, потому что от Extension.sln вы можете изменить зависимые проекты. Плюсом является то, что вы также сможете отлаживать свой код в более сложном режиме, который будет работать на новой машине разработки без какой-либо дополнительной работы.

Тем не менее, я бы выбрал одно решение со всеми 8 проектами, которые прямолинейны. Только если решение получило огромные (~ 100 проектов), я бы пошел на это.

Что касается Вас комментарий о различных репозиториях:

Кроме того, если я совершаю это SVN будет на «существующие проекты» также поручены в новое хранилище?

Я так не считаю. Если вы храните их в том же SVN-репозитории (что я не вижу в этом никаких причин), это будет нормально. Вы можете добавить множество решений в один и тот же репозиторий. Пока они актуальны, это правильно.

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