I'm trying to build and publish web job via MSBuild and it is failing at
'_CheckAzureNet46Support' with error VerifyAzureNet46Support -
[VerifyAzureNet46Support] C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4755,
7): Your hosting provider does not yet support ASP.NET 4.6, which your
application is configured to use.
I've published other projects as web job to this web app with no issue but intermittently this issue occurs, is it something with my configuration of web app.
MSBuild arguments used for build is
/P:Configuration=Release /p:DeployOnBuild=true
/P:PublishProfileRootFolder="%heckoutDir\BuildConfigurations\publishProfile"
/p:PublishProfile="WebsitePublishProfile"
/P:Password=WebsitepublishProfilePassword
/P:outputdirectory=Bin/Release
If the app service plan is having high RAM or CPU utilization this issue occurs.
To mitigate this you can Scale Up app service plan to avoid this issue.
It is highly unlikely this has nothing to do with the App Service plans. That analysis simply does not make sense.
Rather, a build-time check fails verifying whether the deployment target in Azure supports ASP.NET 4.6. This is done by performing an HTTP GET request to a hard-coded URL at http://go.microsoft.com/fwlink/?LinkID=613106&clcid=0x409. If said request returns 200 OK, the check fails.
Therefore, the more likely explanation is that the support page in question was back up for a few hours by mistake. We had the same problem, but it seems to work now.
Related
I've got an simple asp.net core 2.2 API. It is configured to deploy to azure as soon as we check-in into the master branch.
Azure devops release pipeline is configured to deploy it to an staging slot first. Then it does an smoke web test (by going to one end-point) and if that is successful then it swap the slot with production.
When the slot is swaped it does the same smoke web test (by going to the same end-point on production) to check if it still works. A lot of times i then get an HTTP Error 500.30 - ANCM In-Process Start Failure.
Deploying the same build again fixes this problem most of the times. But i cannot find any logs or details why this error occurds and how to fix this.
Any idea how to debug an HTTP Error 500.30 - ANCM In-Process Start Failure on a Azure Web App?
Turns out Azure has an internally known (I guess they are not eager to share the news about this) problem with 'Application Insights'.
So turn that feature off (if it's on), and see if it solves the issue. That step solved the problem for me.
I had the same error with an Azure ASP.Net Core 2.2 that was running fine for several weeks and suddenly started generating this error from Oct 15 to Oct 17.
Microsoft tech support folks tried to help for a couple of days but they couldn't figure out why the stdout logs were blank. Then, after 2 days, it turned out that it was a known problem on Microsoft's side and they promised to fix. Indeed, after about 8 hours the application started working again (no change or redeployment of the application on my side!).
I asked for an explanation but they told me it was too sensitive.
Today, after 2 weeks of working well, the same application is back to showing the same exact error: "HTTP Error 500.30 - ANCM In-Process Start Failure"
So, most likely, the problem is not in your code or deployment procedure. Instead, the problem is Azure (perhaps how they provision the .net core 2.2 runtime). But for some odd reason Microsoft is not willing to share the details of the problem with their user community (or permanently solve it). Very disappointing!
I am attempting to use an Azure App Service Deploy task in Azure DevOps to deploy a file to an app service in Azure. I have been able to use this release pipeline to deploy to the same app service in the past. Two things have changed: I had to re-make the build machine (which exists in Azure), and the source code moved from Azure DevOps to GitLab.
The error I am running into is:
Error: (3/21/2019 4:34:45 PM) An error occurred when the request was processed on the remote computer.
Error: The server experienced an issue processing the request. Contact the server administrator for more information.
Well, I'm the server admin, and I don't have a clue.
Is there some log file I can look at for more information? Can someone please offer some suggestions?
I'm happy to provide additional information, I'm just not sure what would help at this point.
Thank you Tom Sun for directing me to the system.debug variable. That was very helpful. When I turned on the debugging the release worked, witch really doesn't make sense. I started the build machine after it had automatically shut down the day before, but then I had also rebooted the machine eight or nine times before that.
I removed the debug variable and the release still works.
I have no satisfying answer to how this issue was resolved and I don't know how to get the system in a state to reproduce the error.
An additional finding I have is that the artifact produced by the original build was a corrupt war file. Perhaps that had something to do with it?
When we try to deploy ASP.NET Core website to Azure we are getting this error:
Error Code: ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER
More Information: Unable to perform the operation ("Delete File") for the specified directory ("D:\home\site\wwwroot\TestAspNetCore.exe"). This can occur if the server administrator has not authorized this operation for the user credentials you are using. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER.
The problem is IIS locks the .exe file. We can take the website offline but with continuous delivery it would be nice to have no downtime.
Note that ASP.NET 4.5 does not have this problem.
See also https://github.com/aspnet/IISIntegration/issues/226 and https://github.com/aspnet/Hosting/issues/141
I've had a similar headache and it seems not to be possible, the most reliable solution I have come up with is to have 1 build for a private local version that can be taken offline then restarted right after deployment. I then have a second build that takes the private version into production every night in the early hours.
This way I can make updates regularly through the day and ensure my site is only offline for no more than 20s during the early hours when it is least likely to be used.
When I publish to Azure my tiny, tiny test project, configured in the latest vNext RC2, I get the following error upon first load after an extremely long wait:
The specified CGI application encountered an error and the server terminated the process.
Subsequently if the app is anything more than the very simple "Hello World" project below, i.e. it uses some MVC etc. then the app is extremely unresponsive, failing to load some images, taking minutes to load each page. Although sometimes it's suddenly fast for a little while, then slow again.
In RC2 there were some changes to the hosting setup, but all these have been implemented in my tiny test project.
I have also seen this question and ensured I am publishing the exact correct version of the CLR, in fact for information the same result happens if I use full or core CLR.
Here is the example project (publishing profiles removed):
https://www.dropbox.com/s/hpkrj6c74eaytjz/TinyProject.zip?dl=1
If I create a new RC1 project, the problem doesn't surface, but as soon as I update it to RC2 the problem persists.
In the end I solved this by creating an App Service Plan that was anything other than the free or shared option, in my case B1 (screenshot from Visual Studio Azure SDK):
Has your Azure Web app instance had a RC1 instance uploaded to it prior to your RC2? Your project looks ok to me, I can't see anything wrong at first glimpse with your project.json, Startup.cs or hosting.json files. I had an instance of RC1 on a Web App, and when trying to upload RC2, nothing would work, just a long long wait until eventually it would time out with a 503 error. I deleted the Web App, and just published the RC2 (using same DNX build as yourself) and everything works fine (so far!).
Also, if you turn on Diagnostic logging in your Web App, does that provide any more info?
I had a site running asp.net 5 beta4, and decided to upgrade to beta5. The site runs locally fine. I pushed the changes to master and it was picked up from bitbucket and deployed successfully.
When I try to hit the site in azure, I get a 500 Internal Server Error. I've tried a number of things, but can't seem to track down the root cause of the failure. I'm looking for suggestions as I'm hitting a wall. From what I've tried below it seems like some fundamental initialization is failing.
Here's what I've tried:
Enabling customerrors="off". I added a web.config to the wwwroot folder with system.web/customErrors mode="Off". I've verified that the web.config is populated correctly in the deployed wwwroot and had the appsettings containing the dnxversion etc merged correctly.
Customizing the custom error page, adding runtimeinfo. I have the following set in my Startup.cs:
app.UseErrorHandler("/Home/Error");. I also have set the error page to display the exception. This doesn't seem to be hit.
Attached to the remote process to debug. Visual studio eventually freezes, so haven't gotten anywhere with this.
Enabled application insights. This registers events when I debug locally, but doesn't capture anything from the azure instance.
Enabled application logs and request failure tracing. The detailed errors show a 500.0, without much detailed information.
Imgur
Imgur
I've also verified through the console that the runtime is set correctly to beta5.
Update:
I set the ASPNET_ENV to Development and it loaded with appsettings loaded via the azure portal. Setting ASPNET_ENV to something else isn't working. I also removed any custom code from startup.cs pertaining to the non-development environments, with no help. I'm still looking for a means of capturing the original error.
Assuming you are targeting DNX451 and not dnxcore50, there is a good chance Azure it still trying to run it against the beta4 runtime instead of beta5. If that's the case, you won't get a decent error message.
Try adding an environment variable in Azure "SCM_DNX_VERSION" and set it to 1.0.0-beta5. It looks like kudu was recently upgraded to support beta5 https://github.com/projectkudu/kudu/commit/55175a017779bf493ff8e6ce87b96dd1451f7d7b, so you might want to try to redeploy from bitbucket in the case that the Kudu team has already deployed this change.
For a little more detail, you can check out my previous answer (although it is very dated and references the old "K" names) here:
Deploying ASP.NET vNext beta 2 on Azure with Kudu
Every time you update to a new beta, you will have to update your SCM_DNX_VERSION environment variable.