Fix early/unconditional execution of PackageFSharpDesignTimeTools target

[Copilot]

• Understand the current implementation in Microsoft.FSharp.NetSdk.targets
• Implement conditional inclusion of PackageFSharpDesignTimeTools in TargetsForTfmSpecificContentInPackage based on IsFSharpDesignTimeProvider property
• Change target header from DependsOnTargets="_GetFrameworkAssemblyReferences" to AfterTargets="ResolveReferences"
• Add conditional safety call inside the target to prevent early execution
• Test the changes to ensure they work correctly
• Add appropriate release notes
• Refine implementation to follow the implementation guide more closely
• Address all feedback comments and simplify implementation
• Add comprehensive end-to-end tests
• Implement equivalent functionality to T-Gro's requested syntax using MSBuild-compliant approach
• Integrate tests into CI EndToEndBuildTests job
• Fix duplicate TargetsForTfmSpecificContentInPackage entries
• Add issue repro test case for NETSDK1085 scenario
• Fix target scheduling by setting property at evaluation time
• Add back target-based reference checking as experiment
• Remove flawed Test 6 that didn't test our changes
• Improve test diagnostics with detailed error messages
• Add FSharpTestCompilerVersion parameter to all pack commands
• Fix double-import issue breaking F# SDK targets
• Simplify tests to match BasicProvider pattern
• Remove binlog target checking - validate via package contents only

Summary

Fixed the early/unconditional execution of the PackageFSharpDesignTimeTools target that was causing:

• Issue PackageFSharpDesignTimeTools target interacts unpredictably with the rest of the build. #18924: Early inclusion caused premature reference resolution → binding redirect + app.config deletion issues
• Issue NETSDK1085 when packing with --no-build #12320: dotnet pack --no-build could trigger unintended build target participation (NETSDK1085 risk)

Current Implementation (Experimental Hybrid Approach):

Dual-Phase Approach:

1. Evaluation-Time Property Check (for direct property):

<PropertyGroup Condition=" '$(IsFSharpDesignTimeProvider)' == 'true' ">
  <TargetsForTfmSpecificContentInPackage>$(TargetsForTfmSpecificContentInPackage);PackageFSharpDesignTimeTools</TargetsForTfmSpecificContentInPackage>
</PropertyGroup>

2. Execution-Time Reference Check (experimental):

<Target Name="_CheckForDesignTimeProviderReferences" BeforeTargets="GenerateNuspec;Pack" Condition=" '$(IsFSharpDesignTimeProvider)' != 'true' ">
  <!-- Checks ProjectReference/PackageReference and updates property -->
</Target>

Clean Target Structure:

• Changed from DependsOnTargets="_GetFrameworkAssemblyReferences" to AfterTargets="ResolveReferences"
• Added <CallTarget Targets="_GetFrameworkAssemblyReferences" Condition="'@(ReferencePath)' == ''" />

Simplified End-to-End Tests: Test suite validates via package contents only:

• Build with dotnet build
• Pack with dotnet pack --no-build
• Verify package contents (presence/absence of tools/fsharp41 folder)
• No binlog checking (unreliable with binary format)
• Tests require F# compiler to be built first (artifacts/bin/fsc)

Testing Verified:

• ✅ Plain projects: No tools folder in package
• ✅ Projects with IsFSharpDesignTimeProvider="true": tools/fsharp41 folder present in package
• ✅ Projects with references: Target checks references and updates property during execution
• ✅ All existing FSharp.Build unit tests pass (42/42)
• ✅ Tests validate actual package contents instead of binlog analysis
• ✅ Fixed double-import issue preventing F# SDK targets from loading

Experimental: The target-based reference checking approach tests MSBuild's behavior with execution-time property updates.

Note: Tests require the F# compiler to be built before running (EndToEndBuildTests job must build compiler first).

This pull request was created as a result of the following prompt from Copilot chat.

Fixes early / unconditional execution of the PackageFSharpDesignTimeTools target.

Related issues:

