I did just now deploy an Alloy site to Azure (with version: ) and I still neeeded the appsetting to make it read from the portal instead of the config file.
With a release note for this bug (that I reported) it says that it could not be fixed without a breaking change, but that was in version 8 so there has been two breaking after that so I thought it had been fixed. (I also heard from another developer that it was the same in version 11).
Is this still the case, that you need to use this appsettings, and will you fix so you won't use it?
I do not want to save passwords in the transformation file, instead use the config tab in Azure
what I don't understand fully - is why there are required breaking changes under the hood. where exactly?
@Henrik - I have a 11.3 site running in Azure and I'm able to successfully use connection strings defined in the Portal.
In my Release.config - I tranform the connectionStrings element to be empty:
I then set the appSetting episerver:ReadOnlyConfigurationAPI to true in the Azure Portal and it uses my connection strings defined in the Portal.
No connection strings or secrets are in my Web.config or other config files. Am I missing something? I don't see the problem with adding a single appSetting to make this work - there are many other config settings that behave similarly to affect environment level configuration.
Matt the thing I am thinking of is why this appsetting is needed: episerver:ReadOnlyConfigurationAPI
I know that in old versions of Epi, they read up all settings in the cache (and also saved a copy of web.config in the database I think) but I had hope that would have changed with the introduction of Azure support
Is this still so, that we need this app setting?
I am having the exact same problem. Monitoring.episerver:ReadOnlyConfigurationAPI did fix it, but I had to restart app 2x for it to take.
Thanks Henrik for this thread, I had already forgotten this one and faced it again today ;-)
Always glad to help Antti!! :)