У меня есть несколько WorkDesigner 4 ActivityDesigners, которые я бы хотел взаимодействовать с Visual Studio IDE (тот факт, что они WF4, не относится к вопросу).
Эти конструкторы определены в сборке, давайте назовем это herpaderp.dll . В конце концов, эта DLL будет доставлена на серверы, где ее деятельность и другой код будут жить долго и счастливо.
Но до этого времени я хотел бы, чтобы мои дизайнеры имели возможность изучить текущее решение, чтобы обеспечить лучшее время разработки для людей, использующих действия, определенные в herpaderp.dll. Что-то вроде «давайте протестируем эту конфигурацию Activity, используя примеры данных, которые хранятся в решении; вот примеры данных, которые я нашел в удобном поле со списком - пожалуйста, выберите один».
Теперь это довольно просто сделать. Вот наивная реализация:
var dteo = Microsoft.VisualStudio.Shell.Package.GetGlobalService(typeof(DTE));
var dte = dteo as DTE;
if(dte == null) return; // not in Visual Studio or other wierdness, bail
var samples = dte.GetSampleDatum(); // super awesome extension method
Эй, это сработало! Но есть небольшая проблема ... herpaderp.dll теперь должен ссылаться на следующие сборки:
- Microsoft.VisualStudio.Shell.10.0.dll
- envdte.dll
Эти сборки являются частью SDK. Необходимость их упаковки и доставки на сервер не имеет для меня никакого смысла. Это все равно что добавить еще одно приложение в мою толстую кишку.
Как я могу сломать эти зависимости, сохранив возможность взаимодействия с Visual Studio из моих дизайнеров?
На мой взгляд, у меня есть три возможных ответа, ни один из которых мне не особенно нравится.
- Используйте IoC для привязки к сборке во время выполнения, которая будет выполнять взаимодействие для меня. Сборка может ссылаться на сборки SDK, прячась за простым интерфейсом, определенным в herpaderp. К сожалению, это добавляет другую зависимость, которая имеет значение только во время разработки и будет бесполезна на сервере.
- Загружать зависимости во время выполнения, используя их полные имена сборок и прятаться за
dynamic. Это оскорбляет мое безопасное разведение. Кроме того, я не уверен, смогу ли я сойти с рук на все 100%.
- Взаимодействовать с пакетом Visual Studio во время выполнения через какое-либо расположение службы. Мое решение предоставляет расширение Visual Studio, поэтому мне не нужно беспокоиться о том, чтобы написать его или заставить людей его использовать. Но для того, чтобы помешать этому, мне пришлось бы использовать какую-то хреновую хрень с шаблонами Service Locator BS, которую я презираю со страстью . Сервисный локатор. Фэ. Кроме того, это также потребует некоторого рода межпроцессного взаимодействия (или, как минимум, межпроцессного домена в том же процессе).
Вариант 3 - моя лучшая ставка, я считаю. Есть ли другое решение, которое я пропускаю? Я просто неправ, ненавидя один из трех моих ответов?