My Web.config looks like this:
<connectionStrings configSource="secretConnectionStrings.config">
</connectionStrings>
secretConnectionStrings.config stores the DB connection string with the password and is not in source control.
I can see the following in the "Deploy Azure App Service" task:
How can I update my VSTS release pipeline so that the <connectionStrings> section is replaced with a connection string (including password) which I supply?
My repo is public which is why I don't want the password in there, and only trusted people have access to the VSTS account used to deploy.
Not entirely the answer you're looking for, but still an answer to your problem: have a look at what the Azure App Service ConnectionStrings settings under Application Settings do:
For .NET apps, these connection strings are injected into your .NET configuration connectionStrings settings at runtime, overriding existing entries where the key equals the linked database name.
Using this in a smart way enables you to have the setting just be present on the App Service, without the release pipeline even having to know them.
You could also, of course, have the release pipeline update the settings on the App Service. Because you can do XML Transformations with the Azure App Service Deploy task, you can remove the external file reference. Or remove it alltogether.
Also, have a look at my comment on your post
Related
The config value is stored in the Web.config. When I build the web project, the Web.config gets copied to the build folder as {ProjectName}.dll.config. Running the web app locally works fine, the config value gets read without problem using ConfigurationManager.AppSettings["{key}"];.
When I build the cloud service however, the {ProjectName}.dll.config does not get copied to the cspkg file that I upload and run on Azure. I would expect it to be in approot/bin. However there is a Web.config in approot.
Running on Azure the app fails when trying to read from the app settings using ConfigurationManager.AppSettings["{key}"];.
I am aware of CloudConfigurationManager but I would like to avoid having to maintain the configuration in both, Web.config and the cloud cscfg.
The service configuration file specifies the number of role instances to deploy for each role in the service, the values of any configuration settings, and the thumbprints for any certificates associated with a role.
In Solution Explorer, select Properties>Development>Service Configuration and set the value as Cloud.
Then, set the web role's Service Configuration as Cloud.
In setting tab, Add Setting about connection string and what you want to store.
The following code illustrates an example of how to access a connection string. Replace the placeholder with the appropriate value.
// Setup the connection to Azure Storage
var storageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("<ConnectionStringName>"));
For more details about how to configure Azure Cloud service roles with Visual Studio, you could refer to this article.
In azure web apps, there's a tab called "Deployment option" that allows a push from a github branch to azure web apps.
Currently I'm developing a website in Umbraco and is trying to get this option to work properly.
I have been able to successfully connect connect web app and sync the build from that branch from github.
However, after the deploy, the connection is wrong so I have deduced that it's potentially a connection string problem.
Therefore, is there a way to perform web.config transforms while using this deployment option?
Generally, you should not attempt to transform your web.config with connection strings during deployment, as doing this leaves you with physical files containing secrets (dangerous practice).
Instead, you need to set your connection strings using the Azure Portal (or ARM API). Just keep a 'dummy' entry in your web.config to mark that you have this key, and then override the value with the real connection string in the portal.
See doc for related info.
I've defined steps to build and run tests for my ASP.NET Core MVC app and it all works fine.
Now I want to add a step that actually runs the migrations (if any) and that step to works (it doesn' fail :). Allthough I can't understand why it works since it probably uses the setting from appsettings.json, which don't have any connection strings, they're defined in user secrets.
So my question is: Is there any easy way to get the connection string defined in the App Service for the site I want to build?
A neat option would be to define a variable with the same name, e.g ConnectionStrings:db that check if there is any app setting with the specified key in the Azure portal and then use it.
Thanks
The better way is using Azure Key Vault. You can refer to this blog for detail steps of protecting secrets using VSTS and azure key value.
Another way is that you can use secure variable in build/release, and replace the specified value in appsettings.json by using JSON vairble substitution of Azure App Service Deploy task. (match the key, so appsettings.json file should contain connectionstring key).
I have a webapp deployed to an Azure Web App. In the webapp I am using MembershipReboot, with Entity Framework. The Sql Server database is also in Azure.
It is deployed via BitBucket integration and continuous deployment, in a staging slot.
As part of the build process, a web.config transfrom, changes the connection string value to "dummy".
I set this the connection string, named MembershipReboot, in the Azure portal.
When I browse to the application, I get this error:
Format of the initialization string does not conform to specification starting at index 0.
If I change the connection string in the web.config, to be the Sql Azure connection string the app loads fine. If I set it back to "dummy" then I get the above error.
This indicates to me that the connection string set in the Azure portal isn't being picked up by the application.
I created this Azure enviromnent using the ARM template deploy, mixed with some Azure powershell commands. I've tried creating the environment by hand too, with the same issue.
Any ideas on what to look at next?
edit: Just to say, the correct connection string is viewable within Kudu.
Managed to fix this.
It was due to StructureMap being invoked, and creating a database context (via global.asax), before the environment was providing the correct connection string.
In our case, the app was mixing Owin startup and global.asax Application_Start, we had to move the global.asax startup into the Owin startup, and not allow the database context to be created during that startup. I suspect we could have just done the latter.
I am trying to setup essentially a Development, Staging and Production cloud service. So far I have setup 2 cloud services:
MyApp - which is what I am hoping to have be the staging and production since they have the same connection string and should be identical and the ability to quickly swap VIP is a nice feature.
MyAppDev - I want this to point to our development database.
I also want to do the continuous build integration from tfspreview to azure. This is working great except for making the connection string unique.
So far I have setup the cloud services and have it doing continuous builds. I have also set my connection string in web.config and web.production.config. In addition I have setup publishing profiles (.azurePubxml) files and set them to be the Alternative Publish Profile in the build definition process section. These publish profiles specify which config to use (or at least that is what I thought). It seems to pick up the settings for the publish profile because I have RDP enabled and such with different passwords.
So how can I make the build controller use the "Production" & "Debug" build configurations to pickup the web.config transformations?
Hope that makes sense.
EDIT:
I only have Solution to build as seen below:
When defining your build definition, in the "Process" section under item 1. "Items to Build" you are given the opportunity of defining which configuration to Build. In here, type the name of the configuration that matches your .config definition to build that version.
EDIT: This is a little late, but this is how I got the alternate configuration to build along with the correct connection strings. I set the MSBuild Argument for configuration manually and my build correctly changed the connection strings on deployment to Azure.
Just set your downloaded Azure publishing profile in section 6. "Web Deploy Publishing Profile". It's not necessary to use different web.config files Connection String will be rewritten on publish build runtime.