Support file-based apps in user-secrets #63496

jjonescz · 2025-09-01T14:13:03Z

Support file-based apps in user-secrets

Makes the dotnet user-secrets tool work for file-based apps (via a new --file argument) analogously to how it works for project-based apps today.

Description

Supports dotnet user-secrets commands for file-based apps except dotnet user-secrets init (currently you have to set #:property UserSecretsId=... manually but we plan to add support for implicit UserSecretsIds in file-based apps but the technical side of that is still being discussed).

Resolves #63440.

Customer Impact

Driven by Aspire needs.

Regression?

Yes
No - this is a new feature

Risk

High
Medium
Low - this is a new feature which shouldn't affect any existing features

Verification

Manual (required)
Automated

Packaging changes reviewed?

Yes
No
N/A

jjonescz · 2025-09-02T18:03:12Z

cc @dotnet/run-file

Copilot

Pull Request Overview

This PR adds support for file-based apps in the dotnet-user-secrets tool, addressing issue #63440. The changes enable the tool to work with file-based C# apps that use #:property UserSecretsId=... directives instead of traditional MSBuild project files.

Key changes include:

Added --file option to specify file-based apps alongside the existing --project option
Enhanced test infrastructure to support both project-based and file-based app testing
Updated error messages and resource strings to accommodate the new functionality

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Tools/dotnet-user-secrets/test/UserSecretsTestFixture.cs	Added test helper methods for creating and managing file-based app test scenarios
src/Tools/dotnet-user-secrets/test/SecretManagerTests.cs	Enhanced existing tests to cover file-based apps and added validation for new error conditions
src/Tools/dotnet-user-secrets/src/Resources.resx	Added new error messages for file-based app scenarios and removed unused resource entries
src/Tools/dotnet-user-secrets/src/Program.cs	Updated ID resolution logic to handle both project and file options
src/Tools/dotnet-user-secrets/src/Internal/InitCommand.cs	Added validation to prevent init command usage with file-based apps
src/Tools/dotnet-user-secrets/src/CommandLineOptions.cs	Added `--file` option parsing and mutual exclusion validation with `--project`
src/Tools/Shared/SecretsHelpers/SecretsHelpersResources.resx	Updated error messages to mention the new `--file` option for better user guidance
src/Tools/Shared/SecretsHelpers/ProjectIdResolver.cs	Changed MSBuild command from `msbuild` to `build` with updated arguments

src/Tools/dotnet-user-secrets/test/UserSecretsTestFixture.cs

src/Tools/dotnet-user-secrets/test/SecretManagerTests.cs

jjonescz · 2025-09-03T07:44:27Z

@DamianEdwards any idea who I need reviews from here?

captainsafia · 2025-09-03T23:52:47Z

src/Tools/Shared/SecretsHelpers/ProjectIdResolver.cs

                ArgumentList =
                    {
-                        "msbuild",
+                        "build",


Are there any gotchas we should be on the lookout for as we move from msbuild to build for this? Also, I assume this exists because there are file-based app behaviors that are not available in msbuild?

msbuild is the 'raw' interface. it doesn't do multi-processing by default, doesn't do terminal logger (though you're not going to see that one), it doesn't do implicit restores, etc. build will do all of those (and it has the nice CLI args for some of the common properties) in addition to supporting the file-based apps. I'd say in general you should expect more churn in the behavior of build, but we do try to keep the contract pretty clean and consistent.

captainsafia · 2025-09-04T16:43:56Z

src/Tools/dotnet-user-secrets/test/SecretManagerTests.cs

+    [InlineData(false, true)]
+    [InlineData(false, false)]
+    [InlineData(true, false)]
+    public void SetSecrets(bool fromCurrentDirectory, bool fileBasedApp)


Should we error if you try to set secrets on a file-based app from a directory that the file is not in? Based on the options here, it seems like calling the below would be invalid?

$ pwd /user/some/dir $ dotnet user-secrets set "foo" "bar" --file /user/some/otherdir/file.cs

That is currently valid, the test verifies that (fromCurrentDirectory: false, fileBasedApp: true). What's invalid is when no --project and no --file is specified - that works if you are in the project's directory, but not for file-based apps (there could be multiple file-based apps in the directory).

What's invalid is when no --project and no --file is specified - that works if you are in the project's directory, but not for file-based apps (there could be multiple file-based apps in the directory).

Is there test coverage for this case? No project file in the current directory, but there are file-based app(s) in the current directory, and no --project and no --file arg is passed?

I will add a test for this, thanks.

RikkiGibson

LGTM with some questions/nits

RikkiGibson · 2025-09-04T23:13:07Z

src/Tools/Shared/SecretsHelpers/SecretsHelpersResources.resx

  <data name="Error_ProjectMissingId" xml:space="preserve">
    <value>Could not find the global property 'UserSecretsId' in MSBuild project '{project}'. Ensure this property is set in the project or use the '--id' command line option.</value>
  </data>
  <data name="Error_ProjectPath_NotFound" xml:space="preserve">


Should resource name also be changed?

RikkiGibson · 2025-09-05T19:45:47Z

src/Tools/dotnet-user-secrets/src/Resources.resx

+    <value>Cannot use both --file and --project options together.</value>
+  </data>
+  <data name="Error_InitNotSupportedForFileBasedApps" xml:space="preserve">
+    <value>Init command is currently not supported for file-based apps. Please add '#:property UserSecretsId=...' manually.</value>


All this command does is generate a guid and stick it in the UserSecretsId in the user's project? Is that right?

RikkiGibson · 2025-09-05T20:02:45Z

src/Tools/dotnet-user-secrets/test/SecretManagerTests.cs

            var parameters = fromCurrentDirectory ?
                new string[] { "set", secret.Key, secret.Value, "--verbose" } :
-                new string[] { "set", secret.Key, secret.Value, "-p", projectPath, "--verbose" };
+                [ "set", secret.Key, secret.Value, .. pathArgs, "--verbose" ];


nit: wonder if it would be simplifying if pathArgs was always included, and in the case fromCurrentDirectory is true, we would just ensure pathArgs is empty.

RikkiGibson · 2025-09-05T20:07:31Z

src/Tools/dotnet-user-secrets/test/SecretManagerTests.cs

+    [InlineData(false, true)]
+    [InlineData(false, false)]
+    [InlineData(true, false)]
+    public void SetSecrets(bool fromCurrentDirectory, bool fileBasedApp)


What's invalid is when no --project and no --file is specified - that works if you are in the project's directory, but not for file-based apps (there could be multiple file-based apps in the directory).

Is there test coverage for this case? No project file in the current directory, but there are file-based app(s) in the current directory, and no --project and no --file arg is passed?

danmoseley · 2025-09-05T21:38:47Z

@captainsafia is this intentionally against the RC2 branch? I assume we'll have a template in due course?

jjonescz · 2025-09-08T11:47:52Z

is this intentionally against the RC2 branch? I assume we'll have a template in due course?

This is intentionally targeting .NET 10, yes. I'm not sure what template you have in mind with relation to this PR.

captainsafia · 2025-09-08T15:59:00Z

is this intentionally against the RC2 branch? I assume we'll have a template in due course?

This is intentionally targeting .NET 10, yes. I'm not sure what template you have in mind with relation to this PR.

@danmoseley is referring to the template here: https://github.com/dotnet/aspnetcore/blob/main/.github/PULL_REQUEST_TEMPLATE/servicing.md. You can see it in action in this PR.

baronfel · 2025-09-08T16:00:38Z

It's a little wonky because SDK and most other 'tooling' is open through RC2 generally, but since this change is shared with a more 'runtime'-behaving component the process is a little off by comparison.

jjonescz · 2025-09-09T12:03:33Z

I've filled the template in the PR's description.

jjonescz · 2025-09-10T09:55:59Z

@captainsafia do I need something else to get this merged? Thanks

jjonescz · 2025-09-11T08:08:38Z

I have a follow-up PR here ready as well (to implicitly compute UserSecretsId if it's not set in the project/file-based app), so would like to get this merged soon.

captainsafia · 2025-09-15T22:00:16Z

@dotnet/aspnet-build Can we get help merging this? There's a follow-up PR that needs to be taken through as well.

DamianEdwards · 2025-09-15T22:33:31Z

There's a follow-up PR that needs to be taken through as well.

@captainsafia I think we don't need the follow-up PR anymore as the required change is going directly into dotnet/sdk now, but this PR, definitely 😄

Support file-based apps in user-secrets

dbcd91b

build-analysis bot mentioned this pull request Sep 1, 2025

Known Build Error: error : Cannot create a file when that file already exists. #61178

Open

jjonescz added 2 commits September 1, 2025 19:29

Fix resource texts

ec168ba

Avoid restore

e04104c

jjonescz marked this pull request as ready for review September 2, 2025 18:02

Copilot AI review requested due to automatic review settings September 2, 2025 18:02

Copilot AI reviewed Sep 2, 2025

View reviewed changes

src/Tools/dotnet-user-secrets/test/UserSecretsTestFixture.cs Show resolved Hide resolved

src/Tools/dotnet-user-secrets/test/SecretManagerTests.cs Show resolved Hide resolved

captainsafia reviewed Sep 3, 2025

View reviewed changes

captainsafia reviewed Sep 4, 2025

View reviewed changes

RikkiGibson self-assigned this Sep 4, 2025

RikkiGibson approved these changes Sep 5, 2025

View reviewed changes

Improve naming and tests

a816de2

Test clear

92f6bd2

captainsafia added area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI Servicing-consider Shiproom approval is required for the issue labels Sep 11, 2025

captainsafia approved these changes Sep 11, 2025

View reviewed changes

danmoseley added Servicing-approved Shiproom has approved the issue and removed Servicing-consider Shiproom approval is required for the issue labels Sep 11, 2025

wtgodbe merged commit f7d34bf into dotnet:release/10.0 Sep 16, 2025
28 checks passed

dotnet-policy-service bot added this to the 10.0-rc2 milestone Sep 16, 2025

jjonescz deleted the sprint-user-secrets branch September 17, 2025 15:04

Support file-based apps in user-secrets #63496

Support file-based apps in user-secrets #63496

Conversation

jjonescz commented Sep 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Support file-based apps in user-secrets

Description

Customer Impact

Regression?

Risk

Verification

Packaging changes reviewed?

Uh oh!

jjonescz commented Sep 2, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

jjonescz commented Sep 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jjonescz Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RikkiGibson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danmoseley commented Sep 5, 2025

Uh oh!

jjonescz commented Sep 8, 2025

Uh oh!

captainsafia commented Sep 8, 2025

Uh oh!

baronfel commented Sep 8, 2025

Uh oh!

jjonescz commented Sep 9, 2025

Uh oh!

jjonescz commented Sep 10, 2025

Uh oh!

jjonescz commented Sep 11, 2025

Uh oh!

captainsafia commented Sep 15, 2025

Uh oh!

DamianEdwards commented Sep 15, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jjonescz commented Sep 1, 2025 •

edited

Loading

jjonescz Sep 4, 2025 •

edited

Loading