Копирование DLL-s на построение мультирешения MEF приложения

Я использую visual studio 2010 для разработки и сборки на платформе .net framework 4.0. Я также использую управляемую платформу расширяемости для базовой системы плагинов.

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

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

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

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

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

Так что необходимо решить следующие вопросы:

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

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

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

    • я думаю, что это не будет большим компромиссом, если каталоги решений должны быть рядом друг с другом. другие (и имеют имя по умолчанию) для работы (таким образом, я мог бы просто использовать другой уровень ../ ссылаться на него). Это достойное решение? Есть ли какие-то недостатки, о которых я не знаю?
1 2
solution visual-studio-2010 msbuild-task

1 ответ:

Существует другой подход к решению проблемы 1:

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

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

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

Относительно вашего комментария о различных репозиториях:

Также, если я передам это SVN, будут ли "существующие проекты" также переведен в новое хранилище?

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

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