Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dilandau2001 opened this issue Sep 30, 2024 · 4 comments
Assignees
Labels
author-responded Author responded, needs response from dev team. bug

Comments

@dilandau2001
Copy link

dilandau2001 commented Sep 30, 2024

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

@dilandau2001
Copy link
Author

Any news?.
I guess it is easy to reproduce in your side, but if you don't I can try to prepare a full solution to test it.
Basically our issue is with events ProjectFinished and ProjectStarted that are fired way more times than with former versions, and with different parameters.
Specially the "Items" property which in current version is always empty and previously it could contain the whole list of projects to be build.

@GangWang01
Copy link
Member

@dilandau2001 can you provide the minimum sample that reproduces the issue? It will be very helpful to understand and investigate the issue.

@GangWang01 GangWang01 added the needs-more-info Issues that need more info to continue investigation. label Feb 25, 2025
@dilandau2001
Copy link
Author

Hi, I am no longer related to that project.
What I can say is that we had to stop using build tasks.
Instead what we did, was to call msbuild.exe inside a hidden console, capture console outputs and parse them to our needs.

@dotnet-policy-service dotnet-policy-service bot added author-responded Author responded, needs response from dev team. and removed triaged needs-more-info Issues that need more info to continue investigation. labels Mar 8, 2025
@dilandau2001
Copy link
Author

Although not really resolved I am no longer specially interested in the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author-responded Author responded, needs response from dev team. bug
Projects
None yet
Development

No branches or pull requests

4 participants