azure-cloud-services

Description I got a web role hosted in a cloud service that is a web site. There are predictible load spikes that we handle with a custom monitoring (a worker role) that will periodically scale in or scale out depending on the predicted load profile. That part is working. Issue After a new instance of the web site is mounted by the monitoring, we just had a case of a user whose request reach that new instance before the new instance was fully load. It resulted in an unaccessible web site blank page on the web browser. Given our typical target client it is very bad. This happen when a tester

After successfully upgrading my cloud service to the new "Azure SDK for .NET 2.5.1 " I got the following error when trying packaging/publishing. Could not load file or assembly 'Microsoft.WindowsAzure.Packaging, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Windows Azure Tools\2.5\Microsoft.WindowsAzure.targets The related line in the "Microsoft.WindowsAzure.targets" config file is 2930 which obviously is related to CSPack. <CSPack

My Azure Cloud Service's Web Role works fine when deployed to Azure but can't get it running with the Emulator. When starting the role from within Visual Studio (2015) the window just displays "Starting the roles for the application in the Microsoft Azure compute emulator...". When starting with the debugger OnStart() doesn't seem to be hit at all, so something before that gets stuck. The role doesn't seem to be started because the app's custom logs are not created either. Looking at the Compute Emulator's UI reveals that the role is continuously (and very slowly) cycling between Unknown and

Is there anywhere in the service runtime that would tell me if I'm currently running on 'Staging' or 'Production'? Manually modifying the config to and from production seems a bit cumbersome. Igorek You should really not change your configurations when you're based upon if you're in Prod or Staging. Staging area is not designed to be a "QA" environment but only a holding-area before production is deployed. When you upload a new deployment, current deployment slot where you upload your package to is destroyed and is down for 10-15minutes while upload and start of VM's is happening. If you