[Bug]: Logger missing information after upgrading Microsoft.Build tasks version

Issue Description

We are upgrading a tool that is compiling our application using MsBuild tasks. It was previously doing it using versions 15.x Now we are moving to the most recent version up to now which is currently version 17.11.4 because we want to upgrade our build system to VS2022. We have tried to use Microsoft.Build.Locator but we were unable to fix several errors of the type:

MSB4127 : The "GetReferenceNearestTargetFrameworkTask" task could not be instantiated from the assembly "C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'NuGet.Build.Tasks.GetReferenceNearestTargetFrameworkTask' to type 'Microsoft.Build.Framework.ITask'

So we are now trying deploying all dependencies within the compiler itself with the following package reference:

    <PackageReference Include="Microsoft.Build" Version="17.11.4" />
    <PackageReference Include="Microsoft.Build.Utilities.Core" Version="17.11.4" />
    <PackageReference Include="Microsoft.Build.Tasks.Core" Version="17.11.4" />
    <PackageReference Include="NuGet.Build.Tasks" Version="6.11.0" />

This is the closest we can get to have the application actually compiling our project. With those nuget packages the compiler is able to compile the solutions, but we have noticed some changes at logging level. Also it takes 10% more time to do it that former tool.

In our former version, in the IEventSource.ProjectStarted event we had 2 expectations:

When TargetNames == "Build", the attribe Items would be storing all the csproj projects associated to the sln that were going to be compiled" related to the build configuration. In current version the Items property is always null.

In former version, for a sln file with 50 projects, we were expecting 51 project started events and 51 project finish events. First event corresponded to the Target build event, related to the sln file. Other events related each one to a csproj file. In current version both events, either ProjectStarted and ProjectFinished is being fired a whole lot more times, all of them logging the same information. For example, for a sln file with only 50 projects, the event ProjectFinished with the trace "Done building project "XXXX.csproj" is being writen like 28 times.

Steps to Reproduce

Sorry I cannot provide any repro step, it is like a regression or I have missed some breaking change release notes. Actually, if this is how it is the expected behaviour right now, what I would like to know is how to gather the previous logging information with current version. We were using the expected information to log in which order projects were compiled and to trace how long it took to build each one. So my questions are (if this is the current expected behaviour) How do I know all projects that are going to be compiled. How do I know how long it takes to build every single project.

If you still require a zipped project it is going to take sometime to generate it.

Expected Behavior

When eventSource.ProjectStarted, at ProjectStartedEventArgs, when e.TargetNames == "Build", then e.Items should have the list of all projects that are going to be compiled

Events ProjectStarted and ProjectFinished should fire once per project in the solution.

Actual Behavior

ProjectStartedEventArgs.Items is always null

ProjectStarted and ProjectFinish is firing more than once per project in the solution.

Analysis

No response

Versions & Configurations

MSBuild version 17.9.5+33de0b227 for .NET Framework 17.9.5.7608

dotnet / msbuild