User Secrets, or Development Secrets, in ASP.Net Core allow developers to manage sensitive data on their development machines. This data can include database connection strings, usernames and passwords, and API keys.
NOTE: Test and production secrets can be stored in Azure Key Vault.
Right now we have the FredsCarsMvcConnection connection string stored in appsettings.development.json.
And the FredsCarsMvcConnection connection string uses a trusted connection. But if it had a user id and password then every time a developer checked their project into a repository like GitHub this private information could be checked in with it where the whole development team could see it. And if the repository is public, where the whole world could see it.
Secrets allow you to take pieces of your configuration and store them in a configuration file on your dev machine in the file system instead of appsettings.development.json in the project and avoid checking in the sensitive data.
Manage User Secrets
Right click on the FredsCars project and select Manage User Secrets.

A file called secrets.json will be created and opened in a new tab within the VS IDE.

The secrets.json file can be found at:
%appData%\Roaming\Microsoft\UserSecrets.
On Windows, names like %AppData% are called environment variables.
They’re placeholders that the operating system expands into actual file system paths. For example:
%AppData%→ usually expands toC:\Users\<username>\AppData\Roaming%LocalAppData%→C:\Users\<username>\AppData\Local%ProgramFiles%→C:\Program Files%SystemRoot%→C:\Windows
These are part of the Windows environment variables system, and they’re often used in batch scripts, installers, or when entering paths into Explorer’s address bar or the Run dialog.
Open the FredsCars properties by double clicking the FredsCars project or right clicking the FredsCars project and selecting Properties.

In the Properties tab you can see a new Property has been created called UserSecretsId with a GUID value.
<PropertyGroup>
<TargetFramework>net9.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<UserSecretsId>2d407b10-d717-418f-b569-8e31ed1f4fc3</UserSecretsId>
</PropertyGroup>
Don’t forget to save the Properties in the FredsCars tab for the FredsCars.csproj file.

This is the actual folder within the UserSecrets folder that the secrets.json file is stored in.
C:\Users\<user-name>\AppData\Roaming\Microsoft\UserSecrets\2d407b10-d717-418f-b569-8e31ed1f4fc3\secrets.json

Using GUIDs
In .NET, a GUID (pronounced “goo-id” or “gwid”) is a Globally Unique Identifier.
It’s a 128-bit (16-byte) value used to uniquely identify something across space and time, without needing a central authority. In code, it’s represented by the struct:
System.Guid
Format
A GUID is usually shown as a string in hexadecimal with hyphens, like:
550e8400-e29b-41d4-a716-446655440000
Internally it’s just a 16-byte value.
Common Uses in .NET
- Database keys (instead of integer IDs).
- COM objects (to uniquely identify interfaces/classes).
- Entity Framework models.
- Correlation IDs for logging and tracing.
- File, session, or transaction identifiers.
Store a Secret
Now, cut the ConnectionStrings section from appsettings.development.json and past it into the secrets.json file.
The appsettings.development.json file should now look like the following:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning",
"FredsCars": "Debug"
}
},
"Serilog": {
"MinimumLevel": {
"Override": {
"FredsCars": "Debug"
}
}
},
"AllowedHosts": "*",
}
And the secrets.json file should look like the following:
{
"ConnectionStrings": {
"FredsCarsMvcConnection": "Server=(localdb)\\MSSQLLocalDB;Database=FredsCarsMvc;Trusted_Connection=True;MultipleActiveResultSets=true"
}
}
Confirm secrets.json created correctly
Run the following command against the FredsCars project folder in a command console.
dotnet user-secrets list
The results will show the one secret we have stored now: the ConnectionString FredsCarsMvc.

Now if you restart the application the behavior should be the same but now you will not check in the sensitive connection string to your repository.
Edit the UserSecretsId
If we look back at the new Property in the project file (FredsCars.csproj) the GUID value is kind of non-descriptive.
<UserSecretsId>2d407b10-d717-418f-b569-8e31ed1f4fc3</UserSecretsId>
It’s possible for a UserSecrets folder to contain many folders with GUID names making it hard to differentiate each one and identify the correct one for a specific project.

It’s a perfectly good option to leave things as they are and leave the auto-generated GUID UserSecretsId property value and folder name. After all, we will manage all of the User Secrets through the Visual Studio IDE simply by right clicking on the FredsCars project and selecting Manage User Secrets.
We do, however, have the option of changing the UserSecretsId to a more descriptive value.
Update the FredsCars properties with the change showed below.
FredsCars\FredsCars.csproj
<PropertyGroup>
<TargetFramework>net9.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<UserSecretsId>FredsCarsMvc</UserSecretsId>
</PropertyGroup>
Next, change the subfolder name with the folder name
2d407b10-d717-418f-b569-8e31ed1f4fc3
in the UserSecrets folder to FredsCarsMvc to match the new UserSecretsId in the project properties.

Now lets run:dotnet user-secrets list
one more time to make sure the application can still find the project secrets.

And, once again restart the application and the behavior should still remain the same.
What’s Next
In this module we learned how to manage and store User Secrets.
In the next module we will turn our attention back to error handling and set up a global wide error handling system.
