Closed AArnott closed 6 years ago
In studying the build logs using the MSBuild Structured Log Viewer (and the /bl
build switch) I found that the fault seems to lie with the GetPackagingOutputs
target. It seems this target is defined as empty at one point in the preprocessed project file, but later the AppX .targets are imported and define it to actually something that apparently isn't multitargeting aware and thus doesn't suppress the propagation of the TargetFramework
global property.
Since it seems that the GetPackagingOutputs
target is always supposed to be blank for .NET SDK projects, and seeing I don't have any AppX packaging in my solution, I applied the following workaround:
In my Directory.Build.targets file:
<!-- Workaround win8 .targets defining a target that should be blank (https://github.com/dotnet/sdk/issues/2517) -->
<Target Name="GetPackagingOutputs" />
Moving to MSBuild.Sdk.Extras because the .NET SDK doesn't even support the win8
target natively.
From @AArnott on September 6, 2018 15:0
From @AArnott on September 6, 2018 4:11
Details about Problem
NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):
msbuild.exe /restore
MSBuild version:
15.9.10.28431
dotnet.exe --version (if appropriate):
2.1.500-preview-009266
VS version (if appropriate):
15.9.0 preview 2.0 (28029.51.d15.9)
OS version (i.e. win10 v1607 (14393.321)):
17134.rs4_release.180410-1804
Worked before? If so, with which NuGet version: Not sure.
Detailed repro steps so we can see the same problem
Expected
A successful restore and build.
Actual
Restore emits no warnings. Build fails with:
Trying to build again (without another restore step) usually succeeds (but not always). Considering the error is allegedly generated from the Windows.Core.csproj and CodeGenerationAttributes.csproj projects, building them individually might presumably fail, but they don't. They only fail when in the context of the larger build.
I claim this is a nuget/msbuild failure because while it is true that the two mentioned projects do not define a win8 target, they shouldn't need to, since they include
netstandard1.1
as one of their targets, which per this table should work for any win8 targeted project that references these projects. Also since the failure is inconsistent (a second or third build attempt usually succeeds), it seems like some race condition perhaps during the multi-proc build. Or maybe incremental build is buggy and skips the previously failed build step.Copied from original issue: NuGet/Home#7277
Copied from original issue: dotnet/sdk#2517