Add support for file-based apps to dotnet user-secrets

[DamianEdwards]

File-based apps are introduced in .NET 10, allowing for C# apps that are based on just a single .cs file and optionally other supporting content and settings files (e.g. [appname].settings.json, etc.). There is no project file (*.csproj) for these apps and they can be run directly via dotnet run app.cs or just dotnet app.cs.

dotnet user-secrets should be updated to support file-based apps so that it's simple to use user secrets with them. This will involve adding a -f, --file option to all commands to allow specifying the application file, e.g.:

• dotnet user-secrets init -f app.cs
• dotnet user-secrets set -f app.cs setting1=true
• dotnet user-secrets set -f app.cs setting1=true;setting2=true
• type .\secrets.json | dotnet user-secrets set -f app.cs
• dotnet user-secrets clear -f app.cs
• dotnet user-secrets list -f app.cs
• dotnet user-secrets remove -f app.cs setting1

Additionally, dotnet user-secrets should support working with file-based apps that don't have an explicit user secrets ID set by utilizing an implicit ID based on a hash of the full file path. This allows for the commands to work without first needing to run dotnet user-secrets init -f app.cs. If init is run, it should use the file path hash as the ID rather than a new GUID, unless the --id option is specified.

[DamianEdwards]

Note that the CLI can be used with file-based apps today by manually specifying the --id option. See https://github.com/DamianEdwards/runfile/blob/3fd48906414c517f0fce07784d3b482f22923cf7/flat/usersecrets.cs for an example of using user secrets with file-based apps.

[jjonescz]

I'm thinking about adding the implicit UserSecretsId hash computation over to the SDK side - i.e., setting <UserSecretsId Condition="'$(UserSecretsId)' == ''">...hash...</UserSecretsId> in the virtual project file, so that even the implicit $(UserSecretsId) property can be used by user's MSBuild code (if it was just computed by dotnet user-secrets tooling, it would not be visible outside which would be inconsistent with project-based apps). Not sure if that's better or not. It would also mean the hashing logic would need to be duplicated here for init without --id though (or keep it emitting GUIDs).

Btw, what about dotnet project convert? That currently won't preserve the implicit UserSecretsId (it could if we compute it on the sdk side, but it seems like unnecessary noise for all file-based apps). Perhaps it's fine that users will need to do dotnet user-secrets init (when that's supported) before dotnet project convert.

[DamianEdwards]

@jjonescz I like the idea of doing this over on the SDK side. The point about project convert is an interesting one. Perhaps that's an argument to default the UserSecretsId for all projects based on the path, and update dotnet user-secrets accordingly. Then we could have a consistent experience across file-based and project-based apps, but it would be a behavior change for dotnet user-secrets as today I believe it just parses the project file directly to get the ID, rather than evaluating it via MSBuild.

[jjonescz]

as today I believe it just parses the project file directly to get the ID, rather than evaluating it via MSBuild

No, it's doing evaluation of the project via MSBuild even today to get UserSecretsId.

[DamianEdwards]

No, it's doing evaluation of the project via MSBuild even today to get UserSecretsId.

Oh ok, my bad then! So, changing the defaults so that init isn't required for any project because the ID defaults to something based on the app project or file path shouldn't be a break?