• PackageFSharpDesignTimeTools target interacts unpredictably with the rest of the build. #18924: Early inclusion caused premature reference resolution → binding redirect + app.config deletion issues.
• NETSDK1085 when packing with --no-build #12320: dotnet pack --no-build could trigger unintended build target participation (NETSDK1085 risk).

Changes:

1. Gate inclusion of PackageFSharpDesignTimeTools in $(TargetsForTfmSpecificContentInPackage) — using hybrid approach with both evaluation-time property check and experimental execution-time reference check.
2. Change target header from DependsOnTargets="_GetFrameworkAssemblyReferences" to AfterTargets="ResolveReferences".
3. Add conditional safety call inside the target: .

No change to actual packaging semantics for valid design-time providers.

Top test cases:

ID	Scenario	Expected
T1	Plain lib pack	Target absent; no tools/fsharp41 folder
T2	Provider project	Target runs after ResolveReferences; tools/fsharp41// content
T3	Provider via ProjectReference	Target runs; provider outputs included once
T4	pack --no-build (no provider)	Success; no NETSDK1085; target absent
T5	AutoGenerateBindingRedirects + no provider	Success; no MSB3030; target absent

Regression: run tests/EndToEndBuildTests/BasicProvider/TestBasicProvider.cmd — layout unchanged, tests pass.

Implementation includes experimental target-based reference checking to test MSBuild behavior with execution-time property updates.

This pull request was created as a result of the following prompt from Copilot chat.

Fixes early / unconditional execution of the PackageFSharpDesignTimeTools target.

Related issues:

• PackageFSharpDesignTimeTools target interacts unpredictably with the rest of the build. #18924: Early inclusion caused premature reference resolution → binding redirect + app.config deletion issues.
• NETSDK1085 when packing with --no-build #12320: dotnet pack --no-build could trigger unintended build target participation (NETSDK1085 risk).

Changes:

1. Gate inclusion of PackageFSharpDesignTimeTools in $(TargetsForTfmSpecificContentInPackage) — only when the project sets IsFSharpDesignTimeProvider="true".
2. Change target header from DependsOnTargets="_GetFrameworkAssemblyReferences" to AfterTargets="ResolveReferences".
3. Add conditional safety call inside the target: .

No change to actual packaging semantics for valid design-time providers.

Top test cases:

ID	Scenario	Expected
T1	Plain lib pack	Target absent; no tools/fsharp41 folder
T2	Provider project	Target runs after ResolveReferences; tools/fsharp41// content
T3	Provider via ProjectReference	Target runs; provider outputs included once
T4	pack --no-build (no provider)	Success; no NETSDK1085; target absent
T5	AutoGenerateBindingRedirects + no provider	Success; no MSB3030; target absent

Regression: run tests/EndToEndBuildTests/BasicProvider/TestBasicProvider.cmd — layout unchanged, tests pass.

Note: Checking ProjectReference/PackageReference metadata at evaluation time is not feasible due to MSBuild's evaluation order constraints. Only direct property check is supported.

This pull request was created as a result of the following prompt from Copilot chat.

Fixes early / unconditional execution of the PackageFSharpDesignTimeTools target.

Related issues:

• PackageFSharpDesignTimeTools target interacts unpredictably with the rest of the build. #18924: Early inclusion caused premature reference resolution → binding redirect + app.config deletion issues.
• NETSDK1085 when packing with --no-build #12320: dotnet pack --no-build could trigger unintended build target participation (NETSDK1085 risk).

Changes:

1. Gate inclusion of PackageFSharpDesignTimeTools in $(TargetsForTfmSpecificContentInPackage) — only when the project OR a direct ProjectReference/PackageReference sets IsFSharpDesignTimeProvider="true".
2. Change target header from DependsOnTargets="_GetFrameworkAssemblyReferences" to AfterTargets="ResolveReferences".
3. Add conditional safety call inside the target: .

No change to actual packaging semantics for valid design-time providers.

Top test cases:

ID	Scenario	Expected
T1	Plain lib pack	Target absent; no tools/fsharp41 folder
T2	Provider project	Target runs after ResolveReferences; tools/fsharp41// content
T3	Provider via ProjectReference	Target runs; provider outputs included once
T4	pack --no-build (no provider)	Success; no NETSDK1085; target absent
T5	AutoGenerateBindingRedirects + no provider	Success; no MSB3030; target absent

Regression: run tests/EndToEndBuildTests/BasicProvider/TestBasicProvider.cmd — layout unchanged, tests pass.

No commented-out code added. Transitives not (yet) considered—only direct references. Validation logic unchanged.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[github-actions]

✅ No release notes required

[Copilot]

@copilot :

Time Elapsed 00:00:04.24
...

Fixed in commit (pending). Removed unreliable binlog checking with findstr/strings on binary files. Tests now only validate package contents - checking for presence/absence of tools/fsharp41 folder which directly shows whether the target ran.

[baronfel]

Generally direct usage of CallTarget is not ideal - if you need to express a data-dependency then that should be done via DependsOnTargets. Why does this call need to happen, does ResolveReferences not implicitly do _GetFrameworkAssemblyReferences?

[T-Gro]

That was for the scenario of calling pack --no-build with a TP, its mainly a safety net just in case _GetFrameworkAssemblyReferences was not executed.

(also, since its underscored, I/Copilot assumed it is "private" and that we should not depend on any current behavior and/or ordering)

[T-Gro]

But it might be superfluous.
The main motivation was to get rid of DependsOnTargets which was causing a bug (dragging this target in when not needed), and make sure it is really only executed when needed.

[Copilot]

Pull Request Overview

This PR fixes the early/unconditional execution of the PackageFSharpDesignTimeTools target that was causing build issues, specifically NETSDK1085 errors and binding redirect problems. The fix implements a hybrid approach: (1) gating the target's inclusion in TargetsForTfmSpecificContentInPackage based on the IsFSharpDesignTimeProvider property at evaluation time, and (2) adding an experimental execution-time check for references with design-time provider metadata.

Key Changes:

• Modified target scheduling from DependsOnTargets to AfterTargets with conditional safety call
• Added evaluation-time property check to conditionally include the packaging target
• Added experimental execution-time target to check references for design-time provider metadata
• Created comprehensive end-to-end tests validating package contents

Reviewed Changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/FSharp.Build/Microsoft.FSharp.NetSdk.targets	Core fix: conditional target inclusion and modified scheduling
tests/EndToEndBuildTests/EndToEndBuildTests.cmd	Integrated new test suite into CI
tests/EndToEndBuildTests/Directory.Build.props	Removed duplicate import causing double-import issue
tests/EndToEndBuildTests/DesignTimeProviderPackaging/TestDesignTimeProviderPackaging.cmd	Windows test script validating 5 scenarios
tests/EndToEndBuildTests/DesignTimeProviderPackaging/TestDesignTimeProviderPackaging.sh	Unix test script validating 5 scenarios
tests/EndToEndBuildTests/DesignTimeProviderPackaging/PlainLib/*	Test project: plain library without provider flag
tests/EndToEndBuildTests/DesignTimeProviderPackaging/Provider/*	Test project: library with IsFSharpDesignTimeProvider=true
tests/EndToEndBuildTests/DesignTimeProviderPackaging/Host/*	Test project: library with ProjectReference to provider
tests/EndToEndBuildTests/DesignTimeProviderPackaging/RedirectLib/*	Test project: library with AutoGenerateBindingRedirects
docs/release-notes/.FSharp.Compiler.Service/10.0.100.md	Added release note entry
azure-pipelines-PR.yml	Added SDK installation step for EndToEndBuildTests

[T-Gro]

@teo-tsirpanis :

This tests the tests/EndToEndBuildTests/DesignTimeProviderPackaging/RedirectLib/RedirectLib.fsproj project based on your issue report.

Could you please let me know if you have any additional thoughts on testing, before we merge this in?