4
votes

A website with webjob not deploying to Azure.

I am having an issue getting a website with an associated webjob console application to deploy using continuous deployment via Visual Studio Online. I am using VS2013 with update 4 and latest Azure SDK.

  • The website, and the associated webjob, will publish to Azure using direct publish for Visual Studio and works perfectly, so I am confident the publish settings are fine.

  • The solution will build and work locally fine.

  • The solution, once checked in, will build and (seemingly) deploy fine in VSO (using CI) and Azure notes the build was successful and shows it as 'Active deployment'.

However, the website and associated webjob will not be updated.
When I have browsed the deployed files after the VSO build and deploy on Azure, all that is happening, is the binaries of the console app are being copied into the bin/ folder of the website.
None of the website files are being updated. It is almost as if it is deploying the wrong project!

If I remove the Webjob and just deploy the website, it will build and deploy fine through VSO - the website will update.

It is adding the webjob that causes some issue with the deployment via VSO.
I am confident all steps are correct to add the webjob to the WebApp, with the correct webjobs-list.json being added to the webapp and webjob-publish-settings.json to the Console app - as I said, publishing the website (with the webjob) direct to Azure works perfectly, and both the site and webjob get updated.

I have searched post after post and tried all manner of things, but none have worked.
Given the fact this published fine direct from VS, and also that the build is completing, it would suggest that something is wrong with the VSO Build Defintion.
My first guess would be to change it from building the solution to instead building the web project only, but this does not seem to work.
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set.

I have been battling this for a couple of days now an I'm a bit stumped!

3
Just stumbled upon your question. I'm having the exact same issue, and even posted my own question at stackoverflow.com/questions/31025868/…OJ Raqueño

3 Answers

0
votes

This also happens if you have a static website being deployed using a Visual Studio solution via VSO with an automated build - unless the Visual Studio project / solution containing the website is changed then the actual site contents will not be redeployed.

0
votes

I think your hunch that it's deploying the wrong project is correct. If you have multiple "deployable" projects in your solution (and the console app is considered deployable, as this is one way you can host/deploy a webjob), you need to tell Kudu which one to deploy.

You can control it adding a new setting under "app settings" on the "configure" tab for the webapp.
The setting you want is Project and it's a relative path from the solution root to the .csproj file of your web project.

Alternatively, you can specify the setting in a custom .deployment file.

Relevant Kudu documentation here

From the documentation:

You can specify the full path to the project file. Note that this is not a path to the solution file (.sln), but to the project file (.csproj/.vbproj). The reason for this is that Kudu only builds the minimal dependency tree for this project, and avoids building unrelated projects in the solution that are not needed by the web project.

Here is an example:

[config] project = WebProject/WebProject.csproj

0
votes

I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set

That's the root case of problem. You can't have SingleFolder as it sets the OutDir which mess up with web job packaging.

I had to introduce a wpp.targets files in each of my web app project to create the publish package to a particular path (using PackageLocation)

So, let each project have that and set the setting to AsConfigured (or Per Project) instead of SingleFolder.

See this