Codebelt.Template.WebApp.Razor 1.0.0

ASP.NET Core Web App for Razor

Sample ASP.NET Core Web App for Razor reference application, powered by Codebelt, based on the standard project generated by Microsoft.

Getting Started

There are two ways to use this reference application:

You can clone this project: git clone


Open Powershell and run the following command to install the solution template:

dotnet new --install Codebelt.Template.WebApp.Razor

This installs the ASP.NET Core Web App by Codebelt template globally on your machine and can then be used from either Visual Studio UI or .NET CLI. If the latter is chosen, navigate to a new directory where you want to place the solution, and copy the path of the opened directory (eg. %USERPROFILE%\source\repos\MyRazorApp).

Run the following command:

dotnet new cb-webapp -o C:\Users\gimlichael\source\repos\MyRazorApp

In this example I am naming my new solution MyRazorApp and my %USERPROFILE% points to C:\Users\gimlichael. The rest should be pretty self explanatory.


  • Environment is set to LocalDevelopment
  • The approot and cdnroot folder should only be used locally, eg. LocalDevelopment environment

Solution Structure

The solution file, docker-compose and preview nuget sources is placed in the root of the repo.

The project itself, Codebelt.Template.WebApp.Razor, is placed in src.

Example of structure:

/src/Codebelt.Template.WebApp.Razor/approot/<static files tailored to the app>
/src/Codebelt.Template.WebApp.Razor/cdnroot/<static files shared by many>
/src/Codebelt.Template.WebApp.Razor/Pages/<default razor pages by Microsoft>


All Codebelt projects work with 4 different types of environments, where only one deviates from industry standards; LocalDevelopment.

However, more often than not, we need to have an environment that was thought out to be an isolated environment for developer machines, eg. allow more relaxed rules in terms of user secrets, local dependencies and so forth.

Development, in particular, should be used for centralized developer testing before pushing changes to Staging.

  • LocalDevelopment (typically where the app is being forged)
  • Development (centralized developer testing of the app)
  • Staging (dress rehearsal of the app)
  • Production (done-done - we are live)

Development, Staging and Production should be environments outside the developers machine, as these (depending on your setup) are part of the CI/CD flow and used for their respective scopes.


The 3 Docker files each has there own role:

  • Dockerfile (the app itself)
  • (the static files tied to the app)
  • Dockerfile.cdn-static (the static files suited to be shared between your apps on a CDN)


As a quick example I have spun up 3 environments matching what is defined in appsettings.Development.json, appsettings.Staging.json and appsettings.Production.json.

CDN is setup on Azure using a source origins poiting to, and

This is just to provide seed of inspiration.

You can test the 3 environments yourself (nothing fancy; just the sample code provided by Microsoft adjusted to "static content separation"):

Code with passion; love your code; deliver with confidence 👨‍💻️🔥❤️🚀

Version: 1.0.0 Availability: .NET 6.0   # ALM - ADDED TFM for .NET 6 - CHANGED Dependencies to latest and greatest with respect to TFM   # New Features - ADDED .template.config folder to the solution in order to enable support for VS/.NET IDE project template Version: 0.0.0 Availability: .NET 5.0   # New Features - ADDED Program.cs class in the Codebelt.Template.WebApp.Razor namespace that is the entry point for the web app - ADDED Startup.cs class in the Codebelt.Template.WebApp.Razor namespace that is the boostrapper of the web app - ADDED Microsoft sample website tweaked with use of segregated static content for both the app itself and shared content - ADDED Docker configurations that consist of three endpoints; the app itself, static content for app and static content for CDN provider

This package has no dependencies.

Version Downloads Last updated
1.0.0 3 01/02/2022