Я пытаюсь определить, является ли MEF правильным направлением, в котором должна следовать наша прикладная среда. Из моего прочтения MEF наша структура, похоже, «не совсем» подходит, но я посмотрю, смогут ли мне помочь какие-то эксперты.
Наша структура позволяет нам иметь один основной веб-сайт и развернутые зависимые сборки в одном месте (и исправления или функции распространяются на всех клиентов), затем у нас есть клиентские веб-сайты, которые как бы «объединяются» с основным веб-сайтом и расширяют его, необходимо.
Теперь в IIS каждый клиентский сайт - это свое собственное приложение, работающее в своем собственном домене приложений. Однако каждое приложение имеет один и тот же физический путь, указывающий на «основной веб-сайт».
Итак, наша файловая структура ...
- / CoreSite
- / bin (содержит базовый сайт и библиотеки зависимостей)
- / [Основные папки сайта] (например, Модели, Представления, Контроллеры, Контент и т. Д.)
- / Клиенты
- / _ Сборки (содержащие все клиентские сборки - 100 клиентов)
- / Client1
- / [Папки сайта клиента] (например, модели, представления, контроллеры и т. Д.)
- / Client2
- / [Папки сайта клиента] (например, модели, представления, контроллеры и т. Д.)
- / ClientN
1036 **
Так что, как вы уже догадались, загрузка сборки - это наша проблема. Мы не хотели помещать все клиентские сборки в папку root / bin по нескольким причинам. Сначала мы не хотели, чтобы каждый клиентский сайт загружал все остальные клиентские сборки. Во-вторых, мы не хотели, чтобы домен каждого сайта перерабатывался просто потому, что в папке / bin была обновлена сборка другого клиента.
Чтобы сделать это в asp.net 1.1, мы следовали http://www.hanselman.com/blog/MovingTheCodeBehindAssembliesDLLsToADifferentFolderThanBINWithASPNET11.aspx и добавили элемент в web.config вместе с <% @ Assembly Директива Name = "ClientN"%> в каждом представлении на клиентских сайтах. Единственная другая проблема, с которой нам пришлось столкнуться, это обновление клиентских сборок, но asp.net 1.1 блокировал сборки в каталоге / Clients / _Assemblies. Мы просто добавили:
if ( Directory.Exists( assembliesDir ) && AppDomain.CurrentDomain.SetupInformation.ShadowCopyDirectories.IndexOf( assembliesDir ) < 0 )
{
AppDomain.CurrentDomain.SetShadowCopyPath( AppDomain.CurrentDomain.SetupInformation.ShadowCopyDirectories + ";" + assembliesDir );
}
И альт, все, казалось, работало как шарм. К сожалению, в asp.net 4.0 AppDomain.CurrentDomain.SetShadowCopyPath () устарела. Таким образом, мы возились с попыткой загрузить сборки из байтового массива, пытались использовать событие AssemblyResolve, безрезультатно пытались использовать [Assembly: PreApplicationStartMethod (typeof (MvcApplication), «PreApplicationStart»)]]. Compilation.BuildManager.AddReferencedAssembly безрезультатно.
Мы либо получаем:
- сборка не загружена
- загружено слишком много сборок, или
- сборка загружается, но когда представление рендерится и встречает директиву , где пространство имен должно быть расположено из <% @ Assembly Name = "ClientN"%>, просто происходит сбой.
Поэтому я прошу любые предложения, использующие любой механизм и / или советы о том, является ли MEF подходящим вариантом. Мой взгляд на 1000 футов заключается в том, что MEF больше ориентирован на 1 приложение (или веб-сайт), в которое включены несколько компонентов. Я не решаюсь начать основной рефакторинг кода (кажется), потому что в нашей ситуации у нас когда-либо есть только один компонент, подключаемый к нему за раз на приложение / домен приложения. Похоже, что он делает гораздо больше, чем нам нужно (просто загрузите сборку и убедитесь, что asp.net распознает ее ... тогда весь наш код будет работать).
Любой совет с благодарностью.