Getting Started with ASP.NET MVC 5

This section documents ASP.NET MVC 5.3.x, ASP.NET Web API 2.2, ASP.NET Web Pages 3, OWIN/Katana, SignalR 2, and ASP.NET Identity 2 — all running on .NET Framework 4.8.1 — the System.Web-hosted MVC framework, its routing, Razor views, HTML helpers, model binding, filters, and the OWIN-based authentication/Identity stack — as described by the official documentation at Microsoft Learn (plus Web API, Web Pages, SignalR, and Identity), which are the reference these pages are written and verified against.

This is not ASP.NET Core MVC. ASP.NET MVC 5 is the pre-Core, System.Web-hosted MVC framework; it is functionally frozen and receives only security fixes. For the current, cross-platform MVC framework see MVC Controllers and Views under ASP.NET Core (Blazor).

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

This section’s bibliography lists the reference material consulted while preparing these pages.

This page covers ASP.NET MVC 5.3.x on .NET Framework 4.8.1 — not ASP.NET Core MVC — from an installed Visual Studio to a running project: the project template, the startup sequence, and the folder conventions that every other page in this section assumes.

The MVC 5 project template

Visual Studio’s ASP.NET Web Application (.NET Framework) template, with the MVC project type selected, scaffolds a working application: a home controller, a shared layout with Bootstrap, a web.config, and (if authentication is enabled) an account controller wired to ASP.NET Identity. Unlike ASP.NET Core, there is no dotnet new — the template is a Visual Studio / msbuild artifact, and NuGet restores the framework packages into packages/ (or the project-local packages.config).

See Getting Started with ASP.NET MVC 5.

Global.asax and Application_Start

Global.asax is the application file; its code-behind, Global.asax.cs, defines the MvcApplication class that System.Web instantiates once per application domain. Application_Start runs exactly once, before the first request is served, and is where every App_Start/*.cs registration class is invoked:

// Global.asax.cs
public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        GlobalConfiguration.Configure(WebApiConfig.Register);   // Web API 2
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }
}

Global.asax also exposes application-level events — Application_BeginRequest, Application_Error, Application_End, Session_Start — which are still System.Web (HttpApplication) events, not MVC events; MVC’s own extensibility points (routing, filters, model binding) are configured from inside Application_Start, not by handling these events directly. See ASP.NET Application Life Cycle Overview for IIS 7.0.

The App_Start configuration classes

The template splits startup configuration into one static class per concern, each with a Register method called from Application_Start:

File Registers

RouteConfig.cs

MVC’s RouteCollection (RouteTable.Routes) — see Routing and Areas.

BundleConfig.cs

Script and style bundles (System.Web.Optimization) — see Bundling and Client-Side Integration.

FilterConfig.cs

Global action filters (GlobalFilters.Filters) — see Filters.

WebApiConfig.cs

Web API 2’s separate HttpConfiguration — routes, formatters, message handlers — see ASP.NET Web API 2.

IdentityConfig.cs

ASP.NET Identity 2 managers and validators (ApplicationUserManager, ApplicationSignInManager) — see Authentication, Identity, and OWIN.

Startup.Auth.cs (partial Startup class, App_Start/)

The OWIN authentication middleware, invoked via [assembly: OwinStartup(typeof(Startup))] rather than from Application_Start — OWIN has its own bootstrapping path, independent of `System.Web’s.

 
// App_Start/RouteConfig.cs
public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional });
    }
}

NuGet packages and how their versions interlock

MVC 5 is distributed as NuGet packages layered on top of one another; the packages must be updated together, never individually, because each one’s Razor/parser dependencies are pinned to an exact sibling version:

  • Microsoft.AspNet.Mvc (5.3.x) depends on Microsoft.AspNet.Razor and Microsoft.AspNet.WebPages at matching versions.

  • Microsoft.AspNet.Razor (3.x) is the Razor parser/generator shared by MVC and Web Pages.

  • Microsoft.AspNet.WebPages (3.x) supplies the base .cshtml page infrastructure that both MVC views and standalone Web Pages sit on top of.

  • Microsoft.AspNet.WebApi (5.2.x, "Web API 2.2") is versioned and shipped independently of MVC — despite living in the same Visual Studio template, Web API is architecturally a separate framework (its own ApiController, its own pipeline; see ASP.NET Web API 2) that only happens to typically be hosted in the same MVC project.

<!-- packages.config (excerpt) -->
<package id="Microsoft.AspNet.Mvc" version="5.3.0" targetFramework="net481" />
<package id="Microsoft.AspNet.Razor" version="3.2.9" targetFramework="net481" />
<package id="Microsoft.AspNet.WebPages" version="3.3.0" targetFramework="net481" />
<package id="Microsoft.AspNet.WebApi" version="5.3.0" targetFramework="net481" />

Upgrading only Microsoft.AspNet.Mvc via NuGet (right-click Manage NuGet Packages) pulls its pinned Razor/Web Pages dependencies automatically; hand-editing individual <package> versions is a common source of assembly binding-redirect errors in web.config. See the ASP.NET previous-versions documentation index for the full MVC 5 package set.

Folder conventions

MVC 5 relies on convention over configuration for locating controllers and views:

/Controllers/HomeController.cs        # class names end in "Controller"; MVC strips the suffix for routing
/Views/Home/Index.cshtml              # {controller}/{action}.cshtml, resolved by the default view engine
/Views/Shared/_Layout.cshtml          # shared layouts and partials searched when a controller-specific view is not found
/Views/web.config                     # namespace imports + locks down direct browsing (see below)
/Models/                              # POCOs and, commonly, EF6 entities -- see xref:web/aspnet/mvc/data-access-ef6.adoc[Data Access with EF6]
/App_Start/                           # the Register classes above
/Areas/Admin/Controllers, /Views, ...  # self-contained sub-applications -- see xref:web/aspnet/mvc/routing-and-areas.adoc[Routing and Areas]

Visual Studio’s scaffolding (right-click a controller folder → Add → Controller…​) generates a controller plus matching CRUD views from a model class and, optionally, a DbContext, using T4 templates (CodeTemplates/AddController) that can themselves be customized per-project.

Views/web.config is not the application’s web.config — it is a second, view-scoped configuration file that imports namespaces available to every Razor view without an explicit @using, and sets <httpHandlers>/<handlers> to return HTTP 403 for direct requests to .cshtml files (views are only ever rendered through the MVC pipeline, never served as static files):

<!-- Views/web.config (excerpt) -->
<system.web.webPages.razor>
  <pages pageBaseType="System.Web.Mvc.WebViewPage">
    <namespaces>
      <add namespace="System.Web.Mvc" />
      <add namespace="System.Web.Mvc.Ajax" />
      <add namespace="System.Web.Mvc.Html" />
      <add namespace="System.Web.Optimization" />
      <add namespace="System.Web.Routing" />
    </namespaces>
  </pages>
</system.web.webPages.razor>

Next: The MVC Pattern and Request Life Cycle traces what happens between a request arriving and a view rendering.