Asp.Net 5 MVC 6 Startup.cs Montaż Rozłączenie w Beta8

Question

Pracuję nad witryną eCommerce przy użyciu Asp.Net 5 i MVC6 po architekturze cebuli (OA), dzięki czemu mamy luźne połączenie między warstwami. Chcę również rozdzielić kod uruchamiania w swoim własnym zestawie, zamiast go w projekcie MVC.

W wersji beta7 Bardzo łatwo było przenieść plik Startup.cs do biblioteki klas (Bootstrapper), jak wyjaśniono w sekcji here. Interesującym faktem przy użyciu wspomnianego podejścia jest to, że nie musiałem odwoływać się do zespołu Bootstrapper z projektu MVC. W czasie wykonywania, hostingu pod IISExpress, poprzez skanowanie zespołów, był w stanie znaleźć zestaw Bootstrapper wymieniony w pliku Microsoft.AspNet.Hosting.ini. Było to możliwe poprzez określenie położenia w global.json

{ 
    "projects": [ "Source/Projects","Source/Bootstrapper" ], 
    "sdk": { 
     "architecture": "x64", 
     "runtime": "clr", 
     "version": "1.0.0-beta7" 
    } 
} 

projektu inicjującego będą miały odniesienie do wszystkich innych projektów, takich jak infrastruktura, usługi itp żeby zahaczyć Dependency Injection.

Powodem braku odniesienia do projektu Bootstrapper w projekcie MVC, zgodnie z zasadami architektury Onion, jest uniknięcie dostępu do kodu infrastruktury bezpośrednio z projektu MVC. Tak więc wszystko działało bez zarzutu, dopóki nie podniosłem standardu do wersji beta 8 rano.

jako model hosting zmienia się z IIS do Kestrel, miałem byłaby pliki global.json i project.json jak poniżej

global.json

{ 
    "projects": [ "Source/Projects","Source/Bootstrapper" ], 
    "sdk": { 
     "architecture": "x64", 
     "runtime": "clr", 
     "version": "1.0.0-beta8" 
    } 
} 

project.json

{ 
    "dependencies": { 
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-beta8", 
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-beta8", 
    "....", 
    "....", 
}, 

"commands": { 
    "web": "Microsoft.AspNet.Server.Kestrel" 
    } 
} 

Po dokonaniu powyższych zmian, zacząłem coraz następujący błąd niezależnie czy uruchomić go za pomocą polecenia DNX lub bezpośrednio za pomocą Visual Studio

Internal Server Error System.InvalidOperationException typ nazwany „StartupDevelopment” lub „Uruchomienie” nie można znaleźć w montażu „EcommerceMvcApp”. w Microsoft.AspNet.Hosting.Startup.StartupLoader.FindStartupType (string startupAssemblyName, IList diagnosticMessages) w Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() (w Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices) na Microsoft.AspNet.Hosting.Internal.HostingEngine.BuildApplication()

okazało się, że muszę wskazać plik konfiguracyjny lub argumentów inline polecenia internetowej jak wyjaśniono here. Po wykonaniu sugestię, starałem uruchamiania aplikacji i tym razem zacząłem uzyskiwanie błąd poniżej

System.IO.FileNotFoundException Nie można załadować pliku lub zestawu „Bootstrapper” lub jeden z jego zależnościami. System nie może znaleźć określonego pliku . pod adresem System.Reflection.RuntimeAssembly._nLoad (AssemblyName fileName, String CODEBASE, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) w System.Reflection.RuntimeAssembly.nLoad (AssemblyName pliku, String CODEBASE , Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) w System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, logiczna throwOnFileNotFound, logiczna forIntrospection, logiczna suppressSecurityChecks) w System.Reflection.Assembly.Load (AssemblyName assemblyRef) w Microsoft.AspNet.Hosting.Startup .StartupLoader.FindStartupType (ciąg startupAssemblyName, IList diagnosticMessages) w Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() w Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices() w Microsoft.AspNet.Hosting. Internal.HostingEngine.BuildApplication()

Do solution wymaga dodania odwołania do projektu Bootstrapper w projekcie MVC i działa. Jednak w pierwszej kolejności pokonuje cel oddzielnego zespołu Bootstrapper.

Pytanie brzmi, dlaczego nie jest w stanie znaleźć zespołu Bootstrapper, tak jak to miało miejsce w Beta7, używając źródeł określonych w "projects" w pliku global.json lub czy nowy model hostingu ignoruje global.json? Czy istnieje sposób określania położenia zespołu uruchamiania?

Aktualizacja 1

prostu chcę podkreślić, że w p7 działa również za pomocą komendy „DNX” zarówno Microsoft.AspNet.Server.WebListener i Microsoft.AspNet.Server.Kestrel.

"commands": { 
     "kestrel": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5004 --config wwwroot/Microsoft.AspNet.Hosting.ini", 
     "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5004 --config wwwroot/Microsoft.AspNet.Hosting.ini" 
    } 

