Open iwillspeak opened 3 years ago
This seems to be down to the _GetTfmSpecificContentForPackage
target. An example build output when C# projects are buitl dotnet pack --no-build sea.csproj
:
Build started 31/10/2021 08:02:27.
1>Project "/<snip>/sea.csproj" on node 1 (pack target(s)).
1>GenerateNuspec:
Successfully created package '/<snip>/sea/bin/Debug/sea.1.0.0.nupkg'.
1>Done Building Project "/<snip>/sea/sea.csproj" (pack target(s)).
An example with the two F# projects dotnet pack --no-build Gee.fsproj
:
Build started 31/10/2021 07:58:30.
1>Project "/<snip>/Gee.fsproj" on node 1 (pack target(s)).
1>Project "/<snip>/Gee.fsproj" (1) is building "/<snip>/Gee.fsproj" (1:3) on node 1 (_GetTfmSpecificContentForPackage target(s)).
1:3>Project "/<snip>/Gee.fsproj" (1:3) is building "/<snip>/Eff.fsproj" (2:2) on node 1 (default targets).
2>/usr/lib64/dotnet/sdk/5.0.206/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(146,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked. [/<snip>/Eff.fsproj]
2>Done Building Project "/<snip>/Eff.fsproj" (default targets) -- FAILED.
1>Done Building Project "/<snip>/Gee.fsproj" (_GetTfmSpecificContentForPackage target(s)) -- FAILED.
1>Done Building Project "/<snip>/Gee.fsproj" (pack target(s)) -- FAILED.
Build FAILED.
"/<snip>/Gee.fsproj" (pack target) (1) ->
"/<snip>/Gee.fsproj" (_GetTfmSpecificContentForPackage target) (1:3) ->
"/<snip>/Eff.fsproj" (default target) (2:2) ->
(_CheckForBuildWithNoBuild target) ->
/usr/lib64/dotnet/sdk/5.0.206/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(146,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked. [/<snip>/Eff.fsproj]
0 Warning(s)
In both cases all projects had already been built.
Confirming this same issue for C# and a csproj file that references another project via project reference. I am running this with .NET 6.0 SDK in Azure DevOps using a DotNetCoreCLI@2 task and noticed the same behavior. Removing nobuild: true
from the inputs will work around the issue. The error from the log looks like the following
2:5>Done building target "ValidateCommandLineProperties" in project "XXX.XXX.csproj".
2:5>Target "BeforeBuild" in file "/opt/hostedtoolcache/dotnet/sdk/6.0.101/Microsoft.Common.CurrentVersion.targets" from project "/home/vsts/work/1/s/Utilities/XXX.XXX/XXX.XXX.csproj" (target "Build" depends on it):
2:5>Done building target "BeforeBuild" in project "XXX.XXX.csproj".
2:5>Target "_CheckForBuildWithNoBuild" in file "/opt/hostedtoolcache/dotnet/sdk/6.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets" from project "/home/vsts/work/1/s/Utilities/XXX.XXX/XXX.XXX.csproj" (target "CoreBuild" depends on it):
Using "NETSdkError" task from assembly "/opt/hostedtoolcache/dotnet/sdk/6.0.101/Sdks/Microsoft.NET.Sdk/targets/../tools/net6.0/Microsoft.NET.Build.Tasks.dll".
Task "NETSdkError"
2:5>/opt/hostedtoolcache/dotnet/sdk/6.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(136,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked. [/home/vsts/work/1/s/Utilities/XXX.XXX/XXX.XXX.csproj]
Done executing task "NETSdkError" -- FAILED.
2:5>Done building target "_CheckForBuildWithNoBuild" in project "XXX.XXX.csproj" -- FAILED.
@iwillspeak @scottrudy Is this F# specific?
@dsyme As I mentioned in my post on Jan 5, it also happens with C# projects.
The error I was seeing I couldn’t reproduce with just c# projects.
To confirm I can reproduce this bug still with the .NET 6.0.102 SDK:
For F#
dotnet new classlib --language F# --name eff -o eff
dotnet new classlib --language F# --name gee -o gee
dotnet add gee/gee.fsproj reference eff/eff.fsproj
dotnet build gee/gee.fsproj && dotnet pack gee/gee.fsproj --no-build
Produces the error:
/usr/lib64/dotnet/sdk/6.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(136,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked. [/home/will/Repositories/temple/eff/eff.fsproj]
For C#
dotnet new classlib --language C# --name cee -o cee
dotnet new classlib --language C# --name dee -o dee
dotnet add dee/dee.csproj reference cee/cee.csproj
dotnet build dee/dee.csproj && dotnet pack dee/dee.csproj --no-build
Succeeds with the logging
Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Successfully created package '/home/will/Repositories/temple/dee/bin/Debug/dee.1.0.0.nupkg'.
It seems to be down to MSBUILD's decision to build the dependant .fsproj
, which doesn't happen for the .csproj
:
F#:
$ dotnet pack gee/ --no-build -v=n
Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 05/03/2022 09:42:58.
1>Project "/home/will/Repositories/temple/gee/gee.fsproj" on node 1 (pack target(s)).
1>Project "/home/will/Repositories/temple/gee/gee.fsproj" (1) is building "/home/will/Repositories/temple/gee/gee.fsproj" (1:3) on node 1 (_GetTfmSpecificContentForPackage target(s)).
1:3>Project "/home/will/Repositories/temple/gee/gee.fsproj" (1:3) is building "/home/will/Repositories/temple/eff/eff.fsproj" (2:2) on node 1 (default targets).
2>/usr/lib64/dotnet/sdk/6.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(136,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked. [/home/will/Repositories/temple/eff/eff.fsproj]
2>Done Building Project "/home/will/Repositories/temple/eff/eff.fsproj" (default targets) -- FAILED.
1>Done Building Project "/home/will/Repositories/temple/gee/gee.fsproj" (_GetTfmSpecificContentForPackage target(s)) -- FAILED.
1>Done Building Project "/home/will/Repositories/temple/gee/gee.fsproj" (pack target(s)) -- FAILED.
Build FAILED.
"/home/will/Repositories/temple/gee/gee.fsproj" (pack target) (1) ->
"/home/will/Repositories/temple/gee/gee.fsproj" (_GetTfmSpecificContentForPackage target) (1:3) ->
"/home/will/Repositories/temple/eff/eff.fsproj" (default target) (2:2) ->
(_CheckForBuildWithNoBuild target) ->
/usr/lib64/dotnet/sdk/6.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(136,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked. [/home/will/Repositories/temple/eff/eff.fsproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.54
C#:
$ dotnet pack dee/ --no-build -v=n
Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 05/03/2022 09:44:30.
1>Project "/home/will/Repositories/temple/dee/dee.csproj" on node 1 (pack target(s)).
1>GenerateNuspec:
Successfully created package '/home/will/Repositories/temple/dee/bin/Debug/dee.1.0.0.nupkg'.
1>Done Building Project "/home/will/Repositories/temple/dee/dee.csproj" (pack target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.72
I'm pretty confident this seems to be down to the _GetTfmSpecificContentForPackage
target. Here's the logs from running that target only, after building both projects:
A lot more seems to go on in the F# build, and eventually the build target from the project refernece dependencies gets triggered which causes the erorr. I don't know enough about MSBuild to know what is and isn't significant here.
I see that F# has this target that is run as part of pack: https://github.com/dotnet/fsharp/blob/0b5b001e522dd7fe77597b04a5c873b5b0f56878/src/fsharp/FSharp.Build/Microsoft.FSharp.NetSdk.targets#L72-L99
which depends on _GetFrameworkAssemblyReferences
which then triggers ResolveReferences
.
I've found that I can trigger the same behaviour with C# projects if I include the following targets in a Directory.Build.targets
file:
<Project>
<PropertyGroup>
<TargetsForTfmSpecificContentInPackage>$(TargetsForTfmSpecificContentInPackage);BugTestTarget</TargetsForTfmSpecificContentInPackage>
</PropertyGroup>
<Target Name="BugTestTarget" DependsOnTargets="_GetFrameworkAssemblyReferences">
<Message Text="Hello world" />
</Target>
</Project>
This causes the same error:
/usr/lib64/dotnet/sdk/6.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(136,5): error NETSDK1085: The 'NoBuild' property was set to true but the 'Build' target was invoked. [/<snip>/cee.csproj]
Which seems to indicate it is that it is this transitive dependency on the _GetFrameworkAssemblyReferences
target that is causing the error.
I was able to work around the issue by adding /p:TargetsForTfmSpecificContentInPackage=
to the build command to prevent PackageFSharpDesignTimeTools
from being run. The package seems to contain the same as if dotnet pack
is run without --no-build
.
Thanks for the detailed info, that makes sense.
I'm also running in to this issue. It prevents being able to package F# projects using Nix dotnet support.
A proposed fix might be to add a Condition to the PackageFSharpDesignTimeTools
target that is driven by a boolean property, and default that property to false
. Then, in documentation for Type Provider authors tell them to set the property to true
. That way the majority of projects do not incur this hit and could continue along their merry way, and TP authors have a simple, unified way to signal inclusion.
This is still happening with 7.0.201
SDK
@KevinRansom any ideas what can we do in FSharp.Build to prevent this?
Above workaround by @iwillspeak worked for me
The workaround worked for me too. It still happens in .NET 8.
Is there any plan to remedy this?
The workaround worked for me too. It still happens in .NET 8.
Is there any plan to remedy this?
Sure, hovewer not as urgent as some other work on the plate.
When packing an F# project that depends on another project via
ProjectReference
a spuriousBuild
is triggered on the base project. This triggers the SDK errorNETSDK1085
. It doesn't seem to matter if the project being referenced is an.fsproj
or.csproj
. In both cases the preojct being referenced will be re-built and trigger the error. Executables being packed as tools don't seem to trigger this behaviour.Expected behavior
The project should produce a NuGet package with no errors
Actual behavior
The error
NETSDK1085
is reported:Known workarounds
Don't provide the
--no-build
flag when packing.Related information