Build and publish an ASP.NET core application using Visual Studio.

This is part I of the blog post series in which I share some of the ways I have learned to build and deploy an ASP.NET core 2 application to IIS running on Windows Server VM.

In this post, we’ll cover just the basics of how to build and publish an ASP.NET core 2 application to a folder using Visual Studio 2017. In the process, we’ll discuss some of the concepts you should be familiar with:

• Release vs Debug build.
• Deployment mode: framework dependent deployment vs self contained deployment.

I assume you have a working ASP.NET core application which you want to deploy. If not, you can just create a new ASP.NET core project, following the documentation.

Publish an ASP.NET core application to a folder

1. Under the Solution Explorer, right click on your web app project, and select Publish.
2. The “Pick a publish target” dialog appears. Select “Folder”.
3. Click Publish

That would produce all the files necessary for running the application using the dotnet utility or on IIS. The published directory include the .dll files of the application as well as the third party libraries, and folder for static files.

The default settings build the application in Release mode, and use the Framework dependent deployment mode. You may want to adjust some of the settings to suit your needs. For example, if you are deploying to a development or test environment, you may want to build the application in Debug mode. If you don’t want to depend on the .net core framework being available on the target server, you may want to use the self contained deployment mode. To change the defaults, click on the Advanced link.

Let’s discuss some of the configurations for publishing the application .

Release vs Debug build

A debug build does not optimize the binary as it makes debugging difficult. The debug build contains .pdb files which the debugger uses to map break points to code addresses. As such, a debug build can be helpful in development or test environment. For example, in Debug mode, when an exception occurs, the stack trace contains the full path to the file as well as the exact line number to the codes where the exception occur. When building in Debug mode, even if you deploy the application to a remote server, the stack trace still show the original paths of the machine on which the application was built.

A release build optimizes the binary and is more performant. The release build does not contain extra files for debugging and thus is also smaller in size when comparing to the debug build. When deploying in a production environment, you should definitely build in Release mode.

Framework dependent vs self-contained deployment

When deploying a .NET/ASP.NET core application, you can choose to include everything your app needs to run on a targeted server, including the .net core runtime, or you can include only the app’s .dll files and third parties libraries. The first approach is called self-contained deployment, and the latter is called framework dependent deployment.

In a FDD deployment, the application contains only its own codes and third parties’ libraries. It does not contain .net core runtime and libraries. As such, a FDD deployed app depends on the server to have the compatible .net core runtime.

 Your app contains only its own code and any third-party dependencies that are outside of the .NET Core libraries

.NET Core application deployment

A FDD deployment is more efficient than a SCD deployment as multiple apps share the same .net core runtimes. However, in a FDD deployment, you don’t control the exact runtime to use for your app. Instead, the framework selects the latest patch version that is compatible for your app. For instance, if your app targets .net core 2.1.0, and the server has .net core runtime 2.2.0 installed, the framework is going to use 2.2. The feature is called “minor version roll forward”. For more details, checkout the documentation.

In a self-contained deployment, your app contains not only the .dll files and dependent libraries, but also the .net core libraries and runtime.

a self-contained deployment (SCD) doesn’t rely on the presence of shared components on the target system. All components, including both the .NET Core libraries and the .NET Core runtime, are included with the application and are isolated from other .NET Core applications

.NET Core application deployment

As such, the depends less on the server. However, the size of the deployment package is also much bigger when compared to that of a framework dependent deployment.

Now that we have gotten the published folder, in the next post , I’ll share how to deploy the application on IIS running on the remote server.

References

Quickstart: Use Visual Studio to create your first ASP.NET Core web app

Set debug and release configurations in Visual Studio