404 на контроллерах во внешних сборках

Question

У меня возникла проблема с разрешением 404 ответов в моем проекте Asp.Net MVC 4. Он построен в VS2012, ориентированном на 4.5.

У меня есть предварительно скомпилированные представления и контроллеры, встроенные в автономные библиотеки DLL. Я могу динамически загружать библиотеки DLL и проверять их из моего основного проекта, даже вызывать методы на них; однако, похоже, что MVC Framework не знает контроллеров. Я рядом, но чего-то не хватает.

Справочная информация о контроллерах и представлений

контроллеры встроены в отдельный проект MVC и наследовать от Controller. Ничего интересного не происходит. Представления используют RazorGenerator и становятся классами, которые живут в проекте.

Результатом проекта является DLL, которая правильно содержит контроллеры и представления.

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

Загрузка библиотеки DLL

Запуск от имени администратора в Visual Studio я компилирую мое приложение, которое организовано под IIS. С построенным проектом я бросаю DLL плагина в каталог «Плагины». Без отладки (это становится важным позже) я открываю IE и перехожу на сайт. Обратите внимание, что на этом этапе приложение было создано, но никогда не запускается, поэтому запускаются события запуска. Все, что я могу сделать, все равно остается неизменным, если я повторно использую пул приложений.

У меня есть Startup класса с двумя методами, PreStart и PostStart и вызывать методы с использованием WebActivator.PreApplicationStartMethod и WebActivator.PostApplicationStartMethod соответственно.

PreStart где я сделать следующее:

• Получить список всех плагинов DLL, в моем каталоге «Plugins»
• Скопируйте все плагины AppDomain.CurrentDomain.DynamicDirectory
• загрузить тип ... если она содержит IPlugin я тогда
  • Добавить сборку в BuildManager
  • Зов некоторые из методов в классе, что IMP lements IPlugin

В 'PostStart' Я делаю это немного кода (на основе кода из RazorGenerator.Mvc):

foreach (var assembly in Modules.Select(m=>m.Value)) 
{ 
    var engine = new PrecompiledMvcEngine(assembly) 
    { 
     UsePhysicalViewsIfNewer = HttpContext.Current.Request.IsLocal 
    }; 

    ViewEngines.Engines.Insert(0, engine); 
    VirtualPathFactoryManager.RegisterVirtualPathFactory(engine); 
} 

Modules в этом контексте является пара ключ/значение, где значения - это загруженные сборки. Цель этого кода - убедиться, что MVC осведомлен о представлениях, добавив механизм просмотра для каждой сборки, который знает, как разрешить представления (это часть RazorGenerator).

Как я знаю, что я Close (но явно не достает сигару)

IPlugin определяет метод, называемый RegisterRoutes, где, как вы уже догадались, маршруты должны быть зарегистрированы для тех, кто реализует интерфейс. Я вызываю этот метод в PreStart и добавляются маршруты - я подтвердил, что они существуют в моей таблице маршрутов. Например, на маршруте, определенный в мой плагин, созданный с помощью динамического вызова метода во время PreStart, я вижу что-то вроде этого как DataToken при рассмотрении моих маршрутов:

Namespaces = Plugin.Name.Controllers 

Таким образом, маршрут зарегистрирован, сборка загружена, я проверил, что DLL правильно скопирована в DynamicDirectory AppDomain. Я могу вызвать участников классов, которые динамически загружаются во время выполнения. Но когда я перехожу к URL-адресу, который соответствует маршруту , я получаю 404. Это не a «не удалось найти местонахождение» YSOD, это больше похоже на то, что вы не обнаружили контроллер вообще.

Вот часть, которая смущает меня из-за меня: если в данный момент, ничего не делая, я возвращаюсь в Visual Studio и нажимаю F5 ... все работает.

Это похоже на то, что Visual Studio каким-то образом узнает о контроллере, который я не могу определить, и MVC Framework набирает его.

Наконец, Вопрос

Что мне не хватает, и как я могу получить MVC Framework, чтобы быть в курсе моего контроллера?

И, в этот момент, если вы все еще читаете это, спасибо. :)

Answer 1

Оказывается, что это ошибка в самой Asp.Net.

После обсуждения вопроса с Эйлоном Липтоном из Асп.Чистая команда и думая, что это было чем-то нехорошо в MVC Framework, Эйлон и несколько членов команды врылись в вещи и обнаружили, что ошибка была на более низком уровне в этом разговоре: http://aspnetwebstack.codeplex.com/discussions/403529

Они также предложили обходное решение, которое включало другое звоните по BuildManager после вызова AddReferencedAssembly, который я реализовал с помощью следующего кода:

// Add the plugin as a reference to the application 
    BuildManager.AddReferencedAssembly(assembly); 
    BuildManager.AddCompilationDependency(assembly.FullName); 

Это позволяет добавить дополнительные контроллеры/Сост просмотры при запуске в вашей предварительной заявке стадии инициализации. То, что я сейчас делаю, - это перебирать список DLL в моем каталоге плагинов и нажимать их на BuildManager, как указано выше.

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

Надеюсь, что это поможет кому-то еще.

Cheers.

Answer 2

Похоже, что этот вопрос:

MVC использует сборочный-квалифицированное имя типа вида двигателя к устранения неоднозначности записей кэша вид с другой точки зрения двигателей. Так что у не возможно иметь более одного объекта PrecompiledMvcEngine (как , когда у вас есть предварительно скомпилированные представления в более чем одной сборке). Проблема может быть решена путем создания другого производного класса от PrecompiledMvcEngine для каждой сборки. Или путем создания отдельного производного класса , параметризованного некоторым типом сборки.

Артикул here.

Answer 3

@MisterJames, посмотрите на это:

Asp.Net Mvc Pluggable Application

Я надеюсь, что это полезно.