Remove feature flag for transitive #: directives#54012
Conversation
There was a problem hiding this comment.
Pull request overview
Removes the feature-flag gating for processing transitive file-level #: directives in file-based programs, aligning implementation, tests, and docs with the new default behavior.
Changes:
- Stop checking
ExperimentalFileBasedProgramEnableTransitiveDirectiveswhen validating directives (transitive directives always allowed). - Update
dotnet run filetests to no longer set the transitive-directives flag and remove the flag-specific test. - Remove the flag constant from the FileBasedPrograms internal API surface and update documentation accordingly.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| test/dotnet.Tests/CommandTests/Run/RunFileTests.cs | Removes transitive-directive flag setup and deletes the test that asserted the flag gating behavior. |
| src/Microsoft.DotNet.ProjectTools/VirtualProjectBuilder.cs | Removes the runtime check that required the transitive-directives flag for non-entry-point directives. |
| src/Cli/Microsoft.DotNet.FileBasedPrograms/InternalAPI.Unshipped.txt | Drops the internal API entry for the removed flag constant. |
| src/Cli/Microsoft.DotNet.FileBasedPrograms/FileLevelDirectiveHelpers.cs | Removes the transitive-directives flag constant from CSharpDirective.IncludeOrExclude. |
| documentation/general/dotnet-run-file.md | Removes documentation that stated transitive directives were gated behind a feature flag. |
|
Are we going to get this into 10.0.300 as well? |
|
IIRC, code complete of 10.0.3xx was yesterday. Also the IDE integration is probably not even released yet. |
|
We should check on the code complete status and if there's a process for getting changes in still. On the IDE side they release far more often and the experience in the insiders and pre-release versions is already good and we can do follow ups to tweak the experience as needed. Is the opt-in flag for transitive directives removed for .NET 11 already? |
No, but this PR will flow there once merged. |
|
/backport to release/10.0.3xx |
|
Started backporting to |
Two scripting ergonomics improvements that show up across every
Cadenza SDK variant.
`Env.ScriptPath` / `Env.ScriptDirectory` (src/core/Env.cs)
Read the entry .cs file's absolute path from inside the running
program. Backed by `AppContext.GetData("EntryPointFilePath")` /
`EntryPointFileDirectoryPath`, which the .NET 10 file-based CLI
injects as `RuntimeHostConfigurationOption` items on every
`dotnet run`/`dotnet build`. Both return null after
`dotnet publish` (the CLI strips those entries when the binary
is no longer the script) — documented in the doc comments and
the skill's gotcha list.
`ExperimentalFileBasedProgramEnableTransitiveDirectives=true`
Defaulted in all five Sdk.props (Cadenza, Cadenza.Worker,
Cadenza.Web, Cadenza.Mcp, Cadenza.Agent). Without this, a
`#:package` / `#:property` / nested `#:include` inside an
`#:include`d helper file is silently dropped by the directive
preprocessor — verified empirically before shipping by
reproducing the failure with a vanilla SDK and the success once
the property lands in Sdk.props. The flag is read AFTER our
Sdk.props is imported into the synthesized csproj, so it works
from there despite the directive parsing happening pre-MSBuild.
Slated for removal once PR dotnet/sdk#54012 (transitive
directives always-on) reaches the released SDK.
Family bump 1.0.14 -> 1.0.15.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow up on #53775 (comment).