Repository navigation
File-based apps: support legacy artifact behavior - #55970
Conversation
|
Azure Pipelines: Successfully started running 1 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
🔴 Build Failure AnalysisError: Failing leg: Windows x64 (and likely all other legs) Root cause: The PR added a new parameter The error: Fix: Update
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🤖 Automated content by GitHub Copilot. Generated by the Build Failure Analysis workflow. · 50.2 AIC · ⌖ 7.79 AIC · ⊞ 5.3K · ◷
|
Azure Pipelines: Successfully started running 1 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
This PR updates file-based app virtual project generation to preserve older (“legacy”) artifacts behavior when the MSBuild/SDK being used doesn’t recognize the newer file-based artifacts mechanism. This is intended to improve compatibility with external hosts (e.g., MSBuildWorkspace) that may not be running the same SDK/targets as the dotnet CLI.
Changes:
- Detect when artifacts props are imported but no artifacts layout was selected, and switch to a legacy artifacts-property emission path.
- Extend
VirtualProjectBuilder.WriteProjectFilewith a newuseLegacyArtifactsPathparameter and emit legacy artifacts-related properties when enabled. - Update
InternalAPI.Unshipped.txtto reflect the signature change.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/Cli/Microsoft.DotNet.FileBasedPrograms/VirtualProjectBuilder.cs | Adds legacy-artifacts detection/caching and a new project-file emission mode via useLegacyArtifactsPath. |
| src/Cli/Microsoft.DotNet.FileBasedPrograms/InternalAPI.Unshipped.txt | Updates tracked internal API signature for WriteProjectFile. |
|
@333fred @RikkiGibson for a review, thanks |
333fred
left a comment
333fred
left a comment
There was a problem hiding this comment.
Are there tests for this behavior somewhere?
|
This is checked on the roslyn side (without this, the CI of dotnet/roslyn#85065 would fail), but I will add explicit tests here too. |
|
@333fred for another look, thanks |
GitHub Actions
Failure
A file-based app - a single .cs file run with `dotnet run app.cs` - has no project file, so passing one to GetProject threw on XDocument.Load. Roslyn's MSBuildWorkspace opens these by generating the project in its build host, which is not open to us: expanding the file-level directives means evaluating the project being built up, repeatedly, against a real MSBuild, and the core library deliberately has no engine. `dotnet msbuild app.cs` is not an alternative either - only the SDK's own verbs route a .cs file through the virtual project, and `dotnet build app.cs` rejects the -l: the pipe logger needs. So ask the SDK for the project instead, over the same hidden `dotnet run-api` protocol IDEs use to see behind a file-based program, and build that. The project is parsed from the XML the SDK hands back, never from disk, so directives (#:package, #:sdk, #:property) come through evaluated and the whole IProjectFile surface behind them keeps working. MSBuild is handed a project path on the command line, though, so the project is written to the path the SDK would have used - next to the entry point file, which is what Directory.Build .props, nuget.config and global.json discovery walk up from - for the duration of each build and removed after, with concurrent per-framework builds sharing the one file. A project already sitting there is only replaced if it carries the SDK's FileBasedProgram marker, so an earlier crashed run's leftover is recoverable and a real project of the user's is never overwritten. Two version details are worth knowing. The generated project's path is the SDK's to choose (it became app.cs.csproj during .NET 10, when the response started reporting it), so it is read from the response and only guessed at the older convention when absent. And the artifacts properties it emits depend on the SDK that evaluates it (dotnet/sdk#55970), which is decided before any BuildEnvironment exists; generation therefore uses the default dotnet, a build pointed at another one is warned about, and a file-based app always builds against the .NET SDK rather than .NET Framework MSBuild. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
/backport to release/11.0.1xx |
|
Started backporting to |
Follow up on #55697.
Needed for MSBuildWorkspace, see dotnet/roslyn#85065.