Skip to content

Include file based program sources#81284

Merged
jjonescz merged 12 commits intodotnet:mainfrom
jjonescz:fbp-pkg
Nov 18, 2025
Merged

Include file based program sources#81284
jjonescz merged 12 commits intodotnet:mainfrom
jjonescz:fbp-pkg

Conversation

@jjonescz
Copy link
Copy Markdown
Member

@jjonescz jjonescz commented Nov 16, 2025

See dotnet/dotnet#3244 (comment).
This should unblock our code flow to VMR.

@jjonescz jjonescz marked this pull request as ready for review November 17, 2025 15:11
@jjonescz jjonescz requested review from a team as code owners November 17, 2025 15:11
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be good to add some stronger indicator that these files are not meant to be modified directly. For example, placing in a Package/ or Generated/ subfolder, along with readme in the same or containing dir explaining what is being done in here, as well as perhaps instructions for how to update the sources.

var root = FindRepoRoot();
if (root == null)
{
output.WriteLine($"Could not locate repo root. Skipping test. Current directory: {Environment.CurrentDirectory}");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels reasonable to fail the test in this case

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would fail in Helix legs which pick it up but they cannot find the repo root as we don't copy over the whole repo to Helix.

/// because that would not work in source build (which requires roslyn to build before sdk).
/// </summary>
[Fact]
public void Match()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong opposition to doing this in the form of a test, but, it does feel to me more like a script like ./eng/generate-compiler-code.cs.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good to me, will try to convert this to a script, thanks.

Comment thread src/Features/CSharp/Portable/Microsoft.CodeAnalysis.CSharp.Features.csproj Outdated
Namespace="Microsoft.DotNet.FileBasedPrograms" />
</ItemGroup>
<ItemGroup>
<PackageDownload
Copy link
Copy Markdown
Member

@RikkiGibson RikkiGibson Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still used? Maybe it ensures that the package is actually restored so that the script can dig it out of the package cache?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, seemed like best place to put it, I can attach a comment.

@RikkiGibson
Copy link
Copy Markdown
Member

It would be good to comment at the place the package version is defined, what step to perform to update the in-repo sources.

Co-authored-by: Rikki Gibson <[email protected]>
@jjonescz
Copy link
Copy Markdown
Member Author

jjonescz commented Nov 18, 2025

It would be good to comment at the place the package version is defined, what step to perform to update the in-repo sources.

I'm not sure that's possible, the Version.Details.props is automatically regenerated by maestro on updates I believe.

But perhaps putting a comment at the PackageDownload (where the version is used) is enough?

@jjonescz jjonescz enabled auto-merge (squash) November 18, 2025 09:53
@jjonescz jjonescz merged commit e9cf142 into dotnet:main Nov 18, 2025
28 of 29 checks passed
@jjonescz jjonescz deleted the fbp-pkg branch November 18, 2025 11:10
@dotnet-policy-service dotnet-policy-service Bot added this to the Next milestone Nov 18, 2025
@jjonescz jjonescz added the Feature - Run File #: and #! directives and file-based C# programs label Dec 3, 2025
@davidwengier davidwengier modified the milestones: Next, 18.3 Jan 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-IDE Feature - Run File #: and #! directives and file-based C# programs VSCode

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants