ASP.NET Core is a complete rewrite of the original ASP.NET stack — not an incremental update. It shares the Model-View-Controller pattern, Razor syntax, and C# controllers with its predecessor, but the underlying hosting model, request pipeline, configuration system, and dependency injection container are entirely new. For the Cycle Store, this means the MVC concepts in place today translate directly to ASP.NET Core equivalents, but the infrastructure code surrounding them must be replaced file by file.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/aws-samples/legacy-cycle-store-mvc-app/llms.txt
Use this file to discover all available pages before exploring further.
Project File Changes
The legacy project uses apackages.config file to declare NuGet dependencies and a traditional .csproj format that lists every source file explicitly. ASP.NET Core projects use the SDK-style .csproj format, which automatically includes all .cs and .cshtml files in the project directory and declares NuGet packages inline as <PackageReference> items.
- Legacy (packages.config)
- Modernized (.csproj PackageReference)
<TargetFramework>netcoreapp3.1</TargetFramework> element replaces the old <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>. The Microsoft.NET.Sdk.Web SDK brings in the ASP.NET Core framework reference automatically.
Startup and Hosting
The legacy application usesGlobal.asax as its entry point and delegates configuration to static classes (RouteConfig, FilterConfig, BundleConfig). ASP.NET Core replaces this pattern with two files:
Program.cs— creates and runs the web host.Startup.cs— configures services (dependency injection) and the HTTP request pipeline (middleware).
Global.asax file and all static configuration classes (RouteConfig.cs, FilterConfig.cs, BundleConfig.cs) are deleted from the project.
Controllers
ASP.NET MVC 4 controllers inherit fromSystem.Web.Mvc.Controller. ASP.NET Core controllers inherit from Microsoft.AspNetCore.Mvc.Controller. The method signatures, ActionResult return types, ViewBag, and View() / RedirectToAction() helpers all work the same way.
- Legacy (MVC 4)
- Modernized (ASP.NET Core 3.1)
using statement is the only mandatory change for most controllers. Constructor injection replaces direct instantiation, and ViewBag, ActionResult, View(), and RedirectToAction() remain fully compatible.
SiteLayoutController Child Actions
The legacy application uses aSiteLayoutController to render shared layout sections — header, footer, and content navigation — via [ChildActionOnly] actions called from the master layout with @{Html.RenderAction("HeaderLayout", "SiteLayout")}.
Child actions ([ChildActionOnly]) do not exist in ASP.NET Core MVC. The equivalent feature is View Components — self-contained units that have their own class and partial view, and are invoked from Razor with @await Component.InvokeAsync("ComponentName").
Views/Shared/Components/HeaderLayout/Default.cshtml. Replace each @{Html.RenderAction(...)} call in _Layout.cshtml with the View Component invocation:
Routing
Convention-based routing is configured inStartup.Configure rather than in a static RouteConfig class. The route pattern syntax is unchanged — {controller}/{action}/{id?} works exactly as before:
{resource}.axd/{*pathInfo} ignore route is not needed in ASP.NET Core because .axd HTTP handler endpoints no longer exist.
Configuration
Web.config is replaced by appsettings.json as the primary configuration file. Environment-specific values are supplied through appsettings.{Environment}.json files or environment variables, which slot naturally into container deployments.
<appSettings> in Web.config via ConfigurationManager.AppSettings["key"] are now read through IConfiguration:
The
Web.Debug.config and Web.Release.config XML transform files are removed. In ASP.NET Core, per-environment overrides are handled by appsettings.Development.json and appsettings.Production.json — these files are automatically merged over the base appsettings.json based on the ASPNETCORE_ENVIRONMENT environment variable. For sensitive values (passwords, connection strings) in production, use environment variables or AWS Secrets Manager rather than committing them to any config file.Views
Razor views (.cshtml) are largely compatible between MVC 4 and ASP.NET Core MVC. Most views migrate without changes. There are two specific patterns to update:
1. Child action calls — replace @{Html.RenderAction(...)} with View Component invocations as described in the SiteLayoutController section above.
2. Layout file naming — the _SiteLayout.cshtml master layout used in the legacy app should be renamed to _Layout.cshtml, which is the ASP.NET Core convention. Update _ViewStart.cshtml to reference the new name:
_ViewImports.cshtml file should also be added to the Views folder to make tag helpers and common namespaces available across all views:
Error Handling
The legacy application registers a globalHandleErrorAttribute filter in FilterConfig.cs to display a generic error view when an unhandled exception occurs. In ASP.NET Core, exception handling is a middleware concern configured in Startup.Configure:
UseDeveloperExceptionPage() shows the full stack trace during local development. UseExceptionHandler("/Error") redirects to an error controller action in production — add an ErrorController with an Index action and a corresponding view to handle this gracefully.