Support dotnet pack file.cs
#50168
Support dotnet pack file.cs
#50168
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR implements support for dotnet pack file.cs to enable packing file-based programs directly from C# source files. The change allows users to create NuGet packages from standalone C# files without requiring a traditional project file structure.
Key changes:
- Modified the
PackCommandto detect and handle file-based programs using the virtual project building infrastructure - Updated command completion descriptions to include C# files as valid inputs
- Added test coverage for the new functionality
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/Cli/dotnet/Commands/Pack/PackCommand.cs | Refactored to use CommandFactory pattern and support file-based programs through VirtualProjectBuildingCommand |
| src/Cli/dotnet/Commands/Pack/PackCommandParser.cs | Updated argument name and description to include C# files as valid inputs |
| src/Cli/dotnet/Commands/Run/VirtualProjectBuildingCommand.cs | Added PackageOutputPath property and updated runtime config logic to exclude Pack target |
| test/dotnet.Tests/CommandTests/Run/RunFileTests.cs | Added comprehensive test for pack functionality and updated virtual project templates |
| test/dotnet.Tests/CommandTests/MSBuild/GivenDotnetPackInvocation.cs | Fixed cast to handle new return type from PackCommand.FromArgs |
| documentation/general/dotnet-run-file.md | Updated documentation to reflect pack support and clarify behavior |
| test/dotnet.Tests/CompletionTests/snapshots/zsh/DotnetCliSnapshotTests.VerifyCompletions.verified.zsh | Updated completion description to include C# files |
Comments suppressed due to low confidence (1)
There was a problem hiding this comment.
What's the end-to-end scenario for packing file based project?
My understanding is that file based apps are always console apps, is that right? If so, should they be packed as tools, rather than packed as class libraries?
Tools are installed and used with dotnet tool install, whereas class libraries can only be used by PackageReference or equivilent.
There was a problem hiding this comment.
Yes, tools are the likely scenario. But you could actually pack a library as well if you wanted; like:
#:property OutputType=Library
public class C;(you just couldn't dotnet run such file-based app)
| @@ -807,6 +807,7 @@ public static void WriteProjectFile( | |||
| <IncludeProjectNameInArtifactsPaths>false</IncludeProjectNameInArtifactsPaths> | |||
| <ArtifactsPath>{EscapeValue(artifactsPath)}</ArtifactsPath> | |||
| <PublishDir>artifacts/$(MSBuildProjectName)</PublishDir> | |||
| <PackageOutputPath>artifacts/$(MSBuildProjectName)</PackageOutputPath> | |||
There was a problem hiding this comment.
Do we have any tests where the user .cs overrides this?
Resolves #49369.