How to take web app offline while publishing? - azure

Very often, when I hit Publish in VS13, I get the site to compile but when uploading I get the error saying that a file is busy.
Updating file (MyAzureSite\PrecompiledApp.config).
C:...\v12.0\Web\Microsoft.Web.Publishing.targets(4255,5):
Error ERROR_FILE_IN_USE: Web deployment task failed.
(The file 'PrecompiledApp.config' is in use.
Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
When I follow the link provided, it's suggested that I should go for enabling the appOffline rule. "Sure!", I think to myself. But how?! I've googled it, only to get a bunch of hits on the file that's supposed to replace the site while publishing. However, I get no info on how to get rid of my little problem.
I went the easy way and downloaded a publishing profile from my Azure web site and now I'm using it (you know, ALT+B+H).
Right now I resolve the problem by going to the portal for Azure and manually take the site off-line. Then I can publish and after that I take the site on-line. Highly impractical and painfully tedious.
What is causing this and how do I kill it?

You actually configure it in the publishing profile (.pubxml). Just add the element to the PropertyGroup like this:
<PropertyGroup>
<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
...
</PropertyGroup>
More in this MSDN document

The Azure App Service Deployment Task has a checkbox for this (from version 2.0 onwards), under Additional Deployment Options: Take App Offline. Check that and you should be good to go.
Take Application Offline: Select the option to take the AzureRM Web App offline by placing an app_offline.htm file in the root directory of the Web App before the sync operation begins. The file will be removed after the sync operation completes successfully.
Screenshot:

Related

Azure App Service not reflecting file changes from ftp

I am new to Azure and I have created a very simple App Service in Azure with everything default. Changed the App Service Plan to B1. I can browse the app service home page and see the default page. I then connect using FTP and try to change the default page, but it did not reflect changes.
I even downloaded publish profile and published a .net core 3.1 web api with defaults, I can see the files are deployed using FTP but the api is not present. I even deleted the default page but the home page still appears. It seems the ftp is not pointing to default location where files are being picked up by asp.net core.
You can refer my answer in this post. Then use kudu to check whether the time of the last update file via FTP is consistent with the release time. If the file is not updated, of course this update has no effect. Then we can check the FTP connection str.
But first, I suggest you to modify index.html or default interface function and update by kudu. Then check if the update file is effective. If success, I can sure you code is ok.
Second, check your FTP Connection str.
Step 1. Find Deployment Center->FTP, click FTP then you can see Dashboard, into Dashboard find FTPS Endpoint,Username and Password.
Step 2. Use FileZilla, connect it. You can see files in it.
Then you can try again. Under normal circumstances, there is no problem to update via FTP.If the problem is still not resolved, I suggest that you can deploy to local IIS for debugging.
I was facing same problem like, publish contain not displaying when visit website. then i change following settings and it worked.
I had the same issue updating files in FTP and the dlls weren't being updated as they were being used by the site. I had to stop the App Service first and then update the files. The changes then reflected when restarting it.

How to debug why azure web job does not start?

In Visual Studio, I am deploying a web site to Azure via the Publish menu option, and the project has an existing web job added to it (via the Add menu). It was added as a continuous job, and has the correct entries in the 'webjob-publish-settings.json' and 'webjobs-list.json' files.
When I publish the web site, the job is compiled and put into place in the 'jobs' folder and published with the web site. However, it is not started. No entry is added automatically to the WebJobs settings page in Azure, which remains empty. There are no errors in the output window.
The Azure webjobs documentation states that it will attempt to run a selection of files from within the webjob directory, and one of these is any file that ends with ".exe". The webjob project is a console project, and compiles into an exe which is published in the directory.
In the past, I have published this job by zipping the contents of the 'bin\Release' directory, and adding it manually.
How can I debug why it does not start when deployed automatically?
First thing you should do is look at exactly what got deployed, to make sure it looks like what you expect. To do this:
Go to Kudu Console
Go to D:\home\site\wwwroot\App_Data\jobs\continuous
You should see a folder named after your WebJob in there. Go in that folder
Check that it has all the right files
If it doesn't, then you likely have some kind of deployment issue, and it is not an issue with the WebJobs runtime.
I think when you published the Web site, it just copied over the Webjob files but Azure does not know that there's a Webjob that has been published. Could you please try publishing the WebJob separately by selecting "Publish as Webjob" option. If it has problems publishing that way then there's some problem in your Webjob, like app settings etc, and if it is successfully published then I guess you have to publish it separately every time or find a hack in Publish settings of the Website to publish both the projects.
Hope it helps. Thanks
I had a web job that was working fine, I stopped it, changed a value in the config file and started it again. It didn't start, no errors, no log issues, nothing at all.
How I fixed it? I clicked "Restart" button in the app service that contains all the web jobs.
Note: stop and start did not work, only "Restart" did the trick. It really makes no sense but that's what happened. I hope it helps others with the same issue.

Why does my Umbraco installation from within the Azure Marketplace always fail?

I am trying to install Umbraco by using the Azure Marketplace. There they offer a template for it. I am always receiving the error below. I tried to install it a couple of times now but I always get the same error.
Does anybody know what this error message means? Is anybody able to install Umbraco by using the template in the Azure Marketplace?
]
You're asking 2 questions above.
Please see my answers and proposed troubleshooting guide/workaround below:
The error message means that the MSDeploy process failed due to some error which renders it unable to deploy the web deploy package for your Umbraco web app.
Yes I am able to provision a Umbraco web app from the Azure Market successfully (Location: Central US) and couldn't reproduce your issue
Troubleshooting Guide:
Append .scm in front of the azurewebsites.net of your Umbraco Web App as shown below and go to the Url.
Click on the Diagnostic Dump. You will be prompted to download a .zip file
Extract the zip file. You should see 2 folders at root level
Go into
LogFiles\SiteExtensions\MSDeploy
You should see the detail log files for MSDeploy
Detailed MSDeploy log messages are in the appManagerLog.xml file.
If it is related to client side issue which can be resolved by yourself, you can try to resolve it and try again.
If it is related to server side issue, you should create a support ticket for Microsoft to look into with the detailed MSDeploy log which pinpoints the root cause which will help them a lot.
Hope this is useful.
A Microsoft employee confirmed this is a bug in the application currently. I have to wait for a fix.
I have encountered numerous problems with the Azure installer of Umbraco, try setting it up in VS2015 then publishing it to Azure. I have found that this works well.

