2016-05-19 9 views
7

Migrieren meiner Webanwendung von ASP.NET Core RC1 auf RC2. Ich versuche, meine referenzierten Klassenbibliotheken zu laden.So laden Sie Assemblys in ASP.NET Core 1.0 RC2

Dieses Code-Snippet funktioniert nicht mehr mit RC2.

public class Startup 
{ 
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
    { 
     // libraryManager is null .... 
     ILibraryManager libraryManager = app.GetService<ILibraryManager>(); 

     List<Assembly> result = new List<Assembly>(); 

     IEnumerable<Library> libraries = libraryManager.GetLibraries(); 

     IEnumerable<AssemblyName> assemblyNames = libraries.SelectMany(e => e.Assemblies).Distinct(); 
     assemblyNames = Enumerable.Where(assemblyNames, e => e.Name.StartsWith("projectNamespace")); 

     foreach (AssemblyName assemblyName in assemblyNames) 
     { 
      Assembly assembly = Assembly.Load(assemblyName); 
      . 
      . 
      . 
     } 
    } 
} 

Unsere Hilfe wäre sehr dankbar, Danke Stefan

+0

Welche Fehler haben Sie bekommen? – jeteon

+0

kein Fehler .... aber app.GetService () gibt null zurück – stevo

Antwort

12

fand ich eine Lösung. Ich verwende jetzt DependencyContext statt ILibraryManager

var loadableAssemblies = new List<Assembly>(); 

var deps = DependencyContext.Default;    
foreach (var compilationLibrary in deps.CompileLibraries) 
{ 
    if (compilationLibrary.Name.Contains(projectNamespace)) 
    { 
     var assembly = Assembly.Load(new AssemblyName(compilationLibrary.Name)); 
     loadableAssemblies.Add(assembly); 
    } 
} 
+0

Danke, sparte mir eine Menge Zeit :-) –

+0

Danke! brauchte eine Weile, um das herauszufinden. – Charles

+0

In meinem Programm wird DependencyContext.Default in null aufgelöst. Irgendwelche Vorschläge, warum das passieren könnte? –

4

Ich denke stevo 2 falsche Annahmen gemacht hat:

1), dass die Projektnamespace Teil Compilierungsbibliothek Name sein sollte.
2) Der Name der Kompilierungsbibliothek ist derselbe wie der Binärname.

Zuerst ist falsch, wenn Sie es in den Projekteinstellungen ändern. Zweitens ist falsch, wenn Sie es in buildOptions in project.json angeben.

Also Ihre Idee ist richtig, aber die Umsetzung ist falsch. Um das zu beheben, müssen wir die Auflösung durch den Namespace vergessen, bis die Assembly geladen ist.
Ich denke, da alle Assemblies in jedem Fall geladen werden, werden wir keine große Leistungsverzögerung bekommen.

Aber es ist kein Allheilmittel ... Assembly kann mehrere Wurzel Namespaces innerhalb haben! Also vielleicht besser Weg, einige Attribute auf Assembly-Ebene zu definieren und es anstelle von Namespace zu überprüfen.

Auf jeden Fall, wenn Sie wollen Montage sollte es so gemacht werden Namen Ihres Suche einzuschränken:

IEnumerable<AssemblyName> names = DependencyContext.Default.GetDefaultAssemblyNames(); 

foreach (AssemblyName name in names) 
{ 
    if (name.Name.StartsWith("MyRoot") == true) 
    { 
     Assembly assembly = Assembly.Load(name); 

     // Process assembly here... 
     // I will check attribute for each loaded assembly found in MyRoot. 
    } 
} 
+0

Eine kleine Variation dieses Ansatzes funktionierte für mich, Prost. :) – Tagc