XSharp in VSCode

[Fabrice]

Hi Guys,

If you have been attending our latest Summit in Potsdam, you have seen my demo of X# Integration in Visual Studio Code.

To celebrate the forth coming of XSharp 3.0, I'm happy to announce that a version is now freely and publicly available.

For now, you can download it at my homepage : http://www.fabtoys.net
Unzip the downloaded file, then in VSCode open the Extension panel (Ctrl + Shift + X), then click on the "Views and More Actions" button on the top-right (...) and select the last item "Install from VSIX".
Open a PRG file (and get the syntax coloring and more), open a .xsproj and right-click on it to build, run, and with a .NET SDK format get access to all the Settings

[stecosta66]

Hi Fabrice,

just a quick note about the new XSharp Tools extension.

After VS Code auto-updated the extension, my current X# 2.24.0.1 (FOX subscription) / .NET Framework 4.8.1 solution stopped building correctly, because the new extension uses `dotnet build`, which picked up the .NET 10 SDK in my environment. My WinForms project then failed with resource-related errors such as `MSB3822` and `MSB3823`.

I later noticed the note about SDK-style projects and X# 3.0, so this is expected. I downgraded to the previous extension version (0.4.8) and my current setup works again.

It might be useful to make this clearer in the README/release notes, especially for users with VS Code extension auto-update enabled and traditional `.xsproj` / .NET Framework projects.

Thanks for your work. I look forward to using the new extension once X# 3.0 is officially released.

Ciao
Stefano

[Fabrice]

Hi Stefano,
Many thanks for your message and feedback.

In fact, X#3 is (should be) needed "only" for the project settings, as the extension is "only" able to read/modify SDK projects correctly. (I may have add too much options ! )
That said, the XSharp tools settings (dialect used for coloring, formatting options, etc) are used by the LSP Server that is self-contained, so it is version agnostic.

Regarding the build command, it is using "dotnet build" in v0.6 as in v0.4... So I must have changed something by accident; I will check.

Thanks again

[stecosta66]

Hi Fabrice,

I found the actual cause.

It was not a difference in the build command between extension versions. My workspace already has a `.vscode/tasks.json` default build task that explicitly calls Visual Studio MSBuild:

`C:\Program Files\Microsoft Visual Studio\18\Community\MSBuild\Current\Bin\amd64\MSBuild.exe`

with my `ModernUI.xsproj`, `/p:Configuration=Debug`, `/p:DeployDir=C:\ADMWINNETSQL\`, `/m`, and `/t:Build`.

After installing the newer XSharp Tools extension, `Ctrl+Shift+B` was being handled by the extension command `Build XSharp Project` when an XSharp file was active (`resourceLangId == 'xsharp'`). That opened the “Select XSharp project” quick-pick and then used the extension build path, which in my environment went through the .NET 10 SDK and failed on my traditional .NET Framework 4.8.1 WinForms project with MSB3822/MSB3823.

I changed the keybinding locally:

* `Ctrl+Shift+B` is now back to the standard VS Code `Tasks: Run Build Task`
* `Build XSharp Project` is now on `Ctrl+Shift+Alt+B`

With this setup, the new extension can stay installed and my existing ADM build workflow works correctly again.

So this was mainly a keybinding precedence issue in my environment, because I already had a custom workspace build task.

Thanks again for your help.

Ciao
Stefano

[Fabrice]

Hi Stefano,

thanks for the info.

I will see if I can do something in that situation (message, ...); and also indicte that in the Readme.

[stecosta66]

Hi Fabrice,

just a small follow-up.

I also checked the README and everything now makes sense.

The behaviour I saw is consistent with the documented changes:
- Ctrl+Shift+B is assigned to the XSharp build command when an XSharp file is active.
- In a multi-project workspace, it opens the .xsproj quick-pick.
- The extension build path uses dotnet build.

In my workspace I already had Ctrl+Shift+B associated with the standard VS Code build task, which calls Visual Studio MSBuild.exe through tasks.json. I solved the conflict locally by moving the XSharp Tools build command to Ctrl+Shift+Alt+B and keeping Ctrl+Shift+B for Tasks: Run Build Task.

I also fixed my formatter warning: my settings had the wrong extension id, “XSharp BV.xsharp-tools” instead of “XSharp-BV.xsharp-tools”.

One small note: the README says the language server is self-contained, but on one machine running XSharpLanguageServer.exe manually required Microsoft.NETCore.App 8.0.0 to be installed. After checking my main machine, where .NET 8 runtime is installed, the LSP works and I now have hover, references, CodeLens and Go to Definition.

So everything is working on my side now.

Ciao
Stefano

[stecosta66]

Hi Fabrice,

I found a possible LSP parser false positive in legacy VO-style code.

The original code compiles correctly with the X# compiler, but the VS Code LSP reports `ERR_ParserError`.

The first pattern was:

IF ( nPos := RAt( '\', cFile ) ) != 0
cFile := SubStr2( cFile, nPos + 1 )
ELSEIF ( nPos := At( ":", cFile ) ) != 0
cFile := SubStr2( cFile, nPos + 1 )
ENDIF

At first I thought the issue was the inline assignment inside the `IF` condition. I then rewrote the first line as:

nPos := RAt( '\', cFile )
IF nPos != 0

The parser error on that area was reduced, but the LSP still complained around the backslash literal. I also tried using double quotes:

nPos := RAt( "\", cFile )

The build is still fine with the normal compiler, but the LSP diagnostics remain inconsistent.

So there may be two separate parser issues:

1. inline assignment expressions inside `IF` / `ELSEIF` conditions;
2. handling of a backslash literal in function arguments.

I also still see cascading `ERR_ParserError` diagnostics later in the same large legacy file, so I will try to isolate a smaller repro if needed.

I just prepared two reproducible tests

FUNCTION TestBackslash( cFile AS STRING ) AS STRING
LOCAL nPos AS DWORD

nPos := RAt( '\', cFile )
IF nPos != 0
cFile := SubStr2( cFile, nPos + 1 )
ENDIF

RETURN cFile

FUNCTION TestInlineAssign( cFile AS STRING ) AS STRING
LOCAL nPos AS DWORD

IF ( nPos := RAt( '\', cFile ) ) != 0
cFile := SubStr2( cFile, nPos + 1 )
ENDIF

RETURN cFile

[Fabrice]

Hi Stefano,

thanks for your feedback.

I've seen the same effects, and I'm working on it.
Maybe it was a bit too early to release this version, but I was happy to share the current state of this project.

I will keep you informed.

Regards

[Fabrice]

Hi Stefano,

version 0.6.7 has been sent to VSCode Marketplace, you should have the update very soon.

It solves the false positive errors with escapes string, add support for .Net framework projects and .Net core, allow to create new project (SDK only - so X#3), Formatting has been corrected too, etc...

Regards

[stecosta66]

Hi Fabrice,

I updated to 0.6.7 and tested it.

The false positive parser errors around the backslash escape/string case are gone on my side.

I also tested the project configurator on my legacy non-SDK-style ModernUI.xsproj project, and it now opens correctly from the right-click menu. It correctly reads the project as:

- Target Framework Version: v4.8.1
- Dialect: VO
- Output Type: WinExe
- Default Namespace: ModernUI

So the legacy project support looks good in my environment.

My production build is still handled by my custom VS Code task using Visual Studio MSBuild, while the XSharp Tools build command remains available on a separate shortcut.

Thanks again for the very quick fix. This version is working much better for my setup.

Ciao
Stefano