As we started with a new Optimizely 12 project based on .net5 we first had no idea how to deal with the app settings (connection strings, find service endpoint, blob folder path etc..) which are mostly different for every developer in the team. In previous projects based on Optimizely version < 12 we were able to use the power of the xml document transformation and having a *.config for every developer, but with .NET Core there is no way to use the same approach again.
What we wanted to achieve is an appsettings.json for each developer which contains all the developer related and unique information
Example:
To get this work we have just to change a little bit the code within Program.cs and adding the developer specific json file with the right name containing the machine name…
Changes to Program.cs
We need to add the JSON files specificly to a new Configuration of IConfiguration. With appSettings.{System.Environment.MachineName}.json the developer\’s machine name will be dynamically fetched and the developer\’s specific appsettings.json will be added by the ConfigurationBuilder:
Code Snippet:
public static IConfiguration Configuration { get; } =
new ConfigurationBuilder()
.AddJsonFile(\"appsettings.json\", false, true)
.AddJsonFile($\"appsettings.{Environment}.json\", true, true)
.AddJsonFile($\"appsettings.{System.Environment.MachineName}.json\", true, true)
.AddEnvironmentVariables()
.Build()</pre>Add the new Configuration within the CreateHostBuilder method to get it work:
Please make the environment check to do this only on local environment, otherwise it will not work on the DXP
Creating a developer appsetting.json
Add a new appsetting.json with the pattern appsetting.**Your Machine Name**.json to the already existing appsettings.jsons:
Example content (like for me):
That should do the trick!
I also recommend to read the Ultimate Guide to Optimizely CMS 12 from Jon D Jones when starting with a new project
https://www.jondjones.com/learn-optimizely/cms/the-ultimate-guide-to-optimizely-cms-12/
I will post another blogpost how to keep all the personal and environment settings and keys safe and out of the code repository soon!
Happy Optimizing! Keep safe!
You should not add secrets to a file that potensially could end up in a repo. I reccomend to use User Secrets instead.
https://medium.com/@s.faizaan7/manage-the-secrets-using-asp-net-core-secret-manager-with-visual-studio-f254bb0bab91
One key thing that’s very important to call out here as we’ve done the exact same thing. If you deploy to DXP this will break how the configuration works, so we’ve wrapped this code in an environment check so it only applies to local development. With the default when not using the standard _configuration = configuration; so it still works on the DXP. It took a while to figure this out when I deployed as I wasn’t ware my team had changed the config setup
That’s not what I’m talking about. I’m referring to behind the scenes processes that the new DXP deployment process does when using the deployment API and the new docker processes that they have in place (they also use secrets for some data in the app service). I’ve literally had this in code and deployments to the API with the Optimizely managed secrets were being wiped out due to this configuration approach. So you always want to make sure _configuration = configuration; is being run on the DXP environments.
Yeah never post before its not deployed to the DXP 🙂 Many thanks though, like in the third screenshot I am already doing the environment check * if (isDevelopment) * for doing all this and adding the developer appsettings only for the local development.
var isDevelopment = Environment == Environments.Development;
I am going to update this blogpost based on the new learnings. Thanks again.
Apologies, I should read the blog more throughly as I missed the opening IsDevelopment wrapper, that’s what I get for skim reading. When I deployed I had a 500 and basically all the connectionstrings were blank, there’s some different processes now they are on docker and I think with the code on it tries to load the settings directly from the environment file and if they are empty (as they were for us) for the replacement DXP values they then are set to empty. Annoyingly it was my team who implemented this and I deployed so I didn’t know they’d done this.
Thank you for this, user secrets is what we need to consider next yes!