The basics of publishing your .NET Core web app

This article refers to project.json which Microsoft has deprecated in favour of a revamped .csproj file.

A new article will be published shortly and I’ll put a link here.

So far we’ve looked at:

So how can we get our shiny new app out there for the world to see?

Publishing your ASP.NET Core application

There are lots of options for hosting your .NET Core application, especially now you can choose linux and take advantage of potentially cheaper hosting.

Whatever you choose, a useful first step is figuring out how to package up your app so you can publish it to your chosen host.

dotnet publish --output "c:\temp\CoreAppWeb"

Run this and you’ll see a handy message indicating that your app has been published to the folder you specified.

dotnet publish

Take a look in that folder and you’ll find a portable version of your project which can be hosted in any number of places (including on Linux or via IIS on Windows).

When you publish your application as a Portable app you’ll need to install .NET core on your target machine (this can be Windows, Linux, Mac or via Docker).

It is also possible to deploy your application as a self contained app which an be published and run on any machine even if it doesn’t have the .NET Core runtime installed. This requires a slightly different approach which we’ll look at in a subsequent post.

Missing Views

Have another look and you may notice a glaring omission. Depending on how you created your project, you might find that your views are absent from the published output.

Core app with no views

If this is the case, it’s most likely because you haven’t explicitly added the views folder to your publish settings in project.json.

  "version": "1.0.0-*",
  "buildOptions": {
    "preserveCompilationContext": true,
    "debugType": "portable",
    "emitEntryPoint": true
  "publishOptions": {
    "include": ["Views"]
  "tools": {

You’ll need to include anything that is needed for your web site to run in production. This includes things like config files (e.g. web.config).

You can include or exclude folders or file extensions. Here’s another example.

  "publishOptions": {
    "include": ["**.cshtml", "web.config"]

With either of the above changes, you’ll now find you have a views folder in your published output.

Core app with views

To infinity and beyond

A word of caution. If you simply run this command…

dotnet publish

your project will be published to the default location which is inside your application’s bin folder.


If you then choose to use wildcards to include all cshtml files (**.cshtml) then the dotnet command will look for all cshtml files in your application folder which will include the ones in your bin folder, then include these in the published output.

Do this a few times and you’ll end up with a massive nested folder structure and run into problems.

recursive folders

You can avoid this hassle by specifying an output path somewhere outside of your application folder.

dotnet publish --output "c:\somewhereelse\CoreAppWeb"

Debug vs Release

If you’re looking to publish your site to a production host you’ll want to package it up in release mode.

By default, publish produces debug output, this is fine if you need to debug your code but is not optimised and will perform slower than if you publish in release mode.

dotnet publish --output "c:\somewhereelse\CoreAppWeb" --configuration release

Testing the output

Let’s say you want to test that your published output actually works.

In a command prompt, CD to your published output, then run your application.

cd c:\somewhereelse\CoreAppWeb
dotnet Coreapp.dll

Note that you don’t need to call dotnet run just dotnet followed by the name of your compiled dll.

Compiled output

If all has worked correctly, you’ll see the usual message indicating that your app is up and available at the default address.

Running from published output

What next?

So now you’ve got your nicely published web application, what can you do with it?

If you’re going to host your application using IIS, Rick Strahl’s excellent guide on running Core applications with IIS is well worth a read.

Alternatively you might want to look at deploying your app on linux using docker.

  • Pingback: Dew Drop - August 19, 2016 (#2312) - Morning Dew()

  • Pingback: The basics of publishing your .NET Core web app - JonHilton.Net - How to Code .NET()

  • Pingback: The week in .NET – 8/23/2016 | .NET Blog()

  • Pingback: Szumma #054 – 2016 34. hét | d/fuel()

  • Pingback: Notes from the ASP.NET Community Standup – August 30, 2016 | .NET Web Development and Tools Blog()

  • Pingback: Curated links of 4 Oct 16 – DiscVentionsDaily()

  • hi,
    I run my app using `return View(“/Views/v1.cshtml”);` and the `Views` got copied to the publish folder, but once i run it from the publish folder, it looks the app is not seeing my file?


    • Hi.

      Not sure (without seeing this in context) why that would be failing.

      Saying that, is there any specific reason you’re using absolute paths for the views?

      I generally stick to using the view name and not it’s path.

      By way of example, say I did the following.

      Created a controller called TestController.
      Created an Action called Index() which returns View(“TheView”).
      Created a view in my views folder, inside a “Test” subfolder as follows…

      Views > Test > TheView.cshtml

      public class TestController : Controller
      // GET: //
      public IActionResult Index()
      return View("TheView");

      ASP.NET Core will use convention to “look” for the view. In this case it finds the view using the controller name (“Test”) and then the view name (“TheView”).

      As far as I know, this approach will work irrespective of how the app is then published because it doesn’t rely on any specific paths and has the benefit of less code (when specifying the view in a controller) and predictability in that all views will fall within a predictable structure (generally controller name then view name) like so…


      Hope that helps.

      • Thanks,
        I just re-wrote it as `return View(“Views/v1.cshtml”);` and it worked file, so apparently no need to mention the relative path.


  • Lee Alderdice

    Hi Jon,

    I am having a tough time deploying .Net Core. The app is running but falling over in places where is doesn’t when debugging. I am not a techie by trade, just learned on the job which has its downfalls. A couple of questions:

    I have a ViewModels folder – should I explicitly include it or will it be bundled automatically as it strongly typed in views?

    When I publish, my App.dll is showing as last modified several months ago and changes to controllers are not being reflected in the published application. e.g. An action going to a specific view or containing View.Message updates is not working at all. Why would that be?

    I have spent hours on stackoverflow reading people’s comments and issues, getting no further. Your help would be greatly appreciated in understanding why publish is failing in these areas … I am happy to share any code as needed.

    Many thanks