Asp.Net 5 MVC 6 Startup.cs Разборка сборки в Beta8

Question

Я работаю над сайтом электронной коммерции, используя Asp.Net 5 и MVC6 после архитектуры Onion (OA), чтобы у нас была свободная связь между слоями. Я также хочу отменить код запуска в своей собственной сборке, а не иметь его в проекте MVC.

В бета-версии 7 было очень легко перемещать Startup.cs в библиотеку классов (Bootstrapper), как описано here. Один интересный факт, использующий упомянутый подход, заключается в том, что мне не нужно ссылаться на сборку Bootstrapper из проекта MVC. Во время выполнения, хостинг под IISExpress, посредством ассемблерного сканирования он смог найти узел Bootstrapper, упомянутый в файле Microsoft.AspNet.Hosting.ini. Это стало возможным, указав местоположение в global.json

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

Bootstrapper проект будет иметь ссылку на все другие проекты, такие как инфраструктура, услуги и т.д. для того, чтобы подключить Dependency Injection.

Причина, по которой не ссылаться на проект Bootstrapper в проекте MVC, следуя правилам архитектуры Onion, заключается в том, чтобы избежать доступа к коду инфраструктуры непосредственно из проекта MVC. Так что все это было хорошо, пока я не перешел на Beta8 сегодня утром.

Поскольку модель хостинга изменяется от IIS для пустельги, я должен был рефакторить global.json и project.json файлы, как показано ниже

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" 
    } 
} 

После внесения вышеуказанных изменений, я начал получать следующее сообщение об ошибке независимо запускать ли я его с помощью команды DnX или непосредственно с помощью Visual Studio

Внутренняя ошибка сервера System.InvalidOperationException типа с именем «StartupDevelopment» или «запуск» не может быть найден в сборки «EcommerceMvcApp». в Microsoft.AspNet.Hosting.Startup.StartupLoader.FindStartupType (String startupAssemblyName, IList diagnosticMessages) в Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() в Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices () в Microsoft.AspNet.Hosting.Internal.HostingEngine.BuildApplication()

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

System.IO.FileNotFoundException Не удалось загрузить файл или сборку «Загрузчик» или один из его зависимостей. Система не может найти указанный файл . на System.Reflection.RuntimeAssembly._nLoad (AssemblyName имя_файла, строка CodeBase, Доказательства assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, булева throwOnFileNotFound, булева forIntrospection, булева suppressSecurityChecks) при System.Reflection.RuntimeAssembly.nLoad (AssemblyName имя_файла, String CodeBase , фактические данные assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, булева throwOnFileNotFound, булева forIntrospection, булева suppressSecurityChecks) при System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef, Доказательства assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, булева throwOnFileNotFound, булева forIntrospection, булева suppressSecurityChecks) при System.Reflection.Assembly.Load (AssemblyName assemblyRef) при Microsoft.AspNet.Hosting.Startup .StartupLoader.FindStartupType (String startupAssemblyName, IList diagnosticMessages) при Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() в Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices() в Microsoft.AspNet.Hosting. Internal.HostingEngine.BuildApplication()

solution требует, чтобы я добавлял ссылку на проект Bootstrapper в проекте MVC, и он работает. Тем не менее, он побеждает цель иметь отдельную сборку Bootstrapper в первую очередь.

Вопрос в том, почему он не может найти сборку Bootstrapper, как это было в Beta7, используя источники, указанные в разделе «проекты» в global.json, или это новая модель хостинга, игнорирующая global.json? Есть ли способ указать местоположение сборки запуска?

Update 1

Просто хочу подчеркнуть, что в Beta7 он также работает с помощью "команды DnX" для обоих Microsoft.AspNet.Server.WebListener и 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" 
    } 

Однако команда DNX (используя файл Microsoft.AspNet.Hosting.json) не выполняется для обоих серверов в Beta8. Если кто-то задается вопросом, что это как-то связано с компонентом IIS Helios в Beta7, это не так. Я озадачен, почему сборка поиска перестал работать в Beta8

