-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Description
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)