I'm having some issues deploying an Azure WebJob using Visual Studio Team Services (VSTS).
The WebJob seems to be deployed successfully but it breaks the Azure website that is hosted in the same App Service! I don't have this problem if I deploy using VS2013.
This is my build task that generates the WebJob deployment package:
And this is my deployment task:
There are no errors when I deploy the Azure WebJob. If I go to the Azure Portal I see the WebJob is there, and it runs successfully. WebJob files are copied into the wwwroot\App_Data\jobs\triggered\RemoveExpiredDids
folder as expected, but the problem is that some other files will be copied into the wwwroot\App_Data\bin
folder, which will break the existing website that was already deployed into that App Service!!!
So I decided to find out why this was happening. After downloading and extracting the deployment package I saw there are 2 folders (app_data
and bin
) and the scheduler file (settings.job
):
This explains why some assemblies are coppied into the wwwroot\App_Data\bin
of the App Service. The strange thing is that this doesn't happen when deploying from VS2013!!! I took a look into the MSBuild log and found the following line:
Object dirPath ([app service name]\bin) skipped due to skip directive 'SkipBinFolderOnDeploy'.
Concluding, bin
folder is included when deploying the Azure WebJob from VSTS but is excluded when deploying it from VS2013.
So my question is: how to prevent the bin
folder from being deployed when using VSTS? Is there any MSBuild parameter/flag to do this?
Deploy to Azure App ServiceIn Solution Explorer, right-click the project and select Publish. In the Publish dialog box, select Azure for Target, and then select Next. Select Azure WebJobs for Specific target, and then select Next. Above App Service instances select the plus (+) button to Create a new Azure WebJob.
For which web app can you configure a WebJob? Publishing a . NET Core WebJob to App Service from Visual Studio uses the same tooling as publishing an ASP.NET Core app.
Suggested Answer:Triggered runs on a single instance that Azure selects for load balancing. Continuous supports remote debugging. Note: The following table describes the differences between continuous and triggered WebJobs.
Refer to these ways to deploy webjob to azure:
/p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\WebJob" /p:DeployDefaultTarget=WebPublish
)$(System.DefaultWorkingDirectory)/WebJobVnext/drop/WebJob
); Contents:bin
)$(System.DefaultWorkingDirectory)/[artifact name] /drop/WebJob
)I was finally able to fix it, thanks @starain-MSFT for pointing me in the right direction. I had to make some minor changes, though. This is the task that creates the deployment package:
MSBuild arguments:
/p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish /p:Configuration=$(BuildConfiguration) /p:OutputPath=.\bin\ /p:publishUrl="$(build.artifactstagingdirectory)\temp\WebJob"
The difference here comparing to @starain-MSFT answer is that I had to add the /p:OutputPath=
parameter, otherwise I'd get the following error:
The OutputPath property is not set for project
After generating the package, I delete the bin
folder and zip it (this reduces the build time).
This is my deployment task:
Please note that $(DeploymentPackagePath)
is the path to the zip file that contains the deployment package, as mentioned before. It doesn't matter if you deploy the package as a zip file or if you unzip it and deploy the folder, it works both ways.
I've had issue with this particular problem as well.
The latest method I found is using Web Deploy Operation Settings , -skip:Directory= (in this case it would be -skip:Directory='\\bin') when you create your azure deploy task in the release definition (Additional arguments). I've seen that this indeed excludes the bin folder from the update actions (result).
Let me know if this helps you in any way.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With