Update 2

Вот трассировки стека, что я получаю, когда я пытаюсь запустить в Beta8 с помощью IISExpress. Похоже, он пытается найти сборку в папке dnx bin.

System.IO.FileNotFoundException: Не удалось загрузить файл или сборку «Загрузчик» или один из его зависимостей. Система не может найти указанный файл . Имя файла: 'Bootstrapper' на System.Reflection.RuntimeAssembly._nLoad (AssemblyName имя_файла, строка CodeBase, Доказательства assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, булева throwOnFileNotFound, булева forIntrospection, булева suppressSecurityChecks) при System.Reflection.RuntimeAssembly.nLoad (AssemblyName имя_файла, String CodeBase , фактические данные assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, булева throwOnFileNotFound, булева forIntrospection, булева suppressSecurityChecks) при System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef, Доказательства assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark & stackMark, IntPtr pPrivHostBinder, булева throwOnFileNotFound, булева forIntrospection, булева suppressSecurityChecks) при System.Reflection.Assembly.Load (AssemblyName assemblyRef) при Microsoft.AspNet.Hosting.Startup .StartupLoader.FindStartupType (String startupAssemblyName, IList`1 diagnosticMessages) при Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() в Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices() в Microsoft.AspNet. Hosting.Internal.HostingEngine.BuildApplication()

=== Информация о состоянии предварительной привязки === LOG: DisplayName = Bootstrapper (Partial) WRN: информация о частичной привязке была предоставлена ​​для сборки : WRN: Assembly Name: Bootstrapper | Идентификатор домена: 1 WRN: A частичное связывание происходит, когда предоставляется только часть отображаемого имени сборки: . WRN: Это может привести к тому, что связующее загрузит неправильную сборку . WRN: Рекомендуется предоставить полностью определенный текстовый идентификатор для сборки, WRN: состоит из простого имени, версии, культуры и токена открытого ключа. WRN: Дополнительную информацию см. В техническом документе 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 Вызов сборки: (Неизвестно). === LOG: Это связывание начинается с контекста нагрузки по умолчанию. LOG: Файл конфигурации приложения не найден. LOG: Использование файла конфигурации хоста: LOG: Использование файла конфигурации машины от C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ config \ machine.config. LOG: политика не применяется к ссылке в это время (частная, пользовательская, частичная или привязка к месту расположения). LOG: Попытка скачать новый URL-адрес файл: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper.DLL. LOG: попытка загрузки нового URL-адреса файл: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper/Bootstrapper.DLL. LOG: попытка загрузки нового URL-адреса файл: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper.EXE. LOG: Попытка загрузить новый URL-адрес файл: /// C: /Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper/Bootstrapper.EXE.

Может быть, если я бегу ДНУ публиковать и размещать его под IIS он будет работать, но это означает, что я должен опубликовать его каждый раз, когда я делаю изменения

Answer 1

Принимающей формат файла конфигурации изменен с INI к Json.Попробуйте следующее:

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

См. Также this issue.

Answer 2

У меня возникла аналогичная проблема. Похоже, мы не хотим ссылаться на уровень пользовательского интерфейса на уровень Infraestructure (мы очень строги), даже не для разрешения проблемы зависимости.

Возможно, с помощью позднего связывания (я только что слышал об этом говорил), но я думаю, что вы должны прочитать this article. В основном это говорит о том, что корневой состав не может использоваться повторно, и для каждого приложения должно быть одно (например, одно для UI.Web, другое для UI.Console и т. Д.).

Это также мой вопрос о том, что имеет разрешение DI в UI.Web, но нужен другой интерфейс, скажем, консоль (ответ: предпочтительнее сделать разрешение аноретера DI в консоли, а будет иметь собственное разрешение зависимости от того, как работает консольное приложение).

Надеюсь, что дадим вам хороший момент для разъяснения этой проблемы.