After updating to the .NET 10 SDK, I encountered build errors when packing a .NET tool written in F#, that sets AutoGeneratedBindingRedirects to true (because the MSBuild locator sets it).
Repro steps
dotnet pack the following project:
<ProjectSdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net10.0</TargetFramework>
<PackAsTool>true</PackAsTool>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>
<ItemGroup>
<CompileInclude="Program.fs" />
</ItemGroup>
</Project>
Expected behavior
The project packs successfully.
Actual behavior
Packing fails with:
PS C:\Users\teo\code\ephemeral\app-config-repro> dotnet pack .\app-config-repro.fsproj
Restore complete (0,5s)
info NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
app-config-repro net10.0 failed with 1 error(s) (0,2s) → bin\Release\net10.0\app-config-repro.dll
C:\Program Files\dotnet\sdk\10.0.100-rc.1.25451.107\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(371,5): error MSB3030: Could not copy the file "obj\Release\net10.0\app-config-repro.dll.config" because it was not found.
app-config-repro failed (2,9s) → bin\Release\net10.0\app-config-repro.dll
Build failed with 1 error(s) in 4,1s
Known workarounds
Adding an explicit <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects> in my project solved the immediate cause of the errors.
Related information
I'm using .NET 10 RC 1 SDK on Windows. I validated that this does not reproduce if I use C#, or the .NET 9 SDK. It also reproduces regardless of the project's target framework.
Analysis
After inspecting the binlogs, I found that the cause of the issue is the PackageFSharpDesignTimeTools target.
| <TargetName="PackageFSharpDesignTimeTools"DependsOnTargets="_GetFrameworkAssemblyReferences"> |
Because this target is set in TargetsForTfmSpecificContentInPackage, building the project with the _GetTfmSpecificContentForPackage target, causes this target to run too early, which causes ResolveReferences to run too early, before BuildOnlySettings sets $(BuildingProject) to true, which causes ResolveAssemblyReference to skip finding dependencies, which causes RAR to output no suggested binding redirects, which causes the GenerateBindingRedirects target to not run, which messes up @(FileWrites), which causes the IncrementalClean target to delete the .app.config file previously created by the main project build, which causes to the error observed.
While the scenario observed is niche and unsupported, there is arguably something to be fixed here; this inconsistency in target run order might cause more mysterious issues like this to appear. I am thinking of another way to support easily packing type providers that plays better with MSBuild, which might or might not require a breaking change to the activation gesture. Not many projects are using IsFSharpDesignTimeProvider BTW.
After updating to the .NET 10 SDK, I encountered build errors when packing a .NET tool written in F#, that sets
AutoGeneratedBindingRedirectsto true (because the MSBuild locator sets it).Repro steps
dotnet packthe following project:Expected behavior
The project packs successfully.
Actual behavior
Packing fails with:
Known workarounds
Adding an explicit
<AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>in my project solved the immediate cause of the errors.Related information
I'm using .NET 10 RC 1 SDK on Windows. I validated that this does not reproduce if I use C#, or the .NET 9 SDK. It also reproduces regardless of the project's target framework.
Analysis
After inspecting the binlogs, I found that the cause of the issue is the
PackageFSharpDesignTimeToolstarget.fsharp/src/FSharp.Build/Microsoft.FSharp.NetSdk.targets
Line 68 in 984837b
Because this target is set in
TargetsForTfmSpecificContentInPackage, building the project with the_GetTfmSpecificContentForPackagetarget, causes this target to run too early, which causesResolveReferencesto run too early, beforeBuildOnlySettingssets$(BuildingProject)to true, which causesResolveAssemblyReferenceto skip finding dependencies, which causes RAR to output no suggested binding redirects, which causes theGenerateBindingRedirectstarget to not run, which messes up@(FileWrites), which causes theIncrementalCleantarget to delete the.app.configfile previously created by the main project build, which causes to the error observed.While the scenario observed is niche and unsupported, there is arguably something to be fixed here; this inconsistency in target run order might cause more mysterious issues like this to appear. I am thinking of another way to support easily packing type providers that plays better with MSBuild, which might or might not require a breaking change to the activation gesture. Not many projects are using
IsFSharpDesignTimeProviderBTW.