404 su controller in gruppi esterni

Question

Ho problemi a risolvere 404 risposte nel mio progetto Asp.Net MVC 4. È stato creato con il targeting VS2012 4.5.

Ho viste e controller precompilati incorporati in DLL autonome. Sono in grado di caricare dinamicamente le DLL e ispezionarle dal mio progetto principale, invocando anche metodi su di esse; tuttavia, sembra che MVC Framework non sia a conoscenza dei controller. Sono qui vicino, ma manca qualcosa.

Sfondo sui controller e viste

controllori sono costruiti in un progetto MVC stand-alone e ereditare da Controller. Niente di troppo interessante in corso lì. Le viste utilizzano RazorGenerator e diventano classi che vivono nel progetto.

L'output del progetto è una DLL che contiene correttamente i controller e le viste.

Le DLL implementano un'interfaccia specifica, la chiameremo IPlugin, in una classe separata (non parte di un controller) nella libreria.

Caricamento le DLL

Esecuzione come admin in Visual Studio compilo la mia applicazione, che è ospitato in IIS. Con il progetto creato, inserisco una DLL plugin nella mia directory "Plugin". Senza debug (questo diventa importante in seguito), apro IE e navigo nel sito. Nota che a questo punto l'app è stata creata, ma non viene mai eseguita, quindi gli eventi di avvio verranno attivati. Tutto qui è ancora coerente se riciclo il pool di app.

Ho una classe Startup con due metodi, PreStart e PostStart e richiamare i metodi usando WebActivator.PreApplicationStartMethod e WebActivator.PostApplicationStartMethod rispettivamente.

PreStart è dove faccio la seguente:

• ottenere un elenco di tutte le DLL plugin nella mia cartella "Plugins"
• Copia tutti i plugin per AppDomain.CurrentDomain.DynamicDirectory
• Caricare il tipo ... se contiene un IPlugin ho poi
  • aggiungere l'assembly al BuildManager
  • chiamata alcuni dei metodi della classe che imp ELEMENTI IPlugin

In 'poststart' Faccio questo pezzo di codice (basato sul codice da 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 in questo contesto è una coppia chiave/valore in cui il i valori sono gli assembly caricati. Lo scopo di questo codice è assicurarsi che MVC sia a conoscenza delle visualizzazioni aggiungendo un motore di visualizzazione per ogni assembly che sa come risolvere le viste (questo fa parte di RazorGenerator).

Come lo so sono vicino (ma chiaramente Mancando il sigaro)

IPlugin definisce un metodo chiamato RegisterRoutes dove, avete indovinato, percorsi devono essere registrati per coloro che implementa l'interfaccia. Io chiamo questo metodo in PreStart e le rotte sono aggiunte - Ho verificato che queste esistano nella mia tabella dei percorsi. Per esempio, su un percorso definito nel mio plug-in, creata attraverso l'invocazione dinamica del metodo durante la PreStart, vedo qualcosa di simile a questo come un DataToken in sede di esame miei percorsi:

Namespaces = Plugin.Name.Controllers 

Quindi, il percorso viene registrato, il l'assembly è stato caricato, ho verificato che la DLL sia correttamente copiata nella DynamicDirectory dell'AppDomain. Sono in grado di invocare membri di classi caricate dinamicamente in fase di runtime. Ma quando navigo verso l'URL che corrisponde alla route ottengo un 404. Questo è non un "impossibile trovare la vista" YSOD, è più simile a non trovare il controller affatto.

Ecco la parte che mi confonde da me: se, a questo punto, senza fare nulla, torno a Visual Studio e prendo F5 ... tutto funziona.

È come se Visual Studio stia diventando consapevole del controller in qualche modo che non riesco a identificare e MVC Framework si sta occupando di esso.

Infine, una domanda

Quello che mi manca, e come faccio ad avere il framework MVC di essere a conoscenza del mio controller?

E hey, a questo punto, se stai ancora leggendo questo, grazie. :)

Answer 1

Si scopre che questo è un bug in Asp.Net stesso.

Dopo aver discusso il problema con Eilon Lipton of the Asp.Net team, e pensando che questo fosse qualcosa di sbagliato nel MVC Framework, Eilon e un paio di membri del team hanno scavato nelle cose e hanno scoperto che l'errore era a un livello inferiore per questa conversazione: http://aspnetwebstack.codeplex.com/discussions/403529

Hanno anche suggerito una soluzione alternativa che includesse un altro invitare BuildManager dopo la chiamata a AddReferencedAssembly, che ho implementato tramite il seguente codice:

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

Ciò consente di aggiungere ulteriori controller/vista compilati in fase di avvio nel vostro pre-applicazione fase init. Quello che sto facendo ora è scorrere l'elenco delle DLL nella mia directory dei plugin e spingendoli a BuildManager come sopra.

L'unica limitazione qui è che non è possibile rimuovere gli assembly o cancellare la cache in modo dinamico. L'unico modo in cui ho trovato di farlo è quello di aggiungere un assembly precedentemente sconosciuto agli assiemi di riferimento e alle dipendenze di compilazione. Sto sperimentando emettendo dinamicamente un nuovo assembly durante l'inizializzazione della pre-applicazione in modo che io possa sempre, in modo efficace, svuotare la cache e rimuovere i plug-in precedentemente inclusi falsificando un nuovo assembly.

Spero che questo aiuti qualcun altro là fuori.

Cheers.

Answer 2

Sembra che questo problema:

MVC utilizza assemblaggio qualificato nome del tipo del motore al fine di disambiguare le voci della cache della vista provenienti da diversi motori di vista. Quindi è impossibile avere più di un oggetto PrecompiledMvcEngine (come quando si sono precompilate le viste in più di un assieme). Il problema può essere risolto creando una classe derivata diversa da PrecompiledMvcEngine per ogni assembly. O creando una singola classe derivata generica parametrizzata con un certo tipo dall'assieme.

L'articolo è here.

Answer 3

@MisterJames, dare un'occhiata a questo:

Asp.Net Mvc Pluggable Application

Spero sia utile.