Unnecessary Startup Command in Azure Pipelines for .NET Core Project - azure

I've created a Linux App Service running .NET Core 2.2 on Azure. When I go to the deployment center and choose Azure-Repos/ Azure-Pipelines as the source control and then select my MVC Core repo, i'm required to enter a Startup Command, but deleting the command afterwards in the App Service's Configuration - General-Settings doesn't actually prevent the website from running?
Edit:
Actually, if I don't delete the Start-up command after deployment my app wouldn't run!

Well yes, AFAIK, it is true that the Startup command should be optional in the Deployment Center configuration blade, like it is in the Azure App Service Deploy task, unless it's needed for some other specific reason.
I shall check with our internal teams about this and get back with more details as I have them. Thanks for the question!
Update:
#jcmontx We have created a workitem to track and fix this. Please note that there are some other high priority changes planned for Linux Web App continuous delivery which will have effect on how startup command is handled. This means we will have first wait for these to complete before processing the requested change. Thanks for your patience!

I had the same problem. The only solution I found to this was to:
Add a random comment as Startup Command (your build may fail the first time) when setting up the Pipeline in the Deployment Center.
Then go to Azure Pipelines -> Releases -> Select YourPipeline -> Edit -> Tasks -> Select "Deploy Azure App Service"
Scroll down the options and you'll find "Startup command"
Remove your previous input (step 1)
Save

Related

How can I configure a website to start automatically using TFS release management?

[I'm posting this to record what I actually found out after hours of painful trial-and-error.]
I have a website that I need to be "always running" (because in this case it has a Hangfire job that's responsible for kicking off a scheduled task every 5 minutes), and by default, websites are only started up when the first request is received.
So, how can I ensure that the website is started automatically? And, how can I configure this via the TFS release management tool?
[This answer isn't specific to Hangfire, but see the Hangfire documentation's discussion of this issue for details of how it affects Hangfire, but note that the recommended work-around is somewhat involved, and much more complex than the solution below. See also a separate and quite comprehensive discussion on the Hangfire support forum that gives several alternative solutions.]
In IIS, each website is associated with an Application Pool (App Pool). You can configure your App Pool to start automatically via IIS Manager by changing the "Start Mode" to AlwaysRunning in "Advanced Settings" for the App Pool:
However, starting the App Pool doesn't start the website (or websites) associated with it. The website does not get loaded until the first request is received.
In IIS8 (or IIS7.5 with an extension), a new setting was added that allows us to work around this. You can ensure that the website gets sent a request as soon as the App Pool starts by setting "Preload Enabled" to True in "Advanced Settings" for the website:
The combination of these settings ensure that the website will automatically start up when IIS starts, and immediately after the App Pool is recycled, etc.
But, how can you get those settings applied automatically as part of a TFS release pipeline, rather than having to remember to set them manually?
In your release definition, you presumably have an "IIS Web App Management" task, which sets up the App Pool and the website. In the configuration panel for this step, there should be an "Advanced" box with an "Additional AppCmd.exe Commands" entry field. You can use AppCmd to apply the settings described above.
AppCmd has the most confusing command-line syntax I've yet seen outside of code-golf competitions, but here's the incantation that worked for me:
set config /section:applicationPools -[name='myAppPoolName'].startMode:AlwaysRunning
set app "mySiteName/" /preloadEnabled:true
Note that if you have configuration variables defined for your App Pool name and website name, then you can use those rather than hard-coding the name, such as:
set config /section:applicationPools -[name='$(appPoolName)'].startMode:AlwaysRunning
I hope this helps somebody... Thanks for listening :-)

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.

How to reuse Azure startup tasks?

I have an app which needs to be installed for all the services I have. Unfortunately, installation requires many files and task related input parameters (e.g. RoleInstanceValue xpath=...).
The way I came up with to share this task among cloud service projects is through Azure Plugins (here is a link to a library of them http://richorama.github.io/AzurePluginLibrary/).
The problems I see with this approach are:
It is not recommended/supported by Microsoft, which means they can
change support for that any time.
It requires copying files to C:\Program Files\Microsoft
SDKs\Azure\.NET SDK\v2.6\bin\plugins\NxlogAzureForwarder, adding an
extra step to build setup.
Microsoft recommends startup tasks. But I could not figure out a way to share them among cloud services.
So, my question is: how to easily reuse startup tasks?
As recommended your best chance would be a startup task that starts your app, which would be encapsulated into a Windows service. That service is going to be your reusable task/app/service (whatever you call it).
What you need extra is the following:
Project reference to your Windows service
An install script for the service
Installer tool
(Optional) app config for your service
To start your app/service you need to update cloud service definition by adding start up task and making runtime context elevated, and start your service in OnStart entry point.
That being said, you can place parameters of your app in the cloud config and read them in your WebRole and pass them to your service.
For more detail check out this post.

How to take web app offline while publishing?

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:

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).

Resources