vs-secrets 2.2.1

There is a newer version of this package available.
See the version list below for details.
dotnet tool install --global vs-secrets --version 2.2.1                
This package contains a .NET tool you can call from the shell/command line.
dotnet new tool-manifest # if you are setting up this repo
dotnet tool install --local vs-secrets --version 2.2.1                
This package contains a .NET tool you can call from the shell/command line.
#tool dotnet:?package=vs-secrets&version=2.2.1                
nuke :add-package vs-secrets --version 2.2.1                

.NET Nuget Nuget

Visual Studio Solution Secrets

Synchronize solution secrets across different development machines.

<br/>

Get Started

If you already know it, here are the quick start commands.

  1. Install
dotnet tool install --global vs-secrets
  1. Configure
vs-secrets init -p <your-passphrase>
  1. Pull secrets
vs-secrets pull

<br/>

Best Practices

As a good practices in DevOps, you must not store secrets (sensitive data like passwords, connection strings, access keys, etc.) in your source code that is committed in a shared repository and secrets must not be deployed with the apps.

Fortunately Visual Studio and .Net help us in separating secrets from our code with the User Secrets Manager that let us store secrets out of the solution folder. The User Secrets Manager hides implementation details, but essentially it stores secrets in files located in the machine's user profile folder.

You can find the User Secrets Manager documentation here.

The Problem

The User Secrets Manager is a great tool, but when you change your development machine, usually you clone your project code from a remote repository and then you would like to be up and running for coding and testing in a matter of seconds.

But if you have managed secrets with the User Secrets Manager you will not be immediatly able to test your code because you will miss something very important on your new machine: the secret settings that let your code work.

The Solution

For being ready to start coding and testing on the new development machine, you have three choices.

  1. Manually copy secret files from the old machine to the new one, if you still have access to the old machine.
  2. Recreate the secret settings on your new machine for each project of the solution, but this can be tedious because you have to recover passwords, keys, etc. from different resources and it can be time consuming.
  3. **New** : use Visual Studio Solution Secrets to synchronize secret settings through the cloud in a quick and secure way.

Visual Studio Solution Secrets synchronizes secret settings through the cloud in a quick and secure way.

The idea is to use a secure repository in the cloud for storing secret settings, so that when you change the development machine, you don't have to copy any file from the old one.

Just install the tool, configure it and pull the solutions secrets on your new machine and you are ready to code.

It's fast!

Visual Studio Solution Secrets support two kinds of remote repositories:

  • GitHub Gists
  • Azure Key Vault

GitHub Gists

A "gist" is a snippet of code that can either be public or secret. Visual Studio Solution Secrets uses only secret gists.

GitHub Gists is the default repository used by Visual Studio Solution Secrets for storing solutions secrets. Secrets are collected, encrypted and pushed on your GitHub account in a secret gist, so that only you can see them. The encryption key is generated from a passphrase or a key file that you specify during the one time initialization phase of the tool.

GitHub Gists fits very well for personal use.

Concept

Azure Key Vault

Azure Key Vault is a cloud service for securely storing and accessing secrets. Secrets are encrypted at rest and can be accessed only be authorized accounts. No one else can read their contents.

Since the secrets are encrypted at rest and communication with the key vault is secure because it is enforced as HTTPS / TLS 1.2, Visual Studio Solution Secrets does not encrypt the secrets by itself before sending them to the key vault, therefore it is not necessary to use the encryption key on the local machine.

This opens the scenario in which you can share the secrets of the solution with the development team. You just need to authorize the team with read or read/write access to the Azure Key Vault secrets, so that the team can pull secrets.

Azure Key Vault fits better for enterprise use and is the recommended way for sharing solution secrets within the team.

You can read the Azure Key Vault documentation here

Concept

<br/>

How to install

The tool is installed using the dotnet command line interface:

dotnet tool install --global vs-secrets

For upgrading to the latest version, use the command:

dotnet tool update --global vs-secrets

Configure the encryption key and authorizations

In case you use GitHub Gists as secrets repository, after the tool is installed, you need to create the encryption key and then authorize the use of your GitHub Gists.

The local encryption key is not necessary with Azure Key Vault.

Create the encryption key from a passphrase:

vs-secrets init -p <your-passphrase>

Otherwise, you can create the encryption key from a key file with the command below:

vs-secrets init --keyfile <file-path>

In case the encryption key is compromised you can change it.

vs-secrets change-key --passphrase <new-passphrase>
vs-secrets change-key --keyfile <file-path>

When you change the encryption key with one of the above commands, any secret already encrypted on GitHub Gists is re-encrypted with the new key. In this way the compromised key becomes useless.

Repository configuration

As said, GitHub Gists is the default repository, but in case you need, any solution can use a different repository for storing its secret settings.

For example, you can set up your own projects to use GitHub Gists and work projects to use Azure Key Vault.

For configuring the solution to use GitHub Gists:

vs-secrets configure --repo github

For configuring the solution to use Azure Key Vault:

vs-secrets configure --repo azurekv --name <vault-name | vault-uri>

The --name option works only for Azure Key Vault repositories and can accept the key vault URI (ex: https://my-keyvault.vault.azure.net) or the resource name (ex: my-keyvault). In case you use the key vault resource name, it is then completed in its URI (ex: my-keyvaulthttps://my-keyvault.vault.azure.net).

For changing the default repository, use one of the commands below:

vs-secrets configure --default --repo github
vs-secrets configure --default --repo azurekv --name <vault-name | vault-uri>

Sometimes you need to check what is the default repository, or if the solution has a custom repository configuration.

The command configure list serves to this purpose.

vs-secrets configure list [<folder-path>] [--all]

Push solution secrets

For pushing the secrets of the solution in the current folder:

vs-secrets push

For pushing the secrets of the solution in another folder:

vs-secrets push <solution-path>

For pushing the secrets of all the solutions in a folder tree:

vs-secrets push --all
vs-secrets push <path> --all

Pull solution secrets

For pulling the secrets of the solution in the current folder:

vs-secrets pull

For pulling the secrets of the solution in another folder:

vs-secrets pull <solution-path>

For pulling the secrets of all the solutions in a folder tree:

vs-secrets pull --all
vs-secrets pull <path> --all

Utility commands

Search for solutions that use secrets

You can use the tool for just searching solutions and projects that use secrets

vs-secrets search [<solution-path>] [--all]

Checking the status

With the status command you can check for the status of the tool. The command below checks if the encryption key has been defined and if the tool has been authorized to access GitHub Gists:

vs-secrets status

If the current folder contains a solution, the status command will show also the synchronization status for the secrets of the solutions.

Optionally you can check the synchronization status in another folder specifying the folder path or in an entire folder tree adding the --all parameter. Here are some examples:

vs-secrets status --all
vs-secrets status c:\projects\my-project-folder
vs-secrets status c:\projects --all

Clear secret settings from the local machine

If there are secrets that you need to clear locally, the clear command erases the solution secrets from the local machine. It is equivalent to applying the command dotnet user-secrets clear to each project in the solution.

vs-secrets clear
vs-secrets clear .\my-solution.sln

Configuration files

Visual Studio Solution Secrets stores its configuration files in the machine's user profile folder.

Platform Path
Windows %APPDATA%\Visual Studio Solution Secrets
macSO ~/.config/Visual Studio Solution Secrets
Linux ~/.config/Visual Studio Solution Secrets

The files generated by the tool are listed below.

File Description
cipher.json Contains the encryption key
github.json Contains the access token for managing user's GitHub Gists
configuration.json Contains the settings for the repository to use by default and for each solution configured with the command configure
Product Compatible and additional computed target framework versions.
.NET net6.0 is compatible.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 is compatible.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

Version Downloads Last updated
2.2.2 92 11/7/2024
2.2.1 99 8/2/2024
2.2.0 201 11/19/2023
2.1.2 245 10/27/2023
2.1.1 219 8/29/2023
2.1.0 259 8/8/2023
2.0.2 193 7/21/2023
2.0.1 169 7/10/2023
2.0.0 406 11/9/2022
1.2.1 503 10/13/2022
1.2.0 543 9/24/2022
1.1.2 499 4/6/2022