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.
Related
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 am trying to chance some appsettings and the ConnectionString of an application in a certain slot in my Azure Web App.
When I try to change the config via the Application Settings on Azure portal, nothing happens.
So I found this post:
http://brian.vallelunga.com/blog/chaining-azure-web-config-transforms-when-deploying-from-source-control
Ok, I done what the tutorial tells me to do and I got success on some deploys (I am using Kudu for auto deploy from GitHub).
But suddenly (without any change of config) the deploys are using the Release transform, instead of the dev one.
Via Kudu console, I saw in deployment folder, in some moment Kudu transformed my web.config in right one, and after transforms it again into the release version.
Someone have any idea what I can do?
Oh. My solution have more than one web project. I am using the "Project" Key on Azure application config page and that one works.
Thanks,
Ok guys, found the answer.
For some strange reason, the value of the parameter SCM_BUILD_ARGS changed from /p:Environment=Staging to -p:Configuration=Debug.
I just passed that value on Azure app settings and voil! It's working now :)
I have a project and I have it deployed on Windows Azure cloud service, Sometimes it happens that I have to just update a image file or change a css styling. Is there a way that I can copy only the required files to Azure using RDP without missing the changes when the service is refreshed, I dont want to do a full deployment just to reflect a line of change.
Any help with this will be helpful.
Thanks
Full deployment is really the way Azure Cloud Services are engineered to work. However, you can take these content files, and perhaps move them to blob storage and reference them from there. This way they can be updated outside of the root deployment.
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.
When setting up an Azure Web / Worker Role for the first time I need to 'Package' the project and upload it via the Azure portal. After doing this I can 'Publish' the application from Visual Studio.
Under which circumstances do I need to 'Package' the project again and update it via the Azure portal?
In other words - which changes require the project to be re-packaged?
Note: I need to 'Package' the project in order to upload it via the Azure portal. When I create a Compute Role in Azure, I must upload a package in order to be make the Compute Role operational.
From Azure portal:
You have nothing deployed to the production environment.
UPLOAD A NEW PRODUCTION DEPLOYMENT.
The Cloud Service package contains the role definitions, configuration settings, runtime bits, and other static content bundled with your app. Visual Studio (or PowerShell) creates an encrypted package (actually a zip file that you can look into, when building for emulator) for upload to the named slot you created via the portal.
In the future, there are certain things you can do without rebuilding the package, such as changing instance count and other configuration settings. Also: If you move your static content (such as your CSS, images, etc.) to blob storage, you can then update those directly without ever needing to recreate / redeploy the package (you may need to send some type of signal to your running app, to reload some resources, but that's going to be app-specific). If you have specific exe's or MSI's that get installed as part of your startup scripts, you can move these to blob storage as well, since they can easily be downloaded as your role startup code executes (and this cuts down on package size).
If you change anything defined exclusively in the service definition file (e.g. if you add a role or change a role size), you will have to repackage/redeploy (but you can deploy as an update, which won't take your service down [assuming you have 2 or more instances] or replace your assigned IP address).
I don't think you must package your project at the first time. You can publish your azure project for the first time. I'm not sure what prevent from your publishing. Could you explain a bit more.
I fact, the publish is very similar as package. Visual studio just packaged the project and uploaded them to azure on behalf of you.