From the blog: 30 days of BuiltWithDot.Net. Thank you, status update and roadmap.

Getting started with cross platform core web development. Part 3: your first app.


In the third part of this series, you’ll create your first core web app and run it straight from Visual Studio Code, as well as from the command line. And you’ll be taking a look at the basic file structure of an core app.

by Corstiaan Hesselink

Last updated: Friday July 06, 2018Reading time: 11 minutes

With Visual Studio Code all set up in the previous part you’re ready to create your first app. Open a terminal session and run the following command:

> mkdir mydotnetproject && cd mydotnetproject

With your project folder created and navigated to, run:

> dotnet new mvc

This creates the necessary files and folders and automatically runs the command dotnet restore. This command downloads and installs all the required NuGet packages. NuGet is .net’s package manager, similar to Ruby Gems for ruby and rails, NPM for javascript and node, and Composer for php.

A little productivity hack

Now open Visual Studio Code. First we’ll enable a feature that will make you life a tiny bit easier. Open de command palette by going to View -> Command Palette... and search for “install 'code' command in PATH”. Select it from the suggestions.

Visual Studio Code add C# language extension

You should see this confirmation at the bottom right of the window:

Visual Studio Code add C# language extension

This enables the code command so you can start Visual Studio Code quickly from where ever you might be inside your terminal. It’s a cool lil’ trick that will save you numerous clicks throughout the day.

Back at the terminal, still inside the mydotnetproject folder, open Visual Studio code straight from your project folder:

> code .

Notice the dot. This tells Visual Studio Code to open the current folder, mydotnetproject.

Visual Studio Code should open and look something like this, with the folders and files of your fresh core mvc project on the left.

Visual Studio Code add C# language extension

A closer look at the files and folders

When getting into any new framework it’s good to understand the scaffolding that gets created for you when you start a new project. Let’s see what comes in the box.


This folder contains all the controllers that connect your views to the logic that is the rest of your app. If you have worked with other frameworks like Rails (ruby), Sails (node) or Laraval (php) you know what controllers are and what they do. If not, I’ve written a short intro about the main concepts of the Model-View-Controller model here.

The dotnet new mvc command created one controller out of the box called HomeController.


This folder contains, you guessed it, the models that get passed between your views and your controllers (again, I’ve written a short intro about mvc concepts here). The naming is a bit misleading as this folder should actually be called ViewModels and in this scaffolded project, there is a file in here called ErrorViewModel.cs (notice the “View” part in the filename).

The difference between a model and a viewmodel is that a viewmodel is a specific type of model that gets passed between your view and your controller to send over data, like when posting a form back to your controller or vice versa. A “normal” model, on the other hand, is a representation of an object as it saved in your database, like a User or a Product``. This is a good explanation of the differences between models and viewmodels and why you need both.

That said, the dotnet new mvc command creates a Models folder containing viewmodels, which is a little confusing. What can you do :-).

Don’t worry. All you need to know now is that there is a difference between the two.


The obj folder contains a number of temporary files that are required when you actually run and build your app to create the final binary. The exact contents are not that important at this point. Let’s move on.


This folder contains one file called launchSettings.json. This is a configuration file where settings are stored that are required when actually serving the web app, depending on the environment (development, production, etc). Getting too much into this is beyond the scope of this article.


Views is a more interesting folder as it contains all the Razor views that are responsible for rendering the html that actually gets presented to the user. Razor is a templating language similar to ruby’s ERB or node’s EJS used by Sails. Razor uses the .cshtml file extension.

Notice the subfolder called Home that contains views that each correspond to an action inside HomeController.cs inside the Controllers folder.

The Shared subfolder contains non-controllers specific views like _Layout.cshtml, which is a master view from which other views derive. This layout file contains common interface elements like headers and footer and are generally consistent across all views. By inheriting from a master layout you don’t clog up your other views with the repetitive markup of common interface elements.

dotnet new mvc created a simple template structure for you but you can expand on this as you build your app, creating nested templates to minimise markup repetition.


The wwwroot folder is the folder that gets served as the web root when publishing your app. That means that points to wwwroot and all URLs for static content like images are relative to the wwwroot folder.

All the static files in your project go here. These are files that the app will serve directly to clients, including static HTML files (NOT the Razor templates), css stylesheets, images, and javascript files.

From the microsoft docs: “Code files should be placed outside of wwwroot. That includes all of your C# files and Razor files. Having a wwwroot folder keeps a clean separation between code files and static files.

appsettings.json & appsettings.Development.json

The appsettings files are places where you can store static data your app needs like database connection strings, administrator e-mail addresses, etc. Any type of configuration data is stored in these files.

It is common that you use a slightly different app configuration during development compared to running your app live in production. For example, you probably use a different database during development and thus a different connection string. The appsettings.{environment}.json naming convention makes it easy to create different configuration settings for different environments.


Bundling is the process of combining and minimizing front-end assets like stylesheets and javascript files into a single compressed file that is faster to serve to clients. core has some basic bundling features built in that can be configured in bundleconfig.json. As you built out your app and add stylesheets and javascript files you can point the core bundler to these files by modifying bundleconfig.json.


This file has a couple of responsibilities but the most important ones are specifying the exact target version of the .net framework for this app, netcoreapp2.1 for example and keeping track of the NuGet packages and their exact versions that you are using in your project.

Generally, you don’t need to touch this file. It’s maintained by the SDK and the command-line tools as you use those to interact with your project.


This file is where the rubber of your app hits the proverbial road. This is the entry point that loads and boots your app when you run it (which we will get to in a second). At this point, your web app is just a simple console app that loads the entirety of your web site by instantiating an IWebHostBuilder using…


There is quite a bit to Startup.cs. Enough to write a separate article about. For now, it’s enough to know that this file is used mainly for two things.

  1. It’s the place where you add and configure the required services (or “dependencies”) needed by your app. For example, the mvc tooling is such a dependency. But this can also be a service for your own making, like a data access service, or 3rd party api.
  2. It’s the place where you configure the “http pipeline”. The http pipeline consists of a bunch of chained actions and commands that together form a pipeline that handles incoming requests to your web app. These actions and commands are generally called “middleware” and they each influence how a request is handled as it moves through the pipeline. For example, mvc itself is implemented as core middleware.

Here is a Microsoft approved graphic explaining the pipeline and middleware concepts visually:

Visual Studio Code add C# language extension

Running your app

So, after this general introduction to the files and folders of your fresh core mvc app, let’s wrap up by actually running it. At this point, you have two ways of running the app.

The first way is by just pressing the Debug button in Visual Studio Code. This is best while coding and allows you to debug your code while your app is running by setting “break points” and “stepping into the code”. More on this in a later article.

In Visual Studio Code click the debug tab on the left side of the window:

Visual Studio Code add C# language extension

Then click the Debug button at the top left of the window:

Visual Studio Code add C# language extension

This will start the build process. Give it a few moments to complete. When finished your browser will launch and navigate automatically to https://localhost:5001/.

And there you’ll see your app running, gloriously:

Visual Studio Code add C# language extension

Stop the app by click in Stop button from Visual Studio Code at the top of the screen:

Visual Studio Code add C# language extension

The second way of running your app is from the terminal, just like you created the initial scaffolding of your app using dotnet new mvc.

Back at the terminal, still inside the mydotnetproject folder, run the following command:

> dotnet run

This will start the build process and start your web app. Allow it a few moments to complete. After a short while you should see the following output:

Visual Studio Code add C# language extension

Manually navigate to https://localhost:5001/ and there is your app running again.

During development, you will mostly run your app from Visual Studio Code but it’s good to understand that in essence, an core web app is “just” a console app that can be run from the terminal.

What’s next?

In the next article, we’ll add a new view to our app and get into the basics of routing in core mvc. Be sure to signup below for updates.

Ready to dive into cross platform core?

Be the first to get notified when the next step is available. Delivered directly to your inbox, with my no-spam-guarantee™. Unsubscribe any time.