I have a very weird issue deploying an azure cloud Service. I have 1 Web Role with 5 instances and 1 Cache Role with 2 instances.
When I deploy my MVC 5 WebRole from the Azure Portal, deploying starts on the first web instance, then it tells me that the "The role could not be started" due to an error and stops processing the other instances. I did an RDP to the failed instance and truly the MVC application throws an error that it can't find a certain view file "The layout page "..." could not be found at the following path", even though the view in the path specified does exist. So I did an iisreset and the application worked. after I manually fixed the issue the deployment continues to the next instance and the failed instance becomes "Ready".
Anyone has an idea why things don't deploy smoothly anymore or why an iisreset is necessary?
This is relatively recent, around a month.
My environment is:
.NET Framework 4.5.1
MVC 5
Azure SDK 2.4 for VS 2013
Thanks for the help.
FINALLY!! I found the issue and fixed it.
I had a Local Storage Resources to store temporary files and local file caches for certain components, and was configured to reset on role restart. One of the components (Lucene.NET for azure) was locking the files in that local storage, causing the problem on deployment that needed to to IIS reset to release the lock.
I configured the component to cache the files on Windows temp storage instead of the Local Resource and things worked out.
Related
Sporadically get the error
An error was encountered when processing operation 'Delete Directory'
on
'D:\xxx'. The error code was
0x80070091. The directory is not empty.
I'm using web deploy WMSVC and the user has full access to the root of the site (set up through IIS > Configure Web Deploy Publishing
EDIT
Or less frequently:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets (4377): Web deployment task failed. (Unable to perform the operation ("Delete File") for the specified directory ("D:\xxx\bin\Microsoft.Practices.ServiceLocation.dll"). 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.)
I follow the instructions for the user (a domain user) but it makes no difference. The publish settings that get saved have publishMethod="MSDeploy" instead of WMSVC.
Note, it deploys correctly 95% of the time.
I know this sounds stupid, but do you have those folders open (or children thereof) on any computer? Especially if you had a dead remote desktop session or someone accessing it over the network share it will get a denial to be able to delete the directory.
Burned me a number of times, you're issue may be different though. I realize this is a late response, but found it while searching for my own issue and though I cuold help.
I'm trying to upload an ASP.NET MVC 3.0 application to Windows Azure. The upload ok but the configuration (automatic operation just after upload) failed.
Any idea ? (I'm new in Windows Azure)
In the new portal you have to explicitly check a check box to allow deployment with less that two instances:
There is absolutely no obligation to use 2 instances. There is only SLA that comes into place only if you have 2 or more instances. I have production roles with 1 instance and I am very happy to use the Windows Azure services.
UPDATE
Just ntoed the "Linked Resources" comment on the first answer. So here are my 2 cents on it too: Linked resources feature is just a way for us developers to have a quick overview of our application and to quickly navigate between the components. There is nothing to do with our application's configuration files. You can set your Windows Azure SQL Database connection string as you normaly do with regular apps - in web.config (web.release.config)
The answer is right there in the second screen shot.
When you upload your package from the portal the dialog has a checkbox at the bottom that says "Deploy even if one or more roles contain a single instance" That needs to be checked if you are choosing to deploy to a single instance.
This is required since the SLA cannot be maintained with a single instance. There are times when the single instance needs to have OS updates applied or sometimes there are hardware failures. Having more than one instance is the only way to continue serving requests when one of these events occur.
You probably will not want to deploy a production solution with a single instance. But, for the dev cycle you can certainly get by with 1.
I'm trying the WorkSpace.PendAdd method under Microsoft.Teamfoundation.Client namespace to add the local folder to TFS, it works normally when i debug with VS2010, but it doesn't work if it's published to IIS. I also tried giving the full control to the folder, but still no effect. Any idea will be appreciated.
Check to see what identity the web app is running under. Does that ID have appropriate rights in TFS? If you're hosting on a web server that is not also your TFS application tier, you could also be running into the two-hop limitation of passing identity.
When you're running in debug mode, it is probably picking up your credentials, and since your machine counts as hop zero, there's no problem passing them on to the TFS application tier.
I found a solution after checking the versionControl NonFatalError event.
Before the calling to workspace.PendAdd, just call:
Workstation.Current.EnsureUpdateWorkspaceInfoCache(
_versionControl,
_versionControl.AuthenticatedUser);
(for some reason it's the only way the specific file folder path will be mapped when running in IIS)
We use MVC controllers that access System.File.IO in our application and they work fine in localhost (IIS 6.0-based Cassini). Deploying to IIS7, we have problems getting the controllers to work because they throw UnauthorizedAccessExceptions.
We have done the following to try to resolve the issue:
- Set NETWORK SERVICE and IUSR accounts to have permission on the files and folders in question
- Ensured the App Pool is running under NETWORK SERVICE and loading the user profile
- Application is running under full trust
- We tried adding impersonation to web.config and giving NETWORK SERVICE write permissions (which was not a great idea because that's not what we want to do)
Now, we alternate between getting UnauthorizedAccessException and an IIS7 404 page that suggests the routes are being ignored completely (for example we serve "/favicon.ico" via a controller when the physical file actually lives at /content/images/favicon.ico). We used ProcessMonitor to try to track down the issue but weren't successful.
UPDATE:
This issue is intermittent. We had a brief few minutes where everything worked without making any configuration changes. We're running on EC2, so this could be related to a distributed file system. We're also using a separate drive to store all web site data, we're not using inetpub/wwwroot.
UPDATE 2:
The site works without incident under IIS 7.5, with no configuration changes needed but this is likely due to running with the new AppPoolIdentity. Otherwise it's an identical deployment. Unfortunately we can't run R2 on this EC2 instance.
One of the ways to identifying the cause is using Procmon tool from Sysinternals
Procmon will show the reason for unable to open the file , it will also show who is holding the file.
The issue turned out to be the controller factory we were using not handling file requests properly.
What is the correct proceedure when deploying an ASP.net MVC application? I am using the built in forms based authentication and deploying using the publish function in VS2008 but when deploying it doesn't seem to deploy the ASPNETDB to the server and I end up with errors like
An error occurred during the execution of the SQL file 'InstallCommon.sql'. The SQL error number is 1802 and the SqlException message is: CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file 'C:\INETPUB\WWWROOT\HOURS3\APP_DATA\ASPNETDB_TMP.MDF'.
I looked this up and attempted to change the sql server to run under the local system account as per
http://forums.asp.net/t/984436.aspx
but that doesn't seem to have helped.
When you try to publish this way, I believe you're going to overwrite your database with the one you are currently developing with. This means if you had any changes in your web environment, such as new users, you would lose them when you overwrote them in a publish. Additionally the reason you're probably getting permission denied, is because the file is already in use by the website, and Windows doesn't like it if you try deleting a file that is in use.
Typically I set my databases to publish in a different methodology than the ASP.net files. I often generate an upgrade script using a tool such as RedGate SQL Compare. This allows me to upgrade the one live on the server instead of copying a new file.