The core work here is that we were pulling reference assemblies out of a folder with the name RoslynTools.ReferenceAssemblies. A while ago NuGet switched to unpacking all folders with lowercase paths. On Windows this continues to work fine as the filesystem APIs are case-insensitive, but this fails on Linux. By matching casing we can build both net461 and netcoreapp targets on any operating system. The inability to do this was the primary reason for CrossPlatform.sln, so there's now no reason for the solution and we can switch to using Compilers.sln, which is a more reasonable superset of everything in CrossPlatform.sln.

Fixes #20932

This reverts commit f5fc55f8.

Add back feature flag in post-contrib branch. A separate PR will remove IOperation feature flag without removing the experimental feature framework

Rollback the change to move toolset and analyzers forward to 2.5 - we will do this work in dev15.5 branch to dogfood the new analyzers

This lets us avoid hard coding in version numbers for the core tools
we use in our build.

This changes the unix legs to use the 2.0 SDK. They are likely to suffer from the
same problem as the windows CoreClr leg in that they aren't producing XML files. But
we should be able to fix both of those at the same time.

The Roslyn build depends on having a minimum of MSBuild 15.1 in order to
function. Anything less than that will fail with very crpytic errors,
usually around NuGet runtime identifiers.

This change causes our build to declaratively fail with a very specific
message if the wrong version of MSBuild is used. It should help point
customers in the right direction to fixing up the problem.

Note: This was made to be parameterized in Imports.targets because very
soon it will be changing to depend on 15.3.

This changes our core Roslyn.Test.Utilities project to use
multi-targeting to control how we create our core compilation helper.
Previously this was done by having a separate runtime specific assembly
which was probed at runtime.

The intent of this change is to make our build more correct here. I can
now target just Roslyn.Test.Utilties with a net46 framework and get a
runnable asset out of it. This is necessary in order for our unit tests
to successfully run when moved to multi-target.

Presently this makes it multi-target across net46, netcoreapp2.0 and
netstandard1.3. The impl in netstandard 1.3 simply throw for this
specific API. Over the long term it make make sense to pull this out to
a separate library that only targets net46 + netcoreapp2.0. That
requires a much deeper investment in multi-targeting though. Decided to
start smaller for now.

Recent builds of the SDK introduced a bug around referencing netstandard
1.6 projects. This trigged on several Roslyn projects and cause build
breaks with newer builds of VS.

Suppressing the check for now. Will undo when we move to 2.0 SDK

https://github.com/dotnet/roslyn/issues/21183

Recent builds of the SDK introduced a bug around referencing netstandard
1.6 projects. This trigged on several Roslyn projects and cause build
breaks with newer builds of VS.

Suppressing the check for now. Will undo when we move to 2.0 SDK

https://github.com/dotnet/roslyn/issues/21183

Recent builds of the SDK introduced a bug around referencing netstandard
1.6 projects. This trigged on several Roslyn projects and cause build
breaks with newer builds of VS.

Suppressing the check for now. Will undo when we move to 2.0 SDK

https://github.com/dotnet/roslyn/issues/21183

Fixes #21050

A recent change to enable analyzers caused a 3-6X build slow down.
Disabling them locally at least until we can track this down.

https://github.com/dotnet/roslyn/issues/21041

The [change](https://github.com/dotnet/roslyn/commit/6be56fadb4c417c4b6af0bf62f1242e41c8dd124) to move analyzers to 2.5 version broke analyzers in the branch - they are laid out differently in the new nuget package. Build targets are unable to find the props for importing the analyzers and silently bail out executing them. This PR fixes the following:

1. Fix the props file path in Imports.Targets
2. Move to a newer analyzer package which has an important [bug fix](https://github.com/dotnet/roslyn-analyzers/pull/1255)
3. Report a build error if analyzer props file does not exist
4. Fix the public API errors (mostly due to duplicate entries in shipped and unshipped files).
5. Fix one instance of RS0014 (Do not use Enumerable methods on indexable collections. Instead use the collection directly) introduced recently in the code.
6. Add suppression for one instance of CA1802 in WellKnownAttributeData.cs that fixed the signing issue.

This change is required for accurate handling of comments, per dotnet/roslyn#2773.

The NuGetPackageToIncludeInVsix element is used to make the NuGet assets
we use in a VSIX very explicit. It depended on the nuget items having
the metadata element NuGetPackageId. The 1.X New SDK no longer has this
piece of metadata and hence we had to pick a new approach.

After some discussion decided to simply look for the assets which are
coming out of the NuGet packages folders that we expect. It's
essentially the same check.

Needed to encode this in an MSBuild task though as the MSBuild
transforms can't handle that level of complexity.

The warning B40057 used to be suppressed at a global level in PCL /
Desktop projects. The SDK does not suppress this warning and hence
converting to the new SDK caused this to show up.

Previously a number of developers fixed this problem individually. The
correct solution is to suppress it globally as was done previously.

Couple of changes to make it possible to build all desktop projects on
new SDK

- Use new RunResolvePackageDependencies target
- Use LangaugeTargets to allow WPF / VSIX to be built

Enable few more rules and fix issues identified these rules.

Also added issue IDs for the disabled rules due to lack of a fixer/fix all experience.