You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
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.
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.
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:
So we are now trying deploying all dependencies within the compiler itself with the following package reference:
`
`
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:
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
The text was updated successfully, but these errors were encountered: