Support variables in `#:project` directives #51108

jjonescz · 2025-10-02T08:40:01Z

Copilot

Pull Request Overview

Adds support for MSBuild variable expansion inside #:project directives and updates tests and documentation accordingly.

Introduces directive evaluation pass (EvaluateDirectives) to expand MSBuild variables and resolve project paths.
Extends CSharpDirective.Project to preserve original and unresolved names for later path adjustments during project conversion.
Adds tests covering variable usage and updates documentation about variable handling limitations.

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
RunTelemetryTests.cs	Adapts tests to new CSharpDirective.Project constructor.
RunFileTests.cs	Adds tests for variable-based project references and malformed variable syntax.
DotnetProjectConvertTests.cs	Adds test cases for variable-containing paths; updates expectations for cross-platform separators.
VirtualProjectBuildingCommand.cs	Adds directive evaluation, caching of source file, and enhanced project directive handling.
ProjectConvertCommand.cs	Integrates directive evaluation and updates path rewrite logic to preserve variable intent.
dotnet-run-file.md	Documents variable support and caveats for #:project directives.

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs

documentation/general/dotnet-run-file.md

Co-authored-by: Copilot <[email protected]>

RikkiGibson · 2025-10-02T18:34:49Z

The linked issue has milestone 10.0.2xx, was this PR meant to target release/10.0.2xx branch?

jjonescz · 2025-10-02T18:38:15Z

Definitely, I was worried there might be changes missing in the 2xx branch, but looks like it's fairly up to date wrt file-based app PRs, so I can retarget now.

jjonescz · 2025-10-08T08:37:41Z

@RikkiGibson @333fred @MiYanni for reviews, thanks

src/Cli/dotnet/Commands/Project/Convert/ProjectConvertCommand.cs

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs

documentation/general/dotnet-run-file.md

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs

src/Cli/dotnet/Commands/Project/Convert/ProjectConvertCommand.cs

RikkiGibson

LGTM, but, would like to wait to merge until #51373 goes in, if possible, so that I can punt the conflicts over to you :P

I guess there will also be a need to decide whether the analyzer will do the evaluation step. I lean slightly toward yes it should, but, don't feel very strongly at the moment.

RikkiGibson · 2025-10-31T19:20:03Z

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs

+        /// the <see cref="UnresolvedName"/> will be expanded, but not resolved
+        /// (i.e., can be pointing to project directory or file).
+        /// </remarks>
+        public string UnresolvedName { get; init; }


It feels like it's not straightforward to determine whether certain steps have been performed or not on a given Project instance. I'm concerned that if the Project instance reached a layer of the system which expects expansion and/or resolution to have already been done, when those steps weren't actually performed, it may pass by unnoticed.

Is there anything we can do about that? For example, maybe there should be ExpandedName, ResolvedName etc properties which are just null when that step hasn't been performed on the instance. And the base Name property might just hold "whatever the 'best name' is" for the instance, which appears to be used for deduplication, etc.

Curious if you think this situation is worth doing anything about.

It also looks like properties which refer to the same project, using different original paths, are supposed to be treated as duplicates. I think I filed a bug on that for when path/to/project/ and path/to/project/Project.csproj are both used. But do we also have tests for cases where a variable expansion causes paths $(Prop1)/Project.csproj and $(Prop2)/Project.csproj to be the same, for example?

It also looks like properties which refer to the same project, using different original paths, are supposed to be treated as duplicates. I think I filed a bug on that for when path/to/project/ and path/to/project/Project.csproj are both used. But do we also have tests for cases where a variable expansion causes paths $(Prop1)/Project.csproj and $(Prop2)/Project.csproj to be the same, for example?

I will add a test referencing the issue, but I think solving that is part of that issue, so I'd rather do it in a follow up.

Is there anything we can do about that? For example, maybe there should be ExpandedName, ResolvedName etc properties which are just null when that step hasn't been performed on the instance. And the base Name property might just hold "whatever the 'best name' is" for the instance, which appears to be used for deduplication, etc.

You're right, that sounds like it will clarify the code a lot; I will try that; thanks!

jjonescz · 2025-11-12T17:25:56Z

@RikkiGibson for another look, thanks

RikkiGibson · 2025-11-12T21:43:38Z

src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs

-                // https://github.com/dotnet/sdk/issues/51487: Behavior should not depend on process current directory
-                var sourceDirectory = Path.GetDirectoryName(context.SourceFile.Path) ?? ".";
+                // Also normalize backslashes to forward slashes to ensure the directive works on all platforms.
+                var sourceDirectory = Path.GetDirectoryName(sourceFile.Path) ?? ".";


