…at the current project can be ignored properly (#7999)

Undeclared projects needs to be normalized and case insensitive (on windows) so that the current project can be ignored properly

As a part of dotnet/arcade#10123, we are moving all docker containers to the new tagging schema

Fixes #7943

Context
MSBuild detects the wrong processor count on Windows when debugging processor groups

Changes Made
Replaces GetLogicalProcessorInformationEx with GetActiveProcessorCount and removes an incorrect check for >32 processors which is incompatible with Windows boot parameters for debugging processor groups.

Testing
Manual testing

Fixes #5436

Context
Changes Made
There is a significant error in the original Constuctor ProjectItemDefinitionGroupElement(XmlElement xmlElement, ProjectRootElement parent, ProjectRootElement containingProject). The second parameter and third parameter types are the same. Fix the constructor bug and parse ItemDefinationGroup in when and otherwise.

Testing
Add one test SupportItemDefinationGroupInWhenOtherwise()

* Update dependencies from https://github.com/nuget/nuget.client build 6.4.0.90

NuGet.Build.Tasks
 From Version 6.4.0-preview.3.74 -> To Version 6.4.0-preview.3.90

* Update dependencies from https://github.com/nuget/nuget.client build 6.4.0.97

NuGet.Build.Tasks
 From Version 6.4.0-preview.3.74 -> To Version 6.4.0-preview.3.97

* Update dependencies from https://github.com/nuget/nuget.client build 6.4.0.100

NuGet.Build.Tasks
 From Version 6.4.0-preview.3.74 -> To Version 6.4.0-preview.3.100

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

Fixes #7828

Context
Binary logger option overrides verbosity by diagnostic and prints a line even verbosity is set to quiet.

Changes Made
The fix introduces a variable to store the original verbosity, if the "original verbosity" is quiet, it suppresses the console output when binary logger is requested.

Customer Impact
Slower arm64 MSBuild due to assemblies NOT being ngen'd for the arm64 architecture.

Testing
Verified no regressions in https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/426628

Code Reviewers
raines
Forgind

Description of fix
Change setting in our .swr file to ngen relevant assemblies as arm64.

Fixes #8008

Context
With the MSBuild server, I added support for VT100, which meant we could understand colorization and such from an older command prompt, but I also added DISABLE_NEWLINE_AUTO_RETURN, which made the UI look worse.

Customer Impact
Customers using MSBuild server and trying to print newlines (\n) will see output with extra space.

Testing
Manually tested the change: ran the proposed repro project and saw the bug. Overwrote the MSBuild in that SDK with custom bits from this PR and retested it, and I could no longer reproduce the issue. Tried using MSBuild.exe on a random project, and the important part of the VT100 change was preserved.

Code Reviewers
rokonec

Description of fix
Removed the DISABLE_NEWLINE_AUTO_RETURN argument

…er.LogErrorFromException() (#7998)

Fixes #7985

Context
TaskLoggingHelper.LogErrorFromException() does not currently take into account the relatively new AggregateException which has inner exceptions but an outer exception with very little details.

Changes Made
I've updated TaskLoggingHelper.LogErrorFromException() to check if the specified exception is an AggregateException and call the method again for each inner exception, respecting all of the arguments passed in around showing details or a stack trace.

Testing
A unit test was added

Notes
Unfortunately, I can't add the other improvement around an InvalidProjectFileException since TaskLoggingHelper is compiled into Microsoft.Build.Utilities.Core and that assembly does not reference Microsoft.Build.dll so it doesn't have access to the InvalidProjectFileException class 😢

…6.4.0.107 (#8037)

NuGet.Build.Tasks
 From Version 6.4.0-preview.3.100 -> To Version 6.4.0-preview.3.107

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…or. (#8024)

Fixes #7993

Summary
In the MSBuild server, we identify the state of the server via mutexes. Sometimes, for reason yet unknown to us, mutex could throw the exception System.IO.IOException: Connection timed out. When this occurs, we fallback to old behavior building without server. We fixed some of those in #8000, but now found more situations when this happens.

Customer Impact
MSBuild non-Windows users could have intermittent error when building with dotnet build.
This does not affect Visual Studio.

Regression?
Yes, this is a regression.

Testing
Unit tests.

Risk
Low risk. The fix adds additional try-catch blocks to process this situation.

Code Reviewers
[TODO]

Description of the fix
Add a try-catch block to catch and process the IOException exception when mutexes are used.
Add a new client exit type for this kind of error.