Running "dotnet build" has inconsistent behavior with pressing the built-in "Build" button

[yhoundz]

Describe the bug

Running "dotnet build" from the CLI doesn't have consistent behavior with pressing the "Build" button. Specifically, LSP functionalities don't work as expected, as they will only activate after pressing the Build button, and not using "dotnet build" (using "dotnet build" will still output that you need to build the project first).

To Reproduce

1. Run dotnet new avalonia.mvvm -o AvaloniaProject in the terminal
2. Open the AvaloniaProject folder in VSCode
3. Run dotnet build in the terminal while in the project's root directory.
4. In any .axaml file, try typing in < or use any LSP functions.

Avalonia for VS Code

0.0.32

Avalonia version

11.2.3

VS Code version

1.96.2

Relevant log output

N/A

Additional context

I'm using Ubuntu 22.04.5 (on WSL) and .NET 9.0.101 SDK.

#117 maybe relevant?

[yhoundz]

UPDATE: I've found a "workaround" for this to be able to properly build Avalonia projects from the CLI (and enable LSP features), though it isn't exactly ideal.

Command: while in the root directory of the Avalonia project:

dotnet build
dotnet new sln
dotnet sln add ./[projectname].csproj
dotnet /path/to/avalonia/vscode/extension/SolutionParser.dll ./[projectname].sln

example usage:

dotnet build
dotnet new sln
dotnet sln add ./AvaloniaProj.csproj
dotnet ~/.vscode-server/extensions/avaloniateam.vscode-avalonia-0.0.32/solutionParserTool/SolutionParser.dll ./AvaloniaProj.sln

If dotnet is not added to the PATH, you can specify the path of the .NET SDK for it to work (e.g. replace "dotnet" with "/usr/bin/dotnet" instead).

The VSCode extension is still required for this to work, as it contains the proper SolutionParser.dll. Using this method, you can also get the LSP to work in other IDEs (such as neovim) without the need to open VSCode. I still wish there was better tooling to properly build the project from the CLI. I'll leave the issue open for now.

[lextm]

When the extension for this repo prompts you to build a project, the differences in calling MSBuild compared to what you do normally at terminal are mostly because this extension doesn't execute MSBuild in the right project folder (but at /).

Our fork is free of this issue as we use a different approach.

While technically speaking, a language server can be used with more than just VS Code, but other editors' LSP support is often limited or broken. So, I wonder what's the ROI to integrate with them.