I think we should restore the tracking comment.

Suggested change

var sourceDirectory = Path.GetDirectoryName(sourceFile.Path) ?? ".";

// https://github.com/dotnet/sdk/issues/51487: Behavior should not depend on process current directory

var sourceDirectory = Path.GetDirectoryName(sourceFile.Path) ?? ".";

I don't think this code path depends on the current directory. There are even tests for that - you can run dotnet project convert from any working directory and it should work the same way.

It seems like if the value "." were used for sourceDirectory here, then the behavior of the following Directory.Exists call, would depend on the process current directory.

If "." is never used, then I think it should be deleted, and perhaps replaced with an assertion that GetDirectoryName return value is non-null.

Ah, you're right, I completely missed that ".", thanks!

I think that's unreachable if sourceFile.Path is a valid file path anyway (Path.GetDirectoryName would return null only for something like / or C:/ afaik), so I will change this to throw.

RikkiGibson · 2025-11-12T21:46:04Z

src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs


                    // Keep a relative path only if the original directive was a relative path.
-                    directiveText = ExternalHelpers.IsPathFullyQualified(directiveText)
+                    directiveText = Path.IsPathFullyQualified(directiveText)


I think we should revert to release/10.0.2xx version of this line

Suggested change

directiveText = Path.IsPathFullyQualified(directiveText)

directiveText = ExternalHelpers.IsPathFullyQualified(directiveText)

Thanks, looks like my mistake when resolving merge conflicts.

RikkiGibson · 2025-11-12T21:46:53Z

src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs

+                    directiveText = Path.IsPathFullyQualified(directiveText)
                        ? fullFilePath
-                        : ExternalHelpers.GetRelativePath(relativeTo: sourceDirectory, fullFilePath);
+                        : Path.GetRelativePath(relativeTo: sourceDirectory, fullFilePath);


I think we should revert to release/10.0.2xx version of this line

Suggested change

: Path.GetRelativePath(relativeTo: sourceDirectory, fullFilePath);

: ExternalHelpers.GetRelativePath(relativeTo: sourceDirectory, fullFilePath);

I wonder if the last CI build was made before the source package was added to the solution. I would expect the usages in this PR to fail the netstandard2.0 build of the source package.

I wonder if the last CI build was made before the source package was added to the solution. I would expect the usages in this PR to fail the netstandard2.0 build of the source package.

Yes, looks like that's the case - the CI run is from Nov 5, and the sln was updated Nov 6.

RikkiGibson · 2025-11-12T21:51:33Z

src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs

