Jaka jest prawidłowa kolejność w konfiguracji aplikacji ASP.NET Core?

Question

Mam aplikację ASP.NET Core z kilkoma kontrolerami Web Api. Nie mogę stwierdzić, czy jest jakieś połączenie, ale aplikacja została utworzona za pomocą VS2015 update 2, a teraz pracuję z aktualizacją VS2015 3. Stworzyłem więc kolejny kontroler Web Api, a kiedy jest zapytanie do tego kontrolera mam ten wyjątek:

System.NotSupportedException: The given path's format is not supported. 
    at System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath) 
    at System.IO.Path.GetFullPath(String path) 
    at Microsoft.AspNet.FileProviders.PhysicalFileProvider.GetFullPath(String path) 
    at Microsoft.AspNet.FileProviders.PhysicalFileProvider.GetFileInfo(String subpath) 
    at Microsoft.AspNet.StaticFiles.StaticFileContext.LookupFileInfo() 
    at Microsoft.AspNet.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context) 
    at Microsoft.AspNet.Cors.Infrastructure.CorsMiddleware.<Invoke>d__7.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.GetResult() 
    at Microsoft.AspNet.Diagnostics.Entity.MigrationsEndPointMiddleware.<Invoke>d__5.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.GetResult() 
    at Microsoft.AspNet.Diagnostics.Entity.DatabaseErrorPageMiddleware.<Invoke>d__6.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at Microsoft.AspNet.Diagnostics.Entity.DatabaseErrorPageMiddleware.<Invoke>d__6.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.GetResult() 
    at Microsoft.AspNet.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__7.MoveNext() 

Najśmieszniejsze jest to, że jakoś StaticFileMiddleware jest zaangażowany w przetwarzanie prosty wniosek do regulatora. Chociaż mogę rozwiązać ten problem poprzez zmianę kolejności konfiguracji aplikacji poprzez wywołanie

app.UseMvc(... 

przed

app.UseStaticFiles() 

nadal chcę wiedzieć, jak to się stało i co jest prawidłowa kolejność konfiguracji aplikacji.

Należy pamiętać, że wszystkie wcześniej dodane kontrolery działają poprawnie z obydwoma sposobami konfiguracji, ale nowy może pracować tylko z tymi ostatnimi.

Nowy kontroler nie działa z plikami statycznymi.

EDITED Routing: W sterowniku:

[Route("api/[controller]")] 
    public class ViewsController : Controller 
    { 
     [HttpGet("{path}", Name = "Views")] 
     public async Task<IActionResult> Get(string path) 
     { 
      return Json("bla"); 
     } 
    } 

W Startup.cs:

app.UseMvc(routes => 
     { 
      routes.MapRoute(
       name: "angular2app", 
       template: "ng/{*.}", 
       defaults: new { controller = "Home", action = "Index" }); 

      routes.MapRoute(
       name: "api", 
       template: "api/{controller}/{action}/{id?}"); 

      routes.MapRoute(
       name: "default", 
       template: "{controller=Home}/{action=Index}/{id?}"); 
     }); 

niespokojnych prośba:

http://localhost:5000/api/Views/blablapath 

Answer 1

Jak to działa jest to, że przeglądarka spełnia wymagania na serwerze serwer przesyła dalej żądanie do hosta, słuchając tego portu. Środowisko hostingowe może być IIS na Windows lub środowisko hosta w systemie Linux lub Windows. Środowisko hostingu rozpoczyna uruchamianie potoku aplikacji, zaczynając od pierwszego oprogramowania pośredniego. Kawałek oprogramowania pośredniego może zrobić dwie rzeczy, jak widzę:

Odpowiedz bezpośrednio i nie wykonuj pozostałej części potoku (nadal będzie wykonywał oprogramowanie pośrednie, które jest przed nim w rurociągu) Manipuluj odpowiedzią w taki czy inny sposób , które mogą być uwierzytelnianie lub dodać jakieś dodatkowe dane do odpowiedzi

statyczne pliki, takie jak HTML, CSS i JavaScript obrazu, są trwałe, że aplikacja ASP.NET rdzeń może służyć bezpośrednio do klientów . Aby pliki statyczne mogły być wyświetlane, musisz skonfigurować oprogramowanie pośrednie, aby dodać pliki statyczne do potoku. app.Use UseStaticFiles() powoduje, że pliki w katalogu głównym (domyślnie wwwroot) są obsługiwane.

Metoda rozszerzenia UseMvc() dodaje oprogramowanie pośredniczące do routingu do potoku żądania i konfiguruje MVC jako domyślną procedurę obsługi.

Widzisz, że w używanym urządzeniu MVC Middleware powinieneś dostarczyć zasoby plików statycznych i to jest to, o czym mówi już twój wyjątek.