Error Deploying New Relic Instrumented Site to Azure from Github & VS.NET

I am getting the following error:
Error: The process cannot access the file 'C:\DWASFiles\Sites\mywebsitename\VirtualDirectory0\site\wwwroot\newrelic\NewRelic.Agent.Core.dll' because it is being used by another process.
In the Running deployment command... log file when attempting to deploy an Azure website from Github.
Would appreciate any pointers as to what could be causing this.
UPDATE: Turns out this is also failing when publishing directly from VS.NET with the following:
1>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4196,5): Warning : An error was encountered when processing operation 'Create File' on 'NewRelic.Agent.Core.dll'.
1>Retrying operation 'Update' on object filePath (mywebsitename\newrelic\NewRelic.Agent.Core.dll). Attempt 1 of 2.
1>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4196,5): Error : Web deployment task failed. ((06/07/2013 23:54:58) An error occurred when the request was processed on the remote computer.)
This was working before and I am not sure why it would have stopped.
NewRelic recommend stopping the website to unload the file and allow the deployment to go through.
As an alternative, you can set COR_ENABLE_PROFILING to 0 in your app settings on the configure tab to temporarily disable the profiling, which should then allow you to continue with the deployment while leaving the website operational throughout.
Instead of stopping the website you can temporarily turn off New Relic monitoring via the Configure tab on manage.windowsazure.com:
Configure > developer analytics > select "OFF" > Save
Deploy
Configure > developer analytics > select "ADD-ON" > Choose Add-on from dropdown > Save
Worked for me, both with a regular deployment from VS and an automatic build from VSO.
This is a known issue with the New Relic .NET agent for Azure Websites when performing an upgrade of the agent. The workaround is to stop the website to release the dll, finish the deployment and then restart the instance.
https://newrelic.com/docs/dotnet/azure-web-sites#h2-1
Not really a solution but more of a work-around, in the publish dialog view a preview of the changes and uncheck the NewRelic.Agent.Core.dll file so that it doesn't get published.
None of these answers work for me anymore. I have an Azure Basic tier website plan, which hosts multiple actual websites.
If I don't stop the website, I get the error mentioned above (newrelic.agent.core.dll is in use)...
If I do stop the website (or all of them), I get an error saying that the publishing endpoint isn't available.
If I go to the configure tab and disable the AddOn, we still get the error mentioned above (newrelic.agent.core.dll is in use)...
Pretty much we just republish over and over again with different permutations of the above until if works. It took me hours the other day, took me 10 minutes today.
If you are using webdeploy, then you can configure your webdeploy settings so that it ignores the file. However, if you do that, you will manually have to deploy any updates to the new relic agent.
I had a similar issue with the new relic log file being locked, and solved it by:
Moving the new relic log file to a subdirectory of the web root (e.g. \newreliclogs)
Adding 2 lines to my powershell script that configured the skip directive to ignore that whole directory. e.g. (where destBaseOptions is of type Microsoft.Web.Deployment.DeploymentBaseOptions
$skipDirective = new-object Microsoft.Web.Deployment.DeploymentSkipDirective("NewRelicLog","objectName=dirPath,absolutePath=.*\newreliclogs$")
$destBaseOptions.SkipDirectives.Add($skipDirective)
Depending on how you are using webdeploy, the configuration is achieved slightly differently, I used the following links to help me piece it together:
https://technet.microsoft.com/en-us/library/dd569089(WS.10).aspx
https://msdn.microsoft.com/en-us/library/microsoft.web.deployment.deploymentskipdirective(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/dd543313(v=vs.90).aspx
http://blogs.iis.net/jamescoo/archive/2009/11/03/msdeploy-api-scenarios.aspx
http://forums.iis.net/p/1192163/2031814.aspx#2031813
And I used the powershell script from the Octopus Deploy Library at https://library.octopusdeploy.com/#!/step-template/actiontemplate-web-deploy-publish-website-(msdeploy).

SharePoint Solution Deployment: How do I prevent SP from resetting IIS when upgrading or retracting a globally deployed solutions?

So I figured out that by adding the ResetWebServer="FALSE" attribute to the solution manifest prevents SharePoint from recycling any app pools.
However, when upgrading a solution that originally did not specify ResetWebServer="FALSE" or when retracting a solution that does specify ResetWebServer="FALSE", the application pools are still being recycled. Is there a way to prevent any auto-recycling of app pools?
This does not seem possible given the document on MSDN (see below), note that I included Deploying a Solution over Upgrading a solution as underneath it is effectively doing a file replacement. I believe the restart/recycling is necessary as a result of how IIS functions. An option to explore if you wanted to manage when this occurs is to ensure that all deployments are done via timer jobs and execute when their impact will be minimized.
Deploying a solution
Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).
Retracting a solution
On each front-end Web server, the following occurs:
Microsoft Internet Information Services (IIS) is disabled.
Files are removed from the system.
IIS is re-enabled and Windows SharePoint Services is reloaded when
a user browses to a page.
You might also take a look at the "-local" switch. Didn't try it yet but it seemed that it allowed deployment server per server when you are in a load balanced situation.
Might be a good lead.

Resources