1
votes

We are building a webapp for our clients using ASP.NETZero template built on dotnet core 3.1.x

I am trying to create release pipeline in Azure DevOps and facing issues while publishing the changes of build pipeline to IIS similar way I did for traditional MVC5 or MVC6 .NET Framework based webapps.

The self-hosted devops agent is running on a different machine than production server where the webapp is published and the agent service account has access of the shared path of the \\server\inetpub-sharedhostingdir only.

Traditoinally, Copy Files task could replace app DLLs and all other files but in .NETCore there is an error like below:

enter image description here

Then I found out that this is because of changes how .NET Core 3.1.x hosting works.

I also tried to use 'OutOfProcess' in the web.config in the webapp but still getting same error and then I found this SO post and DLL hotswap info given by @MindingData.

So, my current bat to overcome this issue is using remote powershell in CD; I can stop the webapp and publish the new artifact. But there is cost for this step, I have to stop the site and replace all the DLLs which may roughly takes 30 seconds.

enter image description here

The remote Azure DevOps agent does not have access to do so right now and yet we have to add firewall exceptions to do so.

I am wondering if there is any other efficient alternative to publish .NETCore 3.1.x webapp using AzureDevOps agent running on a remote server? (as access of production server is restricted and we cannot deploy the azure agent on production machine.)

Because of these issues currently I need to move all the DLLs in 'backup' directory manually to make the hosting directory empty and then if I run the pipeline of first image, the 'Copy Files To' runs successfully and publishes the app well.

Any suggestions for improving the CD in current environment?

1

1 Answers

1
votes

You may try using 'app_offline.htm' file for graceful shutdown of your running application and after deployment you can easily remove that file using powershell command task.

This approach should work as you have access of the deployment directory of the remote server. Steps are mentioned on the SO post.