Jednak komenda dnx (przy użyciu pliku Microsoft.AspNet.Hosting.json) nie dla obu serwerów w Beta8. Jeśli ktoś zastanawia się, czy ma to coś wspólnego z komponentem IIS Helios w Beta7, to nie jest tak. Jestem zaskoczony, dlaczego odnośnika zespół przestał działać w Beta8

Update 2

Oto ślad stosu że dostanę gdy próbuję uruchomić w Beta8 użyciu IISExpress. Wygląda na to, że próbuje znaleźć złożenie w folderze bin dnx.

System.IO.FileNotFoundException: Nie można załadować pliku lub zestawu „Bootstrapper” lub jeden z jego zależnościami. System nie może znaleźć określonego pliku . Nazwa pliku: 'Bootstrapper' at System.Reflection.RuntimeAssembly._nLoad (AssemblyName fileName, String CODEBASE, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) w System.Reflection.RuntimeAssembly.nLoad (AssemblyName pliku, String CODEBASE , Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) w System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, logiczna throwOnFileNotFound, logiczna forIntrospection, logiczna suppressSecurityChecks) w System.Reflection.Assembly.Load (AssemblyName assemblyRef) w Microsoft.AspNet.Hosting.Startup .StartupLoader.FindStartupType (ciąg startupAssemblyName, IList`1 diagnosticMessages) w Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() w Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices() w Microsoft.AspNet. Hosting.Internal.HostingEngine.BuildApplication()

=== Informacje o stanie pre-bind === LOG: DisplayName = Bootstrapper (częściowe) WRN: Częściowe informacje o powiązaniu zostały dostarczone dla zespołu : WRN: Nazwa zestawu: Bootstrapper | Identyfikator domeny: 1 WRN: A częściowe powiązanie występuje, gdy podano tylko część wyświetlanej nazwy zespołu, podając . WRN: Może to spowodować, że spoiwo załaduje nieprawidłowy zespół . WRN: Zaleca się podanie w pełni określonego, tekstowego identyfikatora dla zespołu, WRN: składającego się z prostej nazwy, tokenu , kultury i tokenu klucza publicznego. WRN: Aby uzyskać więcej informacji i zapoznać się z powszechnymi rozwiązaniami tego problemu, zapoznaj się z oficjalnym biurem http://go.microsoft.com/fwlink/?LinkId=109270. LOG: Appbase = file: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/ LOG: Initial PrivatePath = NULL Zespół wywołujący: (nieznany). === LOG: To powiązanie rozpoczyna się w domyślnym kontekście ładowania. LOG: Nie znaleziono pliku konfiguracyjnego aplikacji. LOG: Za pomocą pliku konfiguracyjnego hosta: LOG: Przy użyciu pliku konfiguracyjnego maszyny od C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ config \ machine.config. LOG: Zasada nie jest stosowana do odniesienia w tym momencie (prywatne, niestandardowe, częściowe lub oparte na lokalizacji powiązanie zespołu). LOG: Próba pobrania nowego adresu URL: file: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper.DLL. LOG: Próba pobrania nowego adresu URL file: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper/Bootstrapper.DLL. LOG: Próba pobrania nowego adresu URL file: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper.EXE. LOG: Próba pobrania nowego adresu URL file: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper/Bootstrapper.EXE.

Być może, jeśli biegnę DNU ​​publikować i udostępniać je pod IIS to będzie działać, ale to oznacza, że ​​będę musiał opublikować ją za każdym razem robię zmianę

Answer 1

gospodarzem format pliku config zmieniły się od INI do Json.Spróbuj tego:

{ 
    "Hosting:Application": "Bootstrapper", 
} 

zobaczyć również this issue.

Answer 2

Utknąłem w podobnym problemie. Wygląda na to, że nie chcemy tworzyć odniesień z warstwy interfejsu użytkownika do warstwy Infraestructure (jesteśmy bardzo rygorystyczni), nawet w przypadku rozwiązywania zależności.

Być może jest to możliwe za pomocą późnego wiązania (Właśnie słyszałem o tym rozmawiałem), ale myślę, że powinieneś przeczytać this article. Zasadniczo mówi się, że główny składnik kompozycji nie nadaje się do ponownego użycia i powinien być jeden na aplikację (tj. Jeden dla UI.Web, inny dla UI.Console itd.).

To odpowiada również na moje pytanie dotyczące tego, co ma rozdzielczość DI w UI.Web, ale potrzebuje innego interfejsu użytkownika, powiedzmy, Console (odpowiedź: lepiej jest zrobić rozdzielczość DIer w Konsoli, a będzie mieć własną rozdzielczość zależności związane z działaniem aplikacji konsolowej).

Mam nadzieję, że podam dobry punkt, aby wyjaśnić tę kwestię.