Are there any negative side effects to using the same UserSecretsId for multiple projects?

According to the documentation for the User Secrets feature of ASP.NET:

The preceding command adds a UserSecretsId element within a PropertyGroup of the project file. By default, the inner text of UserSecretsId is a GUID. The inner text is arbitrary, but is unique to the project (emphasis mine).

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <UserSecretsId>79a3edd0-2092-40a2-a04d-dcb46d5ca9ed</UserSecretsId>
</PropertyGroup>

Our project has a lot of interconnected microservices, many of which share the same secrets and configs (and none of which overlap keys). To simplify service/dev onboarding, we’re considering setting the UserSecretsId of all the projects in our solution to be the same value (as opposed to the current solution where they’re all separate folders and thus need separate secrets files). However, given this bit in the documentation, is there anything about the behavior of .NET or ASP.NET that would cause weird things to happen if any of these projects had the same UserSecretsId value?

The other solution we’ve thought of for this is to keep all of the UserSecretsId files different, but to symlink all of the secrets directories to point to the same folder. Having the projects share the same UserSecretsId is definitely simpler, since the symlink solution will require a script that the devs have to run.

Leave a Comment