search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.24k stars 1.35k forks source link

[Bug]: Net472 Service Fabric project with .Net 8 project reference broken in latest msbuild #10290

Closed johnthcall closed 5 months ago

johnthcall commented 5 months ago

Issue Description

With the latest visuals studio update and the latest accompanying msbuild our Azure service fabric packaing has started to fail with the following error: "E:\One\Mgmt\Governance\Notifications\src\Notifications\Notifications\Notifications.sfproj" (Restore target) (1) -> (Restore target) -> D:\msbuild\17.10.0-dev-24324-01+c6bee852d\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(169,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: E:\One\Mgmt\Governance\Notifications\src\Notifications\Notifications\Notifications.sfproj.

I have checked out this repo and binary searched the commits to find where the issue appears. Strangely the first commit to fail is #9722 c6bee85 and the PR before it #9644 a4ecab3 successfully builds. Attached are the two binary logs for successful and failed build with msbuild created from these commits. binlog.zip

Steps to Reproduce

msbuild src\Notifications\Notifications /t:Package /p:BuildProjectReferences=false /p:Configuration="Release"

Service fabric projects (.sfproj) are .Net 472 and we have package.config file along with project references to csproj which are using central package reference and are .Net 8 runtime.

Happy to work with MSFT employees to share internal setup.

Expected Behavior

Build succeeds and service fabric is properly packaged.

Actual Behavior

Msbuild gets to project restore phase and fails to restore for the sfproj file which is packageconfig restoration.

Analysis

I diffed the detailed logs of the two builds and it appears that this service fabric project switched it's restore project style of PackagesConfig to PackageReference.

Versions & Configurations

No response

rainersigwald commented 5 months ago

Spoke to @johnthcall briefly offline. GitHub's linearized repo history puts those commits together but by commit parent order they're pretty far apart, so that commit had more content. Next actions are to try to narrow it down further (maybe with formal git bisect). I suspect a NuGet change.

johnthcall commented 5 months ago

Root cause of the issue is NuGet/NuGet.Client#3276. After explicitly setting ManagePackageVersionsCentrally to false for service fabric projects it was able to build successfully.