Quick Look: AWS Parameter store

AWS offers a parameter store as part of the AWS Systems Manager service. Parameter Store serves a more fundamental purpose: a central, secure key-value store for application configuration and secrets.

Getting started is simple. Navigate to the AWS Console, open AWS Systems Manager, and select Parameter Store from the left navigation panel. The interface allows you to view, edit, delete, and create parameters—supporting three data types: String, StringList, and encrypted SecureString (backed by AWS Key Management Service).

Each parameter gets a name and value. For the name, I used a “/” to define a hierarchy. The parameter type can be a string, list of strings, or encrypted string.

The UI was smart enough that when I went to go add a second parameter (/seroterdemo/properties/awsvalue2), it detected my existing hierarchy.

And that's it!! Now you are ready to use it in a .NET Core web app.

And lastly , some Real-World Usage Patterns

While it remains a lightweight way to store static variables, modern cloud architectures rely on Parameter Store for critical integrations:

• Infrastructure as Code (IaC): AWS CloudFormation, Terraform, and AWS CDK directly resolve Parameter Store values at deployment time using dynamic references.

• Container & Serverless Injection: ECS task definitions and AWS Lambda functions natively fetch Parameter Store values as runtime environment variables, separating application logic from secrets and config.

Adding an app.debug.config app.release.config transformations in .NET applications

Most applications need to run on multiple environments and with multiple configurations. At a minimum we usually have at least a local and production environment, but more often we have a local environment, a system test, UAT as well as our production and pre-production environments. Transformations allow you can have different settings for different configurations (debug or release). 

For example, the most common transformation is our connection string. For different databases , we will always have different connection strings That means a lot of different configurations are needed for each environment. Currently for ASP.NET, MVC and Web API projects, we have this functionality supported with our Web.config transformations. However for our app.config, i.e. for console or class libraries this is still not supported, out of the box. So we have to manually create our own transformations.

Previously, I have achieved these transformations manually, as you can see from this previous article I wrote: Adding an app.debug.config app.release.config transformations in .NET applications   , but now there are many different extension and Nuget packages for Visual studio, like Slow Cheetah and Configuration Transform which help you to achieve this much easily. 

Slow Cheetah 

Lately I have been using Slow Cheetah a lot and I really like it, this package allows you to automatically transform your app.config in Visual studio. You can either download it as a Visual Studio extension from the website or just add it to your project from Nuget.

Once installed ,you get a right click option to Add Transform, when you right click on your app.config in your project solution . 

Clicking this option will automatically create your new debug and release configs for you. 
And as you can see they are correctly nested underneath the app.config. This is because Slow Cheetah has automatically updated our project file to contain the necessary settings to tell the release and debug config that they are dependent upon the app.config. Before we had to manually make these adjustments to the project file ourselves.

If we open our project file and check the settings added, we can now see something like this, this is how we would normally have to edit our project file to look like, this basically defines the dependency between the app.config and the release and debug config.

Also notice the IsTransformFile element, this is the important setting for Slow cheetah. Instructing it to automatically transform the App.config file depending on the chosen configuration.

And that's it, a lot of manual work saved already. Now you can can add whatever customization's you like inside the transform files, for example if you want to tweak app settings and connection string.

E.G here I have just added an app setting to the app.config and the app.release.config , setting the value to true in the release config and false in the app.config. 

Note, the use of the replace transform key to prompt the replacement of this value and the locator key. 

So if we walk-through the example above, the replace transform key, sends the instruction to replace the true value from the isProd key located beneath the appSetting element. This is done using the xdt:Transform attribute. 

Also note , that all XDT documents, i.e. your app.config, and each environment config, need a namespace declaration in the root element, otherwise your transformations will not happen.

When you build your application the files are transformed and dropped into the output directory. If you are transforming the app.config then when the file is transformed it will be renamed in the output directory as usual to ensure that your application picks it up at runtime.

Preview Transform 

You can also quickly preview your transform using the Preview Transform context menu on the transform file. By selecting the release config and right clicking in the solution explorer, we are presented with the differences, which in our case, is the app setting differences we added between the app and release configs. However as you know, environment configs can become very long and detailed, so this Preview Transform tool can be a god send when you are trying to check settings or connection strings to debug an issue.