+    /// <summary>
+    /// If there are any <c>#:project</c> <paramref name="directives"/>, expand <c>$()</c> in them and then resolve the project paths.
+    /// </summary>
+    public static ImmutableArray<CSharpDirective> EvaluateDirectives(


When this change is consumed on the Roslyn side, I think the Roslyn analyzer should call this method also, to avoid a change in behavior. See also dotnet/roslyn#80575 (comment)

RikkiGibson · 2025-11-12T22:04:48Z

src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs

+        /// </summary>
+        public Project ResolveProjectPath(SourceFile sourceFile, DiagnosticBag diagnostics)
+        {
+            var directiveText = Name;


nit: would be good to rename this to something like resolvedName

src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs

jjonescz added the Area-run-file Items related to the "dotnet run <file>" effort label Oct 2, 2025

Support variables in #:project directives

bc17aea

jjonescz force-pushed the sprint-project-vars branch from 9ad9ae2 to bc17aea Compare October 2, 2025 08:52

Fix slashes

7a28231

build-analysis bot mentioned this pull request Oct 2, 2025

GenerateBundle Task fails writing to singlefilehost.exe #50784

Open

jjonescz requested a review from Copilot October 2, 2025 14:42

Copilot AI reviewed Oct 2, 2025

View reviewed changes

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs Outdated Show resolved Hide resolved

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs Outdated Show resolved Hide resolved

documentation/general/dotnet-run-file.md Show resolved Hide resolved

Fix typo in a comment

bfba2dc

Co-authored-by: Copilot <[email protected]>

jjonescz marked this pull request as ready for review October 2, 2025 14:49

jjonescz requested a review from a team October 2, 2025 14:49

jjonescz changed the base branch from release/10.0.1xx to release/10.0.2xx October 2, 2025 18:36

This comment was marked as outdated.

Sign in to view

jjonescz mentioned this pull request Oct 3, 2025

Fix 2xx builds #51118

Merged

jjonescz added this to the 10.0.2xx milestone Oct 3, 2025

dotnet deleted a comment from azure-pipelines bot Oct 3, 2025

jjonescz mentioned this pull request Oct 8, 2025

File-based programs live directive diagnostics dotnet/roslyn#80575

Merged

333fred reviewed Oct 8, 2025

View reviewed changes

src/Cli/dotnet/Commands/Project/Convert/ProjectConvertCommand.cs Outdated Show resolved Hide resolved

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs Outdated Show resolved Hide resolved

RikkiGibson reviewed Oct 8, 2025

View reviewed changes

documentation/general/dotnet-run-file.md Show resolved Hide resolved

MiYanni approved these changes Oct 9, 2025

View reviewed changes

documentation/general/dotnet-run-file.md Show resolved Hide resolved

jjonescz added 2 commits October 9, 2025 13:51

Remove unnecessary requireds

b3dc5e4

Preserve variables inside full paths

2a0f51a

jjonescz requested review from 333fred and RikkiGibson October 29, 2025 10:40

333fred approved these changes Oct 29, 2025

View reviewed changes

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs Outdated Show resolved Hide resolved

RikkiGibson reviewed Oct 30, 2025

View reviewed changes

src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs Outdated Show resolved Hide resolved

RikkiGibson reviewed Oct 30, 2025

View reviewed changes

src/Cli/dotnet/Commands/Project/Convert/ProjectConvertCommand.cs Outdated Show resolved Hide resolved

jjonescz added 4 commits October 30, 2025 09:20

Merge branch 'release/10.0.2xx' into sprint-project-vars

ffa9443

Improve code

4194017

Fix and test dependency on working directory

f829602

Fix file name case in a test

9fd4539

baronfel mentioned this pull request Oct 30, 2025

dotnet run file.cs / file-based app - environment variables available in directives #51499

Closed

RikkiGibson reviewed Oct 31, 2025

View reviewed changes

jjonescz added 4 commits November 5, 2025 13:31

Merge branch 'release/10.0.2xx' into sprint-project-vars

9f33382

Move directive evaluation to the shared package

dd92781

Test duplicate project directives

be97a18

Clarify project directive name properties

8987eb1

jjonescz requested a review from RikkiGibson November 5, 2025 14:45

build-analysis bot mentioned this pull request Nov 5, 2025

error : HttpRequestException: The SSL connection could not be established, see inner exception. dotnet/dnceng#5015

Open

3 tasks

RikkiGibson approved these changes Nov 12, 2025

View reviewed changes

jjonescz added 2 commits November 13, 2025 12:11

Merge branch 'release/10.0.2xx' into sprint-project-vars

5c7334a

Fix source package errors

422beed

333fred approved these changes Nov 13, 2025

View reviewed changes

src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs Show resolved Hide resolved

Improve code

fdd1d0e

jjonescz merged commit d04687c into dotnet:release/10.0.2xx Nov 14, 2025
22 of 25 checks passed

jjonescz deleted the sprint-project-vars branch November 14, 2025 11:56

dotnet-maestro bot mentioned this pull request Nov 14, 2025

[release/10.0.2xx] Source code updates from dotnet/sdk dotnet/dotnet#3318

Merged

	var sourceDirectory = Path.GetDirectoryName(sourceFile.Path) ?? ".";
	// https://github.com/dotnet/sdk/issues/51487: Behavior should not depend on process current directory
	var sourceDirectory = Path.GetDirectoryName(sourceFile.Path) ?? ".";

	directiveText = Path.IsPathFullyQualified(directiveText)
	directiveText = ExternalHelpers.IsPathFullyQualified(directiveText)

	: Path.GetRelativePath(relativeTo: sourceDirectory, fullFilePath);
	: ExternalHelpers.GetRelativePath(relativeTo: sourceDirectory, fullFilePath);

Support variables in #:project directives #51108

Support variables in #:project directives #51108

Uh oh!

Conversation

jjonescz commented Oct 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!

Uh oh!

RikkiGibson commented Oct 2, 2025

Uh oh!

jjonescz commented Oct 2, 2025

Uh oh!

This comment was marked as outdated.

jjonescz commented Oct 8, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RikkiGibson left a comment • 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!

RikkiGibson Oct 31, 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!

jjonescz commented Nov 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RikkiGibson Nov 13, 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!

jjonescz Nov 14, 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!

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!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Support variables in `#:project` directives #51108

Support variables in `#:project` directives #51108

RikkiGibson left a comment •

edited

Loading

RikkiGibson Oct 31, 2025 •

edited

Loading

RikkiGibson Nov 13, 2025 •

edited

Loading

jjonescz Nov 14, 2025 •

edited

Loading