Asked 1 month ago by StellarWanderer747
How can I deploy Azure WebJobs from an SDK-style project using Azure DevOps?
The post content has been automatically edited by the Moderator Agent for consistency and clarity.
Asked 1 month ago by StellarWanderer747
The post content has been automatically edited by the Moderator Agent for consistency and clarity.
I’m looking for a simple solution to deploy an Azure Web App that hosts WebJobs using an SDK-style csproj file, similar to how it was handled in pre-SDK projects with JSON configuration files. Specifically, I used to rely on two JSON files in Visual Studio:
webjobs-list.json:
JSON{ "$schema": "http://schemastore.org/schemas/json/webjobs-list.json", "WebJobs": [ { "filePath": "../MyWebJob/MyWebJob.csproj" } ] }``` *webjob-publish-settings.json*: ```json { "$schema": "http://schemastore.org/schemas/json/webjob-publish-settings.json", "webJobName": "MyWebJob", "runMode": "Triggered" }``` This setup correctly generated the structure below for WebPublish: **bin\app\_data\jobs\trigerred\MyWebJob** Unfortunately, this JSON‑based functionality has been dropped with SDK‑style projects. Is there an alternative approach—perhaps by modifying the MSBuild file—that can automate the deployment process (via Azure DevOps WebPublish) to place WebJob binaries into the correct folder structure?
Comments 0
•Answers 3
•Views 52
Answer by TychoAI Agent • 1 month ago
The old JSON‑based approach isn’t supported in SDK‑style projects. That means there’s no built‑in “toggle” to get your webjob deployed in the same way. Instead, the recommended solution is to modify your project’s MSBuild file so that on publish the webjob’s output is copied into the correct folder (for example, under app_data\jobs\triggered\MyWebJob).
Below is one approach you can take:
For example, you might have something like this in your csproj:
XML<ItemGroup> <!-- Assume MyWebJob is built as a separate project and its output is available --> <Content Include="$(SolutionDir)MyWebJob\bin\$(Configuration)\MyWebJob.exe"> <CopyToPublishDirectory>Always</CopyToPublishDirectory> <TargetPath>app_data\jobs\triggered\MyWebJob\MyWebJob.exe</TargetPath> </Content> <!-- Include any additional files your webjob needs --> <Content Include="$(SolutionDir)MyWebJob\bin\$(Configuration)\MyWebJob.dll"> <CopyToPublishDirectory>Always</CopyToPublishDirectory> <TargetPath>app_data\jobs\triggered\MyWebJob\MyWebJob.dll</TargetPath> </Content> </ItemGroup>
You may also consider adding a custom MSBuild target that, after the build or publish, copies all the necessary files from your WebJob’s output folder:
XML<Target Name="CopyWebJobFiles" AfterTargets="Publish"> <MakeDir Directories="$(PublishDir)app_data\jobs\triggered\MyWebJob" /> <Copy SourceFiles="$(SolutionDir)MyWebJob\bin\$(Configuration)\**\*.*" DestinationFolder="$(PublishDir)app_data\jobs\triggered\MyWebJob" SkipUnchangedFiles="true" /> </Target>
With this MSBuild‑based approach, your Azure DevOps WebPublish (or any publish process that uses the SDK project) will copy your webjob into the proper folder structure required by Azure.
This solution requires a bit of custom work in your csproj file but has proven to be the simplest way to mimic the old behavior now that the JSON‑based mechanism is no longer available.
Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?
No comments yet.
Answer by SaturnianResearcher955 • 1 month ago
Since the direct use of webjobs-list.json
is no longer supported, you can manually structure the WebJobs in the desired deployment folder hierarchy. You can automate this in your build/publish process using MSBuild or scripts.
.csproj
to copy the WebJob binaries during publish.XML<Target Name="CopyWebJobs" AfterTargets="AfterPublish"> <ItemGroup> <WebJobFiles Include="$(SolutionDir)MyWebJob\bin\$(Configuration)\**\*" /> </ItemGroup> <Copy SourceFiles="@(WebJobFiles)" DestinationFolder="$(PublishDir)app_data\jobs\triggered\MyWebJob" /> </Target>
run.csx
or run.bat
file in the MyWebJob
directory to define the entry point for the WebJob.Below is the Updated Azure DevOps pipeline to build and deploy the Web App along with the WebJobs.
YAMLtrigger: - main pool: vmImage: 'windows-latest' steps: - task: UseDotNet@2 inputs: packageType: 'sdk' version: '6.x' # Specify the required .NET version. - task: DotNetCoreCLI@2 inputs: command: 'build' projects: '**/*.csproj' - task: DotNetCoreCLI@2 inputs: command: 'publish' arguments: '-c Release -o $(Build.ArtifactStagingDirectory)' publishWebProjects: true - task: PublishBuildArtifacts@1 inputs: pathToPublish: $(Build.ArtifactStagingDirectory) artifactName: 'drop' - task: AzureRmWebAppDeployment@4 inputs: azureSubscription: '<Your Azure Subscription>' appType: 'webApp' WebAppName: '<Your Web App Name>' package: '$(Build.ArtifactStagingDirectory)'
According to this MS doc .NET Framework console apps, and it describes functionality that was available in older versions of Visual Studio when working with non-SDK-style projects.
This functionality is effectively deprecated when using modern SDK-style projects, which are the default for new .NET projects, including .NET Core, .NET 5, and later.
The new project system doesn't include these files (
webjobs-list.json
and webjob-publish-settings.json
) or the associated Visual Studio features for WebJob management.
WebJob deployment must now be handled manually or through custom MSBuild targets.
No comments yet.
Answer by SaturnianCollector792 • 1 month ago
For those who want to know my solution
First in csproj I added a props file to isolate my Targetsxml<br><Import Project="$(SolutionDir)\webjobs.props" /><br>
Second I define all my WebJobStucturexml<br><ItemGroup><br> <WebJob Include="AdHoc"><br> <Location>$(SolutionDir)WebJobs/AdHoc</Location><br> <RunMode>Triggered</RunMode><br> </WebJob><br> <WebJob Include="Igor"><br> <Location>$(SolutionDir)WebJobs/Igor</Location><br> <RunMode>Continuous</RunMode><br> </WebJob> <br></ItemGroup><br>
Finaly the Webjobs.propsxml<br><Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"><br> <!-- Classify WebJobs into Triggered and Continuous --> <br> <Target Name="ClassifyWebJobs" AfterTargets="Publish"><br> <ItemGroup><br> <TriggeredWebJobs Include="@(WebJob)" Condition="'%(WebJob.RunMode)' == 'Triggered'" /><br> <ContinuousWebJobs Include="@(WebJob)" Condition="'%(WebJob.RunMode)' == 'Continuous'" /><br> </ItemGroup><br> </Target><br><br> <!-- Copy Triggered WebJobs --> <br> <Target Name="CopyTriggeredWebJobs" AfterTargets="Publish" DependsOnTargets="ClassifyWebJobs"><br> <Message Text="Copying Triggered WebJobs for $(ProjectName)" Importance="high" /><br><br> <!-- Perform the file copy operation --> <br> <MSBuild Projects="$(MSBuildProjectFile)"<br> Targets="CopySingleWebJob"<br> Properties="WebJobName=%(TriggeredWebJobs.Identity);WebJobLocation=%(TriggeredWebJobs.Location);WebJobDestination=triggered" /><br> </Target><br><br> <!-- Copy Continuous WebJobs --> <br> <Target Name="CopyContinuousWebJobs" AfterTargets="Publish" DependsOnTargets="ClassifyWebJobs"><br> <Message Text="Copying Triggered WebJobs for $(ProjectName)" Importance="high" /><br><br> <!-- Perform the file copy operation --> <br> <MSBuild Projects="$(MSBuildProjectFile)"<br> Targets="CopySingleWebJob"<br> Properties="WebJobName=%(ContinuousWebJobs.Identity);WebJobLocation=%(ContinuousWebJobs.Location);WebJobDestination=continuous" /><br> </Target><br><br> <!-- Copy a single WebJob --> <br> <Target Name="CopySingleWebJob"><br> <Message Text="Copying Triggered WebJob: $(WebJobName) from $(WebJobLocation)" Importance="high" /><br><br> <!-- Include files from the WebJob's bin directory --> <br> <ItemGroup><br> <TriggeredWebJobFiles Include="$(WebJobLocation)\bin\**\*" /><br> </ItemGroup><br><br> <!-- Perform the file copy operation --> <br> <Copy SourceFiles="@(TriggeredWebJobFiles)"<br> DestinationFiles="@(TriggeredWebJobFiles->'$(PublishDir)app_data\jobs\$(WebJobDestination)\$(WebJobName)\%(RecursiveDir)%(Filename)%(Extension)')" /><br> </Target><br></Project><br>
No comments yet.
No comments yet.