ASP.NET vNext

For the past few months I've been working on what we're now calling ASP.NET vNext (don't worry I haven't forgotten about SignalR).

A better platform for building web applications with .NET

We took a look at some of the common problems that exist in our ecosystem today, and took best practices learned around .NET, ASP.NET and web development over the years and combined them to come up with the following requirements:

  • Low friction development experience
    • NuGet packages are the unit of reference (not assemblies)
    • Projects and NuGet packages are interchangeable. Projects can depend on packages and packages can depend on projects.
    • Runtime compilation; building a binary on disk isn't required to run (thank you Roslyn).
      • Ability to change code and f5 in the browser without an explicit build step.
    • Unified compilation; Same design time and runtime compiler. No more web.config <compilation> section.
    • First class ability to produce NuGet packages from the project system.
    • Human readable and easy to author project files with default conventions.
  • Dependency injection *everywhere*
  • Fast cold start times
  • Low memory footprint
  • Lightweight pay as you go stack
  • No dependency on System.Web
  • No strong naming (yes I said it)
  • Side by side runtimes
  • OSS by default
  • Excellent Visual Studio experience.

Things we wanted to fix

There are a bunch of problems we wanted to fix that exist in the current stack:

  • MVC, WebAPI and SignalR all scan for assemblies (using either BuildManager or by looking at the loaded assemblies) looking for types that implement some interface/base class. We wanted to make this more efficient.
  • View compilation is always configured separately from your normal project compilation.
  • View page errors don't show up in the IDE alongside normal compilation errors.
  • Today we have two ASP.NET project types: Web Site and Web Application Projects; they each have their strengths and weaknesses. We wanted to unify these.
  • Dependency Injection is different across all of our frameworks (WebAPI, MVC and SignalR). Each of our frameworks came to life at different times and all implemented their own version of dependency injection extensibility.
  • Web API and MVC were different but had very similar programming models. Occasionally people would get confused about what to pick and when to pick it. It even sparked some debate among the ASP.NET community

System.Web

It's hard to talk about ASP.NET without mentioning System.Web. It's easy to say that System.Web is this big monolithic, poorly layered assembly, but it has tons of useful functionality. Let's take a tour of the things that go missing when we don't have System.Web in the picture:

  • IIS Integration (Native module)
    • aspnet_regiis
  • web.config <system.web> section
  • BuildManager and the ASP.NET compilation system
    • aspnet_compiler
    • VirtualPathProvider
  • HttpRuntime.Cache
  • Routing
  • HttpContext and friends
  • HttpUtility
  • Session
  • Health Monitoring
  • Profile/Membership
  • MS Ajax
  • JavascriptSerializer
  • WCF/IIS Integration
  • MachineKey
  • OutputCache

Does dropping System.Web means I will lose this functionality?

Nope, we've re-layered things into separate components that you can pick à la carte.

Next post I'll go over the different components that make up ASP.NET vNext.

Bonus

We are working with the Mono team to make it work with *nix, osx

comments powered by Disqus