I have a question about Remote Desktop deployment on Azure Cloud Application.
First of all I published my app via visual studio.Everything is working.
Yesterday I connected with remote desktop to my azure app and changed some attributes in my web.config files.
First thing : My cloud app is getting so slowly so I think IIS restart etc. but I don't know why my site is coming slowly ?
Second thing : Today when I enter to my app , I can't see my changes and when I check it via remote desktop all my changed things are roll back. Why ?
Do I have to all my deployment via Visual Studio ?
How is staying my deployment in Azure machines ? This machine is sometimes changing or never change when I delete it ?
Thanks,
This is not the expected way to change the settings. Azure is free to relocate your instance to another VM or restart it in-place and erase all your local changes.
So if you want to do some permanent changes you have to do them locally, build the service package and deploy the new package to Azure. This way Azure will have an updated package and your changes will persist.
If you want to change something frequently you have to use the <ConfigurationSettings> node of the service configuration. Your code will have to query the setting and react accordingly. If you want some activity triggered when the service configuration is changed your code has to handle the RoleEnvironment.Changing event.
You cannot make changes in the VM directly, because these changes are not persisted (as you have already noticed). The VM can be recycled and restored at any moment. So you have to make changes by applying them locally and redeploy the site.
Related
What happens under the hood when webapp restarted from Azure portal?
Let say if there is a change in connection string or other appsettings in an MVC.NET application, I can access the live webconfig file, save and restart the service. After the service restarted I would find that change has been updated. Therefore I am asking does at restart time application build or how the change take effect?
Sure, Restarts on an App Service can be triggered either manually or by configuration changes. See below configuration changes which trigger some sort of restart.
It is important to be aware that any config changes in sections such as the ones listed below can trigger a restart.
For more details on Restart operations see this detailed blog.
Currently when pushing updates via our CI/CD pipeline to the Azure Web Apps the nodes are being forcefully rebooted by azure once the configuration changes are completed.
Has anyone come across a way where you can apply a configuration (web.config or other) changes to the web app in a single slot configuration with out the forced restart?
As Fabrizio Accatino said, when you touch the web.config, IIS automatically restarts the app domain.
If you do this to avoid downtime, you could add a deployment slot and publish your newest project to it. When you want to publish your project to production environment,you can swap them.For more details, refer to this article.
If downtime is your concern, it looks like MS starts up another container when you hit Save in the application settings blade, and then transfers all new requests over to the new container. The old container is given 2 min to complete all requests, and is then shut down.
https://social.msdn.microsoft.com/Forums/azure/en-US/f15b207b-c063-46e5-b87a-2b157641c8c4/does-changing-an-app-setting-and-saving-restart-the-app?forum=windowsazurewebsitespreview
I tested this on a Web App by repeatedly hitting an endpoint for 30 seconds while I changed an application setting and hit save. I saw the application start, but did not see any timeouts, only 200 OKs.
FYI my web app only used a single slot.
I am new to Microsoft Azure and working on a MVP for a client. I am able to successfully deploy my ASP.NET MVC web app to a Web Role. The issue I'm facing is that Azure Web Role seems to recycle itself and revert to the deployment package. This leads to rollback of manual changes done (if any) after the deployment (like I allow user to upload profile images and am storing them in file system).
Is this the expected behavior? If not, when can I look from debugging purposes?
Looking for any help possible.
Is this the expected behavior? If not, when can I look from debugging
purposes?
It is expected behavior. Azure Fabric Controller is responsible for managing the Virtual Machines in which your WebRole runs. It takes care of patching the VM and do other maintenance related work on that VM. It is also responsible for taking out faulty VMs and replace them with brand new VMs. When the replacement happens, Fabric Controller will create the new VM based on the last deployment package.
You should not be making any changes manually after VM hosting WebRole has been created, these are Stateless VMs. Any changes you make to VM will be rolled back if Fabric Controller decides to recycle the VM. Please note that these changes do persist if the VM is simply rebooted.
I am developing a multi-tier web application consisting of multiple Web APIs in an Azure App Service Environment.
Recently after upgrading to VS2017 I have noticed that the apps will randomly fail to update after I publish new code (from VS). Remote debuggers will not load correctly and the old code will continue to run after publishing.
I am selecting "Remove additional files at destination" in the publish settings.
Restarting the apps usually fixes the problem temporarily, though sometimes I have to stop and restart each app.
Are there any new settings in VS or Azure that could be affecting this behavior, or is something just not working correctly?
WEBSITE_DYNAMIC_CACHE is new feature that, for some reason, was turned on by default.
Adding the entry to Application Settings in the Azure Portal and setting the value to 0 seems to have solved the problem.
This worked for me:
In VS 2017 right-click on the project and choose Publish.
Click on Configure, as shown below:
I had WEBSITE_LOCAL_CACHE_OPTION 'Always' on for my Production Slot within Application settings. When I created a new slot I copied the settings from the Production slot - including this flag. This had to be turned off for Staging.
Try this WEBSITE_RUN_FROM_PACKAGE = 0 in my case its helps.
Adding the entry to Application Settings in the Azure Portal and setting the value to 0 seems to have solved the problem.
The issue maybe related to the dedicated instances in your ASE. You could submit a support request if you have a support plan.
As a workaround, you could set up a new Worker Pool in your ASE or a new ASE and create a new Web App Plan there. After that, you could move your Web App to the new Web App Plan. Your Web App will run on the new allocated instances. It will solve the issue which related to the dedicated instances.
I have configured my application to use the Service configuration Local in the development settings.
I have two cscfg files (as per default) Cloud and Local. I have added connection strings for Storage that tell it to use a live account in Cloud.cscfg and dev storage for Local.cscfg.
However when I run my project and use the line
var setting = CloudConfigurationManager.GetSetting("StorageConnectionString");
It is using my Cloud configuration and returning my live storage. It is definitely my Cloud cscfg and not something else setting the value as if I change it in Cloud the setting returned changes.
Is this by design? Is there any way to see the logic CloudConfigurationManager is using to select the configuration?
The weird thing was I am sure this was working earlier.
Deleted all compiled versions of projects. Restarted Compute and Development storage services and the issue went away.
Tried deleted all compiled version and restart Emulator many times to no avail.
Found out my setting wasn't right.
So, right click on your Cloud Service project (not the Roles, but the project) and "Properties".
Then go to "Development" tab (from left), and you will see "Service Configuration" setting under "Run/Debug category".
This needs to be Local for Cloud Service project to use Local setting.