We are using continues deployment from Visual stdio online to an Azure Website.
The deployment fails when we added new relic.
"Exception Message: The file 'NewRelic.Profiler.3640.log' is in use."
If I Disable profiling, azure website>configure>app settings COR_ENABLE_PROFILING = 0 then the deployment works.
Is there some way to get this to work? Is it possible to add a step to the deployment process that sets COR_ENABLE_PROFILING = 0 and then afterward set COR_ENABLE_PROFILING = 1.
This is a known limitation of New Relic's Azure Web Sites integration:
https://docs.newrelic.com/docs/dotnet/azure-web-sites#known_issues
I'm not sure if setting that Web Site app setting after deployment is possible or would cause the profiler to load. With other types of deployment for the New Relic .NET agent, IIS needs to be restarted for the profiler to load into the web worker process. The COR_ENABLE_PROFILING environment variable is just a flag that more or less gives the profiler permission to load. So I think the site would require a restart even if you could set the variable later.
Making it possible to use continuous deployment with New Relic and Azure Websites would require some coordinated effort between New Relic and Microsoft. You might file a feature request with both.
I was able to make the continues deployment work. If i copied the new relics folder out of the sites folder. And the change the new app config to use that one the site and deployment work. Not 100 % sure that new relic works but it seems to be doing alright
Related
We are deploying into azure using Octopus deploy. We are using it since more than a year, and suddenly we started (about 3 weeks ago) to get errors on few deployments.
Microsoft.Web.Deployment.DeploymentDetailedClientServerException: Web Deploy cannot modify the file 'msvcr120.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE
We have the webapp running and always on and we have the app setting 'MSDEPLOY_RENAME_LOCKED_FILES' to 1 that in theory prevents this.
Does anyone knows if something was changed in azure or octopus?
There are a number of reasons files may be locked during deployment. You should be able to get an idea of what may be locking files by using the kudu process explorer, which you can access using the url {yoursite}.scm.azurewebsites.net.
In order to avoid the locking issue altogether, you could make use of slots to achieve a zero downtime deployment if that's an option for you. In this case you could stop the site or enable App Offline which should unlock any files and allow the deployment to succeed after which a slot swap will make the deployment live. App Offline is preferred over using MSDEPLOY_RENAME_LOCKED_FILES, but will take the application offline during the deployment. Octopus also has support for this as an option on the Deploy an Azure Web App step itself, so may be worth a try even without slots.
You can use custom pre/post deployment scripts as part of your Deploy an Azure Web App to make use of the Stop-AzureRmWebAppSlot, Start-AzureRmWebAppSlot and Switch-AzureRmWebAppSlot Powershell commands Azure commandlets to achieve the above.
An alternative may be to use zip deployments, however, the Deploy an Azure Web App Octopus step doesn't have first class support for this quite yet. It can still be achieved using a Run an Azure PowerShell Script along with a package references if this is what you are wanting to do.
I am setting up a release for the first time in 2018 Release Management. We have a website that we want deployed to IIS.
The build definition is setup and has created the artifacts. When I setup the release definition I select the IIS Website Deployment template which gives me two tasks.
IIS Web App Manage
IIS Web App Deploy
They seem to cover similar ground, but I cannot find documentation to tell me how they are different. Do I need both?
When I configure IIS Web App Deploy, the Website Name field is grayed out. The link icon tells me
This setting is linked to the 'Website name' (Parameters.WebsiteName)
process parameter.
So I created the process parameter in the release definition and the build definition with a different name. However the Website Name does not update. Is there a way to manually edit this field?
In short:
IIS Web App Manage
This task does provisioning, for example creating an IIS Web Site and Application Pool. Typically this is only needed the first time deploying to a target machine, but there is no harm in running it on every deploy, since it then just skips creating already existing items.
IIS Web App Deploy
This task deploys your code.
You need to create a Deployment Group before using the IIS Website Deployment template. Deployment groups in VSTS/TFS make it easier to organize the servers that you want to use to host your app. A deployment group is a collection of machines with a VSTS/TFS agent on each of them. Each machine interacts with VSTS/TFS to coordinate deployment of your app.
Useful link and blog for your reference:
https://learn.microsoft.com/en-us/vsts/build-release/archive/apps/aspnet/aspnet-from-vsts-to-windows-vm?view=vsts
https://abelsquidhead.com/index.php/2017/11/28/build-and-deploy-to-multiple-iis-servers-and-sql-server-using-vsts/
If you don't want to use this template, you could also try other extensions, such as IIS Web App Deployment Using WinRM.
Both tasks are needed. The website name is set on the Environment level then referenced in all of the tasks within.
Currently when pushing updates via our CI/CD pipeline to the Azure Web Apps the nodes are being forcefully rebooted by azure once the configuration changes are completed.
Has anyone come across a way where you can apply a configuration (web.config or other) changes to the web app in a single slot configuration with out the forced restart?
As Fabrizio Accatino said, when you touch the web.config, IIS automatically restarts the app domain.
If you do this to avoid downtime, you could add a deployment slot and publish your newest project to it. When you want to publish your project to production environment,you can swap them.For more details, refer to this article.
If downtime is your concern, it looks like MS starts up another container when you hit Save in the application settings blade, and then transfers all new requests over to the new container. The old container is given 2 min to complete all requests, and is then shut down.
https://social.msdn.microsoft.com/Forums/azure/en-US/f15b207b-c063-46e5-b87a-2b157641c8c4/does-changing-an-app-setting-and-saving-restart-the-app?forum=windowsazurewebsitespreview
I tested this on a Web App by repeatedly hitting an endpoint for 30 seconds while I changed an application setting and hit save. I saw the application start, but did not see any timeouts, only 200 OKs.
FYI my web app only used a single slot.
I am developing a multi-tier web application consisting of multiple Web APIs in an Azure App Service Environment.
Recently after upgrading to VS2017 I have noticed that the apps will randomly fail to update after I publish new code (from VS). Remote debuggers will not load correctly and the old code will continue to run after publishing.
I am selecting "Remove additional files at destination" in the publish settings.
Restarting the apps usually fixes the problem temporarily, though sometimes I have to stop and restart each app.
Are there any new settings in VS or Azure that could be affecting this behavior, or is something just not working correctly?
WEBSITE_DYNAMIC_CACHE is new feature that, for some reason, was turned on by default.
Adding the entry to Application Settings in the Azure Portal and setting the value to 0 seems to have solved the problem.
This worked for me:
In VS 2017 right-click on the project and choose Publish.
Click on Configure, as shown below:
I had WEBSITE_LOCAL_CACHE_OPTION 'Always' on for my Production Slot within Application settings. When I created a new slot I copied the settings from the Production slot - including this flag. This had to be turned off for Staging.
Try this WEBSITE_RUN_FROM_PACKAGE = 0 in my case its helps.
Adding the entry to Application Settings in the Azure Portal and setting the value to 0 seems to have solved the problem.
The issue maybe related to the dedicated instances in your ASE. You could submit a support request if you have a support plan.
As a workaround, you could set up a new Worker Pool in your ASE or a new ASE and create a new Web App Plan there. After that, you could move your Web App to the new Web App Plan. Your Web App will run on the new allocated instances. It will solve the issue which related to the dedicated instances.
I am trying to deploy my app to an Azure WebApp slot but it seems that the file (Microsoft.Data.Edm.dll) it is trying to update is locked even though I have manually stopped the WebApp. I got the following error while deploying my app.
Web deployment task failed. (Web Deploy cannot modify the file 'Microsoft.Data.Edm.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
I tried on both VSTS web deploy task and manual deploy from Visual Studio, it returns me the same error message. I tried restarting the WebApp, setting the COR_ENABLE_PROFILING = 0 then 1 too but again, same error. The last resort that I didn't try is delete the WebApp and recreate again.. but i would like to know if there are other suggestions first before I do this desperate measure.
Thank you in advanced.
Restarting works better, stop just stops the http listener, restart restarts the running proces
Please try to use Resources explorer portal to full stop your web app. In this way, we can delete some locked files via FTP without anything running. For more details about how to full stop your web app, please refer to this article
As of time of this writing, if you are using Azure DevOps (VSTS) to deploy your application, you can select "Run From Package" in the "Azure App Service Deploy" task/step - this is available in version 4 of the task, under the "Additional Deployment Options" node.
This deployment option eliminates file locking issues as it provides atomicity, in that the application is pointed to the new zip file rather than deploying a bunch of loose files under wwwroot, some of which may be locked.
It provides you with a number of other benefits that you can read about it if you search and read about the feature.
HTH