Skip to content

Improvements to User Secrets #107849

@ElanHasson

Description

@ElanHasson

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Note: I initially thought this could fit well into aspire, but as I was typing this up, I realized it may be a better fit for dotnet proper. Feel free to move this issue there.

I wish there was a better story around User Secrets for teams or even just new machines.

I got a new computer, cloned my repo, started my project and got an OptionsVaidator exception and it took me a few min to figure out what was missing.

I've invested some time setting up Aspire just right and the project, so it didn't rely on external values for things-- easy to get started day one for new team members: clone repo, F5.

Then I realized it was my User Secrets that were missing-- they're pretty much set and forget-- and they stay on the local machine for obvious reasons.

So, new machine, I have to set them. One more thing to remember to do. One more document to write. One more document to keep in sync. 😢

Describe the solution you'd like

I'd love to see a way to provide a default secrets.json for an Aspire project (or even a csproj as this would benefit non-aspire projects as well).

I do not think we need a new mechanism for this as I think this would fit well into the csproj and this could probably implemented via a MSBuild task.

<Project Sdk="Microsoft.NET.Sdk.Web">
   <PropertyGroup>
   	<!--Exists Today-->
   	<UserSecretsId>37913f03-ffcc-4c77-9904-6b7241929494</UserSecretsId>
   	<!--Proposed-->
   	<UserSecrets>
   		{
   		"clientId": "",
   		"clientSecret": "" // Get creds from https://my-intranet/provision-client,
                       "secret_tokens": []
                       "complexSecrets": {
                          "userId": 43110,
   		}
   	</UserSecrets>
   </PropertyGroup>
</Project>

How would it work?

The point here is not to require a schema be specified, but only structural validation. The assumption is all values are required, values and types aren't validated, the exception is for properties that are object types: we would validate the path exists ($.complexSecrets.userId using above sample).

Non-Aspire

When you open a project in VS or Code, the host would see the UserSecrets element and see the current user secrets specified by UserSecretsId do not match the template specified in the csproj and alert the user that they are required and show them the template.

When you use the CLI, validation would occur at build time and the problem would be surfaced there.

Aspire

I'm not sure what this would look like in aspire, perhaps the above Non-Aspire workflow is better suited to be implemented as a UserSecrets resource that performs the validation.

I think it maybe makes sense to do so as Aspire is responsible for downstream config injection to the projects and user secrets do get injected via a different pipeline outside of Aspire.

Additional context

Related Issues: dotnet/aspire#4035 dotnet/aspire#2953 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions