In microsoft/CsWin32#218, we had a report of a source generator that was failing to load in Omnisharp. Debugging revealed it the analyzer depends on System.Text.Json, and the NuGet package there depends on assembly version 4.1.3 of System.Numerics.Vectors. However, another dependency brings in 4.1.4 of System.Numerics.Vectors, which in a normal app would be resolved with a binding redirect at runtime. Since microsoft/CsWin32#261 was fixed, the analyzer does package 4.1.4.
For our command line compilers, right now it works out that this analyzer will load, only because System.Numerics.Vectors 4.1.4 happens to be a dependency of the compiler and thus a direct is in place for it. But that's somewhat an implementation detail and could change. For Omnisharp however, it doesn't have a redirect and thus won't load. And there's no practical way to package both 4.1.3 and 4.1.4 versions of the dependency in the same NuGet package to work around the issues.
Discussing with @jaredpar it seems the best resolution here is to change our assembly loading rules a bit. When we load an analyzer, we require exact matches of dependencies here; changing that to allow an "or higher" would mean we'd be effectively doing a binding redirect at runtime, which would resolve these issues.
Omnisharp currently has a copy/paste of the analyzer assembly loading code in it's repo; once we have the compiler change in hand we should update that copy. Since we have an External Access shim, I'd propose we simply make an API for them to fetch the implementation Roslyn has and they can reuse that directly.
In microsoft/CsWin32#218, we had a report of a source generator that was failing to load in Omnisharp. Debugging revealed it the analyzer depends on System.Text.Json, and the NuGet package there depends on assembly version 4.1.3 of System.Numerics.Vectors. However, another dependency brings in 4.1.4 of System.Numerics.Vectors, which in a normal app would be resolved with a binding redirect at runtime. Since microsoft/CsWin32#261 was fixed, the analyzer does package 4.1.4.
For our command line compilers, right now it works out that this analyzer will load, only because System.Numerics.Vectors 4.1.4 happens to be a dependency of the compiler and thus a direct is in place for it. But that's somewhat an implementation detail and could change. For Omnisharp however, it doesn't have a redirect and thus won't load. And there's no practical way to package both 4.1.3 and 4.1.4 versions of the dependency in the same NuGet package to work around the issues.
Discussing with @jaredpar it seems the best resolution here is to change our assembly loading rules a bit. When we load an analyzer, we require exact matches of dependencies here; changing that to allow an "or higher" would mean we'd be effectively doing a binding redirect at runtime, which would resolve these issues.
Omnisharp currently has a copy/paste of the analyzer assembly loading code in it's repo; once we have the compiler change in hand we should update that copy. Since we have an External Access shim, I'd propose we simply make an API for them to fetch the implementation Roslyn has and they can reuse that directly.