Auto publish Azure Web Jobs with ASP.Net Core RTM

by Frans Lytzen | 26/08/2016

This is an update of my original post on how to do this with ASP.Net Core RC1
At the time of this writing, there is no tooling to auto publish Azure Web Jobs with an ASP.Net Core website. You can do it with old-style websites, but not yet the new ones. The tooling is highly likely to appear eventually, but as of right now you have to take a few steps to set it up yourself, which is what I describe in this post. For clarity, what I am describing works only with source control deploy (git etc), not with publishing from Visual Studio.

This information will eventually become obsolete, probably around the RTM of the ASP.Net Core Visual Studio tooling. If that has happened and I have not updated the post, please post a comment and I'll get on it.
Note that for very simple, self-contained web jobs, there may be a simpler approach (see http://stackoverflow.com/a/33291097/11534 for some thoughts). In this post I am catering for the scenario where your webjob references another project in your solution - though it'll work just as well if it doesn't.

In summary

You have to use a custom deployment script and insert an action to publish your webjob to the path that Azure looks for webjobs in; App_Data/Jobs/Continuous for continuous jobs. Azure will automatically detect content in that folder and assume it's a webjob, so all we really have to do is make sure our webjob is copied there. And yes, it will happily overwrite a running webjob, the Kudu functionality handles that somehow.

The reason we are publishing, using dotnet publish, is to ensure we get all the dependencies. It won't re-compile so it's just a copy operation.
If we had a very simple webjob that was self contained, you could just copy the files, as long as you added a run.cmd (see link above).

In detail

Prepare a site
  1. Set up a solution with an ASP.Net 5 Web site and a webjob written as a ASP.Net 5 / Core console app.
  2. Set up source control deploy to an Azure website. It shouldn't matter which type.
  3. Wait for the initial deploy of the site. 

Set up a custom deployment script

In this example, we will download the deployment script that Azure has created. There are ways to also do this with the Azure CLI, but the generated script is not quite the same at this point in time - which may or may not matter.
  1. Get the auto generated script
    1. Log in to the web app console at https://[yoursite].scm.azurewebsites.net
    2. Go to Tools - Download deployment script
    3. Unzip the downloaded zip file to the root of your solution folder
  2. Modify your deploy.cmd file in the following ways
    1. Add a line like this near the top - just to make it easier to check that your custom script is being used (whatever you put after echo will be output in the log file)
      echo CUSTOM SCRIPT Start
    2. Near the middle of the file you will find a series of steps that are numbered. One of the steps will look like this;
      NOTE: The indented lines will be on a single line, the line breaks are only added here for readability
      :: 2. Build and publish
      call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MySolution.sln"
      /nologo
      /verbosity:m
      /p:deployOnBuild=True;
      AutoParameterizationWebConfigConnectionStrings=false;
      Configuration=Release;
      UseSharedCompilation=false;
      publishUrl="%DEPLOYMENT_TEMP%"
      %SCM_BUILD_ARGS%

    3. Below that insert these lines (updating the path with the actual path to your webjob in the solution)
      NOTE: The indented lines need to put on a single line, the line breaks are only here for readability
      :: 2.1 Publish webjobs
      echo STARTING TO PUBLISH WEBJOBS
      echo DEPLOYMENT_TEMP is %DEPLOYMENT_TEMP%
      call :ExecuteCmd dotnet publish
      "%DEPLOYMENT_SOURCE%\src\MyWebJob\project.json"
      -o "%DEPLOYMENT_TEMP%\App_Data\Jobs\Continuous\MyWebJob"
      -c Release
      If you have more than one web job, just add individual publish lines for each one

Check that it worked

Push your changes and wait for Azure to deploy, then look at the webjobs in the Azure portal. You should see your job there. In case you don't, have a look at the publish log file to see if there are any errors in there.


Share this article

You Might Also Like

Explore more articles that dive into similar topics. Whether you’re looking for fresh insights or practical advice, we’ve handpicked these just for you.

Why Automated Azure Cost Tools Aren’t Enough

by Frans Lytzen | 27/02/2026

Automated Azure cost optimisation tools are useful — but they don’t tell the whole story. Especially if you’re building and running your own applications in Azure. Real savings often sit at the architecture and code level, where experience and application insight outperform generic automation.

The AI Adoption Paradox: Why Waiting for Strategy (or Rushing Ahead) Is Holding You Back

by Sean Worthington | 23/02/2026

AI adoption often stalls between endless strategy and fragmented experimentation. Instead of choosing one, organisations can evolve both in parallel — building clearer objectives, growing confidence and delivering measurable value along the way.

AI in Core Business: Where Real Competitive Advantage Is Built

by James Gregory | 13/01/2026

AI creates real competitive advantage when it’s embedded in core business decisions and workflows – not just support functions. Here’s why leaders must rethink where AI is applied to unlock meaningful value.

Privacy & Cookies

Contact Us

NewOrbit Ltd.
Hampden House
Chalgrove
OX44 7RW


020 3757 9100

NewOrbit Logo

Copyright © NewOrbit Ltd.