Azure-webjobs-sdk: Webjobs not updating after publish

[isaackhazi]

When I make changes to the source code of the app that runs in the webjob and publish using the "Publish as Azure Webjob" from the context menu, the job is published but the changes are not reflected. For instance when I publish my app v 2.2.1, the actual app version running v 2.2.0.

I have tried the following:

1. Publish to existing web job
2. Publish to new web job within the same web app

3. Zip the release folder and manually add as a web job via Azure portal.

4. Publish to new web job in a new web app. (Works in this case)

Is there any setting I am missing? I noticed this behavior only recently. A few ago it was working as expected.

Repro steps

Provide the steps required to reproduce the problem

1. Step A: Made some changes to the app, built and published via "Publish as Azure webjob.."

2. Step B: Older version of app running after publishing.

Expected behavior

The web job must update and run the latest exe.

Actual behavior

The job is running an older exe

Known workarounds

Created a new webapp and deployed the job.

Related information

Provide any related information

• Package version
• Links to source

[mathewc]

Are you using the webjobs SDK?

[paulbatum]

Closing due to lack of activity. Please reopen with additional info if required.

[MarkJ74]

I get the exact same problem.

[unnieayilliath]

I have the exact same issue while using Azure webjobs SDK and deployment using "Publish Azure Webjobs" option in VS 2017.

[MarkJ74]

All I can suggest is you try deleting the web job, stopping and restarting the app service, then re-publishing the web job. If you've renamed any assemblies then delete your bin folder so the old ones aren't left in there.

[stuartdotnet]

Getting the same issue. Tried deleting the webjob and it's still deploying the old code somehow. Please fix.

[clebens]

I'm not sure why this issue is closed. I still seem to be running into the same issue. Deleting and re-deploying did not solve the problem (and seems an unacceptable solution, regardless).

[clebens]

Thanks for reopening! I figured I could provide a bit more context.

I think I was able to resolve my issue, but it may still merit some additional investigation.

The process I went through was to Publish as Webjob -> Rename Webjob Project (and, as a result, the name of the executable produced during the build) -> Publish as Webjob. Doing this did not appear to clear out the original executable from my obj/ and bin/ directories (even after clean). As a result, it kept publishing the old executable along with the new binaries. For whatever reason, it always decided to run my old executable when both were present (perhaps because the earlier Webjob's filename was first alphabetically?)

Deleting my local obj/ and bin/ folders along with the published version (via FTP) and then republishing resolved the issue.

[natedahl32]

I have been having the exact same issue. Unfortunately I just deleted the entire WebJob folder from Azure dashboard and confirmed the folder was gone via FTP. I republished the WebJob from Visual Studio and it is still running my old code somehow. This has been a problem for awhile now and I have no idea how to fix it. Re-publishing a webjob via Visual Studio seems fundamentally broken right now, or rather even updating the web job in general. It seems to me when a publish occurs it should be running the most up to date code.

[atpalmer]

I'm seeing similar issues. This looks to have been broken for a long time. Please fix these issues. WebJobs aren't viable for production use if deployment is unreliable.

[paulbatum]

Is anyone getting this behavior when using webjobs 3.x ? The publishing workflow for that is a little different (there is no "publish as webjob" option anymore, VS just figures out the right thing to do). I'd like to understand if this issue is specific to the old workflow (for webjobs 2.x) , the new workflow, or can happen regardless of version.

[atpalmer]

@paulbatum Versioning is completely opaque as far as I can tell. All I know is that deployments don't deploy. The word "version" doesn't even appear in the documentation (https://docs.microsoft.com/en-us/azure/app-service/websites-dotnet-deploy-webjobs). If there are differences, they need to be communicated clearly.

For my own part, I've had issues regardless of Visual Studio--which isn't how I want to be deploying anyway, at the end of the day. (So, this may be the wrong thread for me...?) Kudu documentation has been a little more helpful, and I seem to be able to just write scripts to get around problems.

[paulbatum]

@parker-andy I'm talking about which version of the WebJobs SDK (the NuGet package) you are referencing in your application.

[paulbatum]

Actually disregard that. The publishing gestures that are presented depend on the project type (i.e. is it a .NET Framework console application or a .NET Core console application). So the version of the webjobs SDK used should not matter here.

[atpalmer]

@paulbatum I appreciate your replies. In my case, what I was actually trying to do is tangential to the original post (though I've tried a handful of things and in all cases was having difficulty getting webjob deployments to take).

For the benefit of anyone else working through related problems, what I wanted to get working is along the lines of what I've shared here (https://github.com/parker-andy/azure-webjob-python). I'm deploying via source control, rather than from Visual Studio, and this approach is seemingly reliable. Others can speak to whether they're still having issues with the .NET + Visual Studio path.

[paulbatum]

So we need more information to be able to narrow down this issue. A few questions about what happens when you run into this problem:

1. Does performing a restart gesture on the webapp that is hosting your webjob resolve the issue?
2. If you look at the files using the kudu console (see here for info) within D:\home\site\wwwroot\app_data\Jobs do the new files appear or the old ones?

[simongullberg]

@paulbatum I'm experiencing the same problem when deploying a webjob to Azure.

1. Yes, when I restart the webapp the webjob is picking up the changes.
2. The new files appear when checking the kudu console.

Let me know if you need more information about my environment. I use version 2.2.0 of Microsoft.Azure.WebJobs package.

[ms000]

I just want to let y'all know that I found the answer to this problem, in my case at least. After updating my webjob and publishing my Azure web app, it looked like the old version of the webjob would run, but only sometimes. This was driving me crazy.

The answer in my case is that I have a second deployment (staging) slot for this web app. The webjob on the staging slot was looking at the same queue as the production server and randomly grabbing the jobs. To stop this you have to go to the Azure portal and stop the webjob on the staging server (i.e., don't just stop the web app).

This may not be what is causing similar problems for others, but it is something to check.

[fabiocav]

@dariagrigoriu we need to engage the VS team to assist with this.

[davidrevoledo]

Having the same problem, I've followed this: https://docs.microsoft.com/en-gb/azure/app-service/webjobs-dotnet-deploy-vs but not luck so far.

I'm using KUDU in this project.

[afrischk]

I had the same issue with my webjob recently. I have deployed the webjob within a web app via Azure DevOps. The web app is scaled out to multiple instances, the webjob has a singleton setting. After deploying, the webjob was running the old code. The files were updated as far as I can remember. Restarting the web app did not help.To fix the issue I had to delete the webjob and re-deploy the web app. I observed this behavior the first time.

[jgragert]

So we need more information to be able to narrow down this issue. A few questions about what happens when you run into this problem:

1. Does performing a restart gesture on the webapp that is hosting your webjob resolve the issue?
2. If you look at the files using the kudu console (see here for info) within D:\home\site\wwwroot\app_data\Jobs do the new files appear or the old ones?

Regarding question 1: For me, restarting the web app did not resolve the webjob issue. Will post again when I have time to answer question 2.

[kbdavis07]

Having same issue in Aug 03, 2019

1.Does performing a restart gesture on the webapp that is hosting your webjob resolve the issue?

No

If you look at the files using the kudu console (see here for info) within D:\home\site\wwwroot\app_data\Jobs do the new files appear or the old ones?

Files are gone, but still seems to be running, even when the web job itself has been deleted.

Seems after may be 20 mins or so it finally clears out, we should not have to delete everything, stop the web app and then wait 20 mins or so, then re publish to Azure in order to get it to work.

[carol-braileanu]

I having the same issue, but I deploy the webjob via FTP. I can confirm the files are updated, but the old version of the webjob seems to be running in the background somehow. Even if I stop or delete the job it is still running in the background somehow. The only way I have been able to fix this in the past was to delete the entire app service and re-create it.

I was hoping there was an easier fix...

[BC89]

This still appears to be the case when i right click deploy too and is incredibly frustrating. Even when debugging locally and I've stopped the App Service in Portal, sometimes it picks up jobs thereby bypassing the local debug instance.

[hakonfjukstad]

This still appears to be the case when i right click deploy too and is incredibly frustrating. Even when debugging locally and I've stopped the App Service in Portal, sometimes it picks up jobs thereby bypassing the local debug instance.

try changing the version of your app before you deploy, just up the minor.