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.
Related
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.
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?
It looks like I have just happened to find an easy reproducible solution for infamous:
'Load operation failed for query 'GetUser'.
The remote server returned an errror: NotFound'
issue for WCF RIA Services (Silverlight 5) web setup: when using VS2012 Web Publishing Wizard with 'Precompile during publishing' option checked-on then the issue does raise its ugly head. When the 'Precompile during publishing' option is checked off then deployed WCF RIA Services works well with Silverlight client. Please check on your system.
I have used fuslogvw etc.etc. - nothing helped. Never used Web Publishing Wizard before - xcopy was my friend, this time I wanted to automate the whole deploying process - and lost a couple of hours of precious time.
I still don't know what is the cause of the issue but I can proceed with my work. Next time when there will be more free time I will probably use this technique to localize the causes of the subject issue.
Edit for clarification: I have effectively solved the subject issue on my localhost but I have it still appearing in one program but not in another when releasing on an external web hosting environment, and I'm yet to find what causes this issue - do you know any good sources where this issue's various solutions are classified and accompanied with solution walk-throughs?
I'm new with windows Azure and i've just signup for a 3months free trial, i've installed dotnetnuke 7.0.1 the problem that i have is that everytime when i try to install a module on to my dotnetnuke website i get the sql error message, please help as i don't know what is the problem.
my windows Azure is disabled because i've created more than 1 databases but now i've deleted all the other databases now i'm left with one, how do i reactivate my trial so i can complete my tests.
The problem with the modules that you are trying to install is probably that are not SQL Azure compatible. Ensure that those modules are compatible with SQL Azure asking to the module developer/vendor. If the problem is within the open source/non-core modules, some time ago I modified all of them to be SQL Azure compatible (check this link: http://dotnetnuke6.intelequia.com/Module-Test). Before install any of them, be sure that there is no new version at CodePlex with the SQL Azure compatibility fixed.
I think the problem is that the SQL Azure "billing" counter is calculated "per day". So you should wait at least one day before creating a new database or just disable the trial limits by converting the subscription to a paid subscription
---I WORK FOR POWERDNN---
Hi Anonymous,
While Azure does have some advantages, when it comes to running an app like DotNetNuke on Azure, it is really not a good business or technology decision (at least today). Right now Azure does not have parity with standard SQL Server technologies which is what DotNetNuke has been coded against for the past ten years.
I've already talked to more than a couple associates who have tried to run their DNN website on Azure and it has caused serious problems for them, Usually what happens is a SQL script won't completely run and will leave their database in an indeterminate state. The problems usually aren't apparent to them until a few weeks after trying out azure and then they have to decide to either roll back (and loose weeks of data) or spend hours trying to figure out what script didn't fully run and trying to piece things back together in an azure-compatible way.
If you have never had to rewrite a vendor's SQL scripts, I'd highly encourage the experience. It is a lot of "fun" :-)
Always glad to help,
Tony V.
I just built a simple hello world windows azure service containing just one web role, I used visual studio 2008 and Windows azure tools for VS 1.2 I am pretty new to this and I have been trying to deploy an application all afternoon now. I'm in australia and deploying in the region Asia anywhere.
I have pretty much followed the info provided on MSDN and it says uploaded 95% then after about ten minutes the deployment disappears. I have tried using the old windows azure developer portal and 30minutes later I can not access the service and it's status is either busy or stopped.
I have the introductory offer for an extra small compute instance on the subscription I am deploying to. Can anyone with experience with windows azure elaborate on the subject of deploying apps and the status on my application, I am very keen to get into the platform and this issue has just about spoiled my weekend.
Most likely it is related to the UseDevelopmentStorage=true for a connection string. I have accidentally done this a couple of times myself and things just magically don't work and there is no explanation. Missing DLL's are usually a little harder to track down as the application may or may not start depending on where the failure happens. Trace logging and/or infrastructure logging is the best way to find out if the DLL is missing if you can get your application to run that far.
As pointed out already, the best place to start is making the simplest "Hello World!" you possibly can and start extending from there. Yes it will take you a while to make progress but the experiences you gain from this will be invaluable moving forward.
Two things to check before deployment
1. Change Roles' Connection Strings to point to Azure Storage instead of UseDevelopmentStorage
2. All References not belong to asp.net framework should be set to "Copy Local=True"
I would guess that the deployment is going successfully but that the role instances are not able to start. The most common causes of this are eithe referrences to development storage while deployed (UseDevelopmentStorage=true) or a referrence to an assembly with copylocal!=true.