Skip to content

Latest commit

 

History

History
36 lines (25 loc) · 2.13 KB

README.md

File metadata and controls

36 lines (25 loc) · 2.13 KB
Raw

Aspire Orchestrating ASP.NET Proof of Concept

An experiment to use an ASP.NET MVC project with .NET Aspire. I'm hoping this might eventually form the basis of a library.

The Aspire AppHost orchestrates

  • coreApi: an ASP.NET Core Web API
  • frameworkMvc: an ASP.NET MVC project
    • the project is started via IIS Express, reading the config in .vs\AspireNetFramework\config\appliationhost.config
    • contains service references to
      • the service endpoints of coreApi
      • the SQL Server database mydatabase
      • Aspire injects these to the IIS Express process as environment variables, which can be read via ConfigurationManager after setting up Microsoft.Configuration.ConfigurationBuilders.EnvironmentConfigBuilder in the web.config
  • coreMvc: an ASP.NET Core MVC project
    • contains service references to
      • the service endpoints of frameworkMvc, for use with YARP
      • the service endpoionts of coreApi (although currently unused)
      • the SQL Server database mydatabase

Why???

For those of us on the ASP.NET->ASP.NET Core migration path (using the incremental approach), the developer inner loop can be a bit rough. For a simpler solution of a database, web api, and frontend web app, config already gets a bit more complex (db conn string, web api URL, plus the legacy web projects now being proxied by the aspnetcore projects), plus we now have four projects we need to ensure Visual Studio starts. I think it would be great if we could make this easier, which (excluding the support for legacy ASP.NET projects) was a goal of Aspire as well.

Current shortcomings

Some areas where work is needed:

  • Visual Studio debugger isn't automatically attached to frameworkMvc
    • it can be attached manually though (Debug->Attach to Process...)
  • the ports for frameworkMvc bypass the Aspire AppHost's proxy

TODO

Aside from resolving shortcomings, other things to add for this experiment include

  • inject the RemoteApiKey value used by System.Web Adapters from the AppHost, rather than setting in two separate config files