I would like to update a database connection string in the web.config file for an application that is currently hosted in Azure as a web app.
Seems that you can RDP into an Azure cloud service role but not a web app. If you can't RDP into an Azure web app, is there another way to update the connection string without redeploying?
You can use the portal, there is a tool called "App Service Editor" in preview that lets you edit any of the files you've deployed. I do wonder why you want to do this though, it's not considered good practice to modify source files on the fly like this! Config and app settings are exposed via the portal as well and can be modified without dropping to the app service editor tool. (under Settings/Application Settings in portal). Updating these does not update the web.config but will override web.config settings.
As Russell Young said, on Azure portal, we could use App Service Editor that provides an in-browser editing experience for our App code. And we could specify connection string in App settings section to override existing settings.
Besides, we could also to access and update Web.config file (under D:\home\site\wwwroot folder) via Kudu Debug console.
The best practise would be to use a FTP client such as File Zilla, where you can grab it, edit, save and push it back to the host without the hassle of logging into a portal and editing it directly on the server or portal.
Please note that editing a file without backing it up first, and editing a file directly on the server can cause many many problems.
Related
Is it possible to import azure web sites application setting from a file.I could not find a direct link from the azure portal.
Update
I want to copy some application settings from one azure web site to another azure web site in our test environment. I don't want to automate this, as we have our deployment infrastructure in place. I just want some simple solution where I can export the application settings from one web-site and import to another for testing.
want to copy some application settings from one azure web site to another azure web site in our test environment
If you check the Azure web app in Azure Resource Explorer, you can find Application settings info is under config/web section, and it provides an API to update the configuration of an app.
You can try to get Application settings of one website via Azure Resource Explorer, and then you can call Rest API to update another website Application settings. If you save Application settings of one Azure website in a file, you can read file content and construct request based on it and send request to update another website.
You could upload a fresh copy of your web.config, but that'll recycle your app when you do so. That's about the only support out-of-the-box for manually changing settings via a file.
You could also do the following:
Create a Settings class that's a singleton and reads settings from a file.
Within the Settings class, set up a FileSystemWatcher on the file containing your settings.
On the FileSystemWatcher.OnChanged event, re-read your settings file.
As to Azure Portal you can go to Configuration/Application settings and open Advanced edit where you can paste JSON version of the settings. You need to do it separately for Connection strings. (If you already have settings in Azure then you can copy them from there - what would be an export in that case).
Connection strings
js site which i deployed on Azure.
Site was working fine but i made some changes but changes not appearing on the site. How to restart or clear site cache on Azure portal.
One more thing that post methods are not working in this site as well how to enable post method in Azure ?
I already tried to restart my web app from Azure portal but not success.
Posted my issue https://social.msdn.microsoft.com/Forums/en-US/090831ae-41ff-4091-a7ec-466041904c10/nodejs-app-restart-cache-issue?forum=windowsazurewebsitespreview here as well
First of all, you could restart your app by following steps below on Azure portal.
In the Azure Portal, open the blade for the web app.
Click Overview.
Click Restart button to restart your app.
Secondly, you could check the code whether it has been changed on Azure with Kudu which could be accessed via https://<yourwebsitename>.scm.azurewebsites.net/DebugConsole.
Then cd to site/wwwroot folder, you will now be able to see your application files.
By default, Azure doesn't restrict any HTTP request method. Maybe you have made a mistake in configuring web.config file, which can be found on this article. You can check this official guide if needed.
My web.config contains multiple entries in "appSettings" (e.g.: twilio account key). One of these is for the asp.net chart control. It's the configuration part that states where the images the control generates are to be stored.
All of these settings work on my development machine. That is, i can connect to twilio and the chart control stores image in memory (as it should, according to the settings).
When i publish the site to my azure website (using vs), all of the settings work, apart from the chart control one. The chart control behaves as if the setting isn't even there. (it defaults to c:\TempImageFiles for storage).
I looked into the published version of the web.config and the setting is there. Only, it's beeing ignored.
My next attempt was to add that setting using the portal. (It's possible to add appSettings for a web app using the portal). I copied the exact same setting from web.config into the portal settings. This worked, so there is nothing wrong with what's in the settings.
So my question is: Why are some (at least this one) settings from web.config ignored when the app runs inside an azure web app?
You might have an app setting defined in the Web App's configuration with an identical name that overrides the web.config setting. This is typically done to have production settings stored in Azure instead of Web.config.
You can confirm if this is the case by opening your Web App's blade in the new portal, and checking the Application Settings tab there.
azure websites / azure web app service are typical web applications running on top of azure PaaS infrastructure. So whatever storage allocated to the service is accessible from the app. But it cannot be the typical C: or D: where in a regular server the app may have complete access. Mostly the C: space is allocated for IIS hosting. D:\local is something you can utilize as the app will have complete read and write access.
Please refer azure web app service sandbox details here.
If you are accessing the path via code try using Server.MapPath property to get access to the path. options like Path.GetTempPath() will not work.
One point to note is, any local storage in azure PaaS services is to be treated like a temporary storage. Whenever the site, service or role recycles the storage will be gone a fresh storage will be assigned.
I Used Azure Website Migration Assistance to migrate my web service that was running on my Local VM's IIS. My Migration process was successful and also I was able to use this web service. But I can't find where to find the migrated source code in azure portal. All I can see is some 20Mb of data in on the dashboard graph of azure portal. If I need to changed some of my code where to do this?
What is on the Azure Web App should now match what was on your IIS server. Now, to update the web app, you can use the deployment techniques here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/
The simplest method to deploy to check what content is on your web app would be to use the SCM site. This is available at: https://your-site-name.scm.azurewebsites.net. Go to Debug Console > CMD and then the site > wwwroot folder to see your web app content. You can also upload to the site via drag and drop.
Alternatively, you can download the publishing settings for your web app via the portal and then re-use the migration tool, select the site, and then upload the publishing settings. However I would suggest using the deployment techniques above first. (Disclaimer: I wrote the migration tool.)
There are multiple ways to push changes to your Azure Website/Web App. They are listed here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/
One simple way is to use an FTP client like FileZilla. In the classic portal, you will find the FTP address (hostname) and the credentials in the dashboard tab. In the new portal, select your Web App and the FTP address will be displayed in the Essentials section at the top of the page. Click on Settings and Deployment credentials to set your FTP user password.
Another simple alternative is to use Dropbox. Take a look at this video for how to set instructions: https://channel9.msdn.com/Series/Windows-Azure-Web-Sites-Tutorials/Dropbox-Deployment-to-Windows-Azure-Web-Sites
I enabled the Web Deploy feature for my Web Role and deployed it.
But how can I get hold of the .publishsettings file so I can create a Publishing Profile for it?
This 2 year old article states that it should have been created automatically, but I haven't got that in my profile manager.
Any ideas?
If you are using Visual Studio 2012 or greater, the server explorer to the left will have several Azure items.
Specifically the Windows Azure Compute is what we are looking for, right click on that and say 'add deployment environment'. You will then be prompted with a dialog that allows you to sign in and download publish settings file:
You can get publishsettings file from the following link: https://windows.azure.com/download/publishprofile.aspx
Well, the problem was really behind the keyboard.
So the publishing profile is actually provisioned correctly and automatically to the Web project as the documentation states.
The problem and confusion was that I have a secondary web application in my Solution that I also publish to the same Web Role (referenced as an additional Site in the ServiceDefinition.csdef file).
That Web Project does not get the Publishing Profile, and when I try to create a profile manually, it doesn't work since that (secondary) IIs instance is not configured for Web Deployment.
Oh well, back to the tedious Cloud Service deployment it is...