RoslynTools.MSBuild 17.7.2 caused two CG alerts when doing signing validation. dotnet/arcade#14055 and its linked PRs have more context.

Fixes policheck:Error

Changes Made

Skip the non en-us locale resource files.
Skip the file that contains the specified entity names in the deprecated folder
Change country to country/region based on https://policheck.microsoft.com/Pages/TermInfo.aspx?LCID=9&TermID=79570

Testing
Test with MSBuild pipeline build https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=8509007&view=logs&j=7d9eef18-6720-5c1f-4d30-89d7b76728e9&t=c5a86041-9185-53e8-42a2-1cadc4486f0d&l=5251. There are no active results now.

* Mention unification in RAR found-conflicts message

Consider a message like

```
warning MSB3277: Found conflicts between different versions of "System.Runtime.InteropServices.RuntimeInformation" that could not be resolved.
    There was a conflict between "System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
    "System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not.
    References which depend on "System.Runtime.InteropServices.RuntimeInformation, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [C:\VisualStudio\VS17PrevPublic\Common7\IDE\PublicAssemblies\System.Runtime.InteropServices.RuntimeInformation.dll].
        C:\VisualStudio\VS17PrevPublic\Common7\IDE\PublicAssemblies\System.Runtime.InteropServices.RuntimeInformation.dll
            Project file item includes which caused reference "C:\VisualStudio\VS17PrevPublic\Common7\IDE\PublicAssemblies\System.Runtime.InteropServices.RuntimeInformation.dll".
                System.Runtime.InteropServices.RuntimeInformation
    References which depend on "System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [].
        C:\Users\user\.nuget\packages\azure.core\1.25.0\lib\net461\Azure.Core.dll
            Project file item includes which caused reference "C:\Users\user\.nuget\packages\azure.core\1.25.0\lib\net461\Azure.Core.dll".
                C:\Users\user\.nuget\packages\azure.core\1.25.0\lib\net461\Azure.Core.dll
                C:\Users\user\.nuget\packages\azure.identity\1.8.0\lib\netstandard2.0\Azure.Identity.dll
                C:\Users\user\.nuget\packages\azure.security.keyvault.secrets\4.4.0\lib\netstandard2.0\Azure.Security.KeyVault.Secrets.dll
                C:\Users\user\.nuget\packages\nuget.services.keyvault\2.111.0\lib\net472\NuGet.Services.KeyVault.dll
                C:\Users\user\.nuget\packages\nuget.services.configuration\2.111.0\lib\net472\NuGet.Services.Configuration.dll
```

What the message _means_ is that the first reference is the winner, and
what was chosen there will require unification for all the other
assemblies listed in the second part of the message. But what it says is
that the list of assemblies in the second part of the message depend on
the second version, which is not necessarily true--in fact, that's the
list of  references that _can be unified_ to that version.

This isn't a full fix for #4757 but hopefully makes the message a bit
less misleading.

* Update tests

* fixup! Update tests

* Correct success

This is not yet a problem but only because neither /preprocess nor /targets are supported for solution files.

The root of the problem is if someone chooses to specify both /preprocess and /targets. If /preprocess fails but /targets succeeds, it currently will erroneously display success. This fixes that.

As I said, that scenario doesn't currently exist but only because /targets cannot succeed unless /preprocess succeeded, but that is not guaranteed going forward. Notably, if /preprocess is extended to support solution files before /targets is, this will become an issue.

* Make isTargets not run if !success

---------

Co-authored-by: Forgind <Forgind@users.noreply.github.com>

Fixes #7330
(plus one subtask of #8329)

Changes Made
Based on Add ability to create temp mapped drive for integration tests #8366 fixes to enable other Drive enumeration integration tests with a dummy folder in windows
Remove one test data https://github.com/dotnet/msbuild/blob/fecef0fdffe59ba8b0251701a23be48bbd552726/src/Build.OM.UnitTests/Instance/ProjectItemInstance_Tests.cs#L1010-L1012C45 since there is no warning when inlude is not null and exclude with enumerating wildcards. The related logical code is
msbuild/src/Build/Utilities/EngineFileUtilities.cs

Line 339 in fecef0f

 private static void LogDriveEnumerationWarningWithTargetLoggingContext(TargetLoggingContext targetLoggingContext, IElementLocation includeLocation, IElementLocation excludeLocation, bool excludeFileSpecIsEmpty, bool disableExcludeDriveEnumerationWarning, string fileSpec) 
. There is no condition satisfied.
Associate unix Enumeration Tests long time run with issue Unix drive enumeration imports not expanded? #8373

Preliminary design proposal for the Packages Sourcing feature

Fixes #8762

Context
Catch the exceptions when extensionsPathPropValue is null or importExpandedWithDefaultPath is empty.
In NET Framework, Path.* function also throws exceptions if the path contains invalid characters

Changes Made
Catch the exception.

Testing
FallbackImportWithInvalidProjectValue

Notes

.NET (Core) stuff is implied by ManagedDesktop now, and we require only
"some .NET Framework SDK", so no need to specify explicitly as one will
be delivered by ManagedDesktop.

We do still target .NET Framework 3.5, though . . .

…004.4 (#9314)

Microsoft.Net.Compilers.Toolset
 From Version 4.8.0-3.23501.1 -> To Version 4.8.0-3.23504.4

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

…ngTargetExceptions (#9253)

Fixes #9245

Context
The test was disabled to unblock PR CI.

Changes Made
Increased the relevant timeout.

Testing
The test is reliably passing now.

Notes
This turned out to be an issue with the sleep command we use on Windows. In some cases PowerShell can take a super long time to start. I have been able to reproduce locally by enabling Fusion logging. Thread times of the powershell process:

image

We spend almost 10 seconds just loading assemblies, so the timeout of 10 seconds for the entire build was not enough.

I don't have a full understanding of the mechanism that slows down PowerShell this much. At this point I'm happy we were able to confirm it's not a product issue, although I'm wondering if there is a better and more light-weight sleep command we could use on Windows instead (e.g. ping 127.0.0.1 -n <seconds>). Reviewers please opine.

EDIT: In my trace, file system operations block extensively with wdfilter.sys on the stack, so the likely explanation for the issue appearing all of a sudden is a Defender update.

Context
The ExcludeFromStyleCop is not effective anymore. Even if it was, it's not clear why we would want to exclude so many files from style checks.

Changes Made
Deleted all occurrences of <ExcludeFromStyleCop>true</ExcludeFromStyleCop> from project files.

Testing
Build (CLI and VS).

Added IDE0305 to `.editorconfig` as a suggestion.

…9309)

Context
We need to add an extra job to .exp-insertions.yml pipeline for creating experimental Framework MSBuild.

Changes Made
Pipeline refactored, a job added
Fixed bug in deploy script code path for Framework MSBuild
Testing
Manual run of the pipeline

…: Build ID 8527872 (#9316)

* Localized file check-in by OneLocBuild Task: Build definition ID 9434: Build ID 8509770

* Localized file check-in by OneLocBuild Task: Build definition ID 9434: Build ID 8514818

…010.8 (#9333)

Microsoft.Net.Compilers.Toolset
 From Version 4.8.0-3.23504.4 -> To Version 4.8.0-3.23510.8

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

Context
The sole purpose of introducing the type seems to have been silencing a legacy code analyzer rule. The rule does not exist anymore / has not been brought over to Roslyn (dotnet/roslyn-analyzers#722) and it's now hurting performance, if anything. Types like HashSet<int> are part of the mscorlib native image and it's wasteful to duplicate the code in our binaries. The rest is handled by IBC/OptProf.

Changes Made
Deleted NGen and its uses.

Testing
Experimental insertion to confirm no regressions.

Co-authored-by: Ladi Prosek <laprosek@microsoft.com>

Co-authored-by: Ladi Prosek <laprosek@microsoft.com>