search

tintoy / msbuild-project-tools-vscode

VS Code extension for MSBuild intellisense (including PackageReference completion).
MIT License
82 stars 16 forks source link

Revert running language server in an isolated .NET runtime #138

Closed DoctorKrolic closed 7 months ago

DoctorKrolic commented 7 months ago

Fixes: https://github.com/tintoy/msbuild-project-tools-vscode/issues/137

The issue is indeed connected with the fact, that we were running language server in an isolated .NET runtime from a VS Code .NET Runtime extension. This was the original intent to isolate us from the world, so we can use whatever version of .NET we want and provide features to users no matter what runtimes/sdks are installed on their system. However, our language server needs to know the info about .NET installed on the user's machine, so we start a separate dotnet process for that. And if we run language server from an isolated .NET, spawning a dotnet child process (note that this is not an absolute path) now binds to that isolated runtime executable. This was never noticed during development since any dotnet executable on Windows returns info about all runtimes/sdks installed in the system (I guess, it reads registry for that). However, the same is not true for Unix-like systems, so what happens is we try to run dotnet --version (which is an sdk command), this binds to an isolated runtime (again, only runtime, not sdk) and we get an error because --version is not supported argument for pure dotnet runtime installation. I tried to fix it properly and still use isolated runtime, while gathering information about global dotnet in the system, but I wasn't successful yet. Thus, I believe, it is better to make this fast hot fix now to provide users the ability to use latest version of the extension and then provide a proper fix when we figure that out.

@tintoy I highly recommend you trying to run this from your own wsl and double-check, that the issue is fully resolved. Also please replace release 0.5.1 instead of creating a new one if possible. It makes a lot of confusion why 2 different versions represent the same thing + any person can downgrade any version of any extension if he wants, so it wan't necessary to publish a reverting release in the first place Code_LRlF7qbDN2 Don't forget to add release notes about this. In case you replace release 0.5.1 the changelog should be something like Reverted running language server in an isolated runtime due to critical usability bug. If not and you will have to add a new 0.5.2 release, please add to the changelog both versions and specify, that 0.5.1 reverts extension to the same state as 0.4.9 and 0.5.2 returns back all good stuff from 0.5.0 + a hot fix

tintoy commented 7 months ago

Yeah, I agree it’s a little ugly; unfortunately, due to the way the VS gallery works, it is not possible to replace or withdraw a published version of an extension. That’s why I had to quickly publish v5.0.1 - to take the pressure off by preventing v5.0.0 being automatically pushed to anyone else while we were working on this 🙂

tintoy commented 7 months ago

I’ll test this change myself sometime today (both WSL and dev containers) - thanks for the quick turnaround!

tintoy commented 7 months ago

FWIW, I still think it was a good idea; I just didn’t realise that the acquired runtime/sdk was isolated rather than (globally) additive.

tintoy commented 7 months ago

msbuild-project-tools-0.5.2.vsix.zip

Also published to gallery.