This lesson will cover building, compiling, and launching ASP.NET Core MVC projects so we can run our FriendLetter application in the browser.

Building and Running ASP.NET Core MVC Applications

---

Our ASP.NET Core MVC projects are a combination of pre-existing code and custom code we write ourselves. This is the point of a framework: it provides pre-made reusable functionality for commonly-used tasks like rendering webpages in a browser that developers can utilize to more quickly scaffold projects.

So far, we've only added framework code. Next, we'll use part of the .NET framework called MSBuild to add custom code.

MSBuild

MSBuild is also known as Microsoft Build Engine or Microsoft Build Tools. It turns code in a project directory into a cohesive application by toggling settings, customizing how packages are introduced into the rest of the codebase, and more.

If the code or project is the combination of raw ingredients, MSBuild is the oven where our ingredients become a fully-fledged meal. There's no need to worry about the technical specifics of MSBuild quite yet, but if you're curious, check out the MSBuild section of the Microsoft documentation.

Building

Let's use MSBuild to build our project. We'll start by running dotnet restore in our FriendLetter.Solution/FriendLetter directory.

To run MSBuild, we'll run this command from the same directory:

$ dotnet build

Running

Now let's try running our project in the browser. We'll run the following command in our FriendLetter.Solution/FriendLetter directory:

$ dotnet run

After running this command, we'll see a response like this:

Hosting environment: Production
Content root path: /Users/epicodus_staff/Desktop/FriendLetter.Solution/FriendLetter
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

Note the line Now listening on: http://localhost:5000. Let's type localhost:5000 into our browser's URL bar. The text "Hello World!" will appear in the browser.

Where is "Hello World!" coming from? Let's take another look at the Configure() method in Startup.cs:

...

public void Configure(IApplicationBuilder app)
{
  ...

    app.Run(async (context) =>
    {
      await context.Response.WriteAsync("Hello World!");
    });

  ...
...

These lines of code tell our app to print "Hello World" if a proper MVC route cannot be found. We haven't created any routes yet so our application displays this filler text instead. We'll learn about routes in the next few lessons.

It may not seem like much, but we've successfully configured, built, and launched our first ASP.NET Core MVC application.

Maintaining Organized Projects

---

After running these commands, our FriendLetter.Solution/FriendLetter project directory has new files in a bin subdirectory. Our project structure now looks like this:

FriendLetter.Solution
└── .gitignore
└── FriendLetter
    ├── FriendLetter.csproj
    ├── Program.cs
    ├── Startup.cs
    ├── bin
    │   └── Debug
    │       └── net5.0
    │           ├── FriendLetter.deps.json
    │           ├── FriendLetter.dll
    │           ├── FriendLetter.pdb
    │           ├── FriendLetter.runtimeconfig.dev.json
    │           └── FriendLetter.runtimeconfig.json
    └── obj
        ├── Debug
        │   └── net5.0
        │       ├── FriendLetter.AssemblyInfo.cs
        │       ├── FriendLetter.csproj.CoreCompileInputs.cache
        │       ├── FriendLetter.csproj.FileListAbsolute.txt
        │       ├── FriendLetter.dll
        │       └── FriendLetter.pdb
        ├── FriendLetter.csproj.nuget.cache
        ├── FriendLetter.csproj.nuget.g.props
        ├── FriendLetter.csproj.nuget.g.targets
        └── project.assets.json

Let's try an experiment. Don't commit this new content yet.

• Delete the FriendLetter.Solution/FriendLetter/obj directory. Confirm it's removed from the project entirely.
• Delete FriendLetter.Solution/FriendLetter/bin in the same way. Confirm it's removed from the project.
• Now run the following commands in the FriendLetter.Solution/FriendLetter project directory:
  • > dotnet restore
  • > dotnet build

If we revisit our project in our code editor, we'll see that the obj and bin subdirectories are there even though we deleted them. This is because dotnet restore installs the packages listed in our .csproj file, creating obj and its contents while dotnet build creates internal content for our build in bin.

Because we can install and build everything with just a few commands, it's best practice to exclude the obj and bin directories from our Github repositories. This ensures our repositories primarily contain code we've written, which helps keep our repos organized and easy to navigate.

When we or other developers want to retrieve and run the project from Github, we can simply clone the repo and run dotnet restore and dotnet build in the production project's directory to recreate all necessary directories and files.

.gitignore Review

The Git Best Practices and Adding a .gitignore lesson from JavaScript showed us how to omit certain files from a repository. The .gitignore in our .NET projects should include the following:

*/obj/
*/bin/
.vscode

$ dotnet build

$ dotnet run

obj/
bin/