Tooling to validate dependency restrictions, that Visual Studio imposes on Roslyn tools.

In our company, most developers are using Rider. For those few that use Visual Studio, things regularly break, because a dependency is updated for some of our internal tooling, that is using Roslyn. In the last few weeks System.Collections.Immutable was updated to 9.0.0 in four different places by different people, and this changes all had to be rolled back, after Visual Studio users got blocked. Similar issues happened a few times with Microsoft.CodeAnalysis NuGets, because they are usually released some days before the matching Visual Studio version.

We are definitely not alone with this struggle. Others break Visual Studio users too. See for example https://github.com/ChilliCream/graphql-platform/issues/8106 or various occurrences linked in https://github.com/dotnet/roslyn/issues/45162, https://github.com/dotnet/roslyn-analyzers/issues/7302 and https://github.com/dotnet/roslyn/issues/47087.

Ideally Visual Studio would not impose more restrictions than console builds, but as far as I understand the amount of tech dept is to high to achieve this. As an alternative, it would be nice, if the restrictions could be validated. A possible implementation might be to release a "dummy" NuGet package for every Visual Studio version, that just enforces version range constraints for NuGets used by Visual Studio.

No files, tests, or entry points are named. Start by reviewing the linked Roslyn and Roslyn-analyzers issues and the Visual Studio dependency restrictions described here; done would mean a validated way to detect incompatible NuGet versions before Visual Studio users are blocked.

Written by the indexing model from the issue text.