· Jan 14, 2019

Seeking field testers for an upcoming VSCode extension from George James Software

At the George James Software booth at Global Summit last year we took the wraps off the work we've been doing to make our popular editing and debugging tool Serenji available on the Visual Studio Code platform.

Rather than requiring you to pull code from your namespaces into local files, then push the changes back to the namespace to run it, you work directly in the namespace. In other words, the editing experience is like Studio rather than like Atelier.

As well as editing code you can also debug it directly from VSCode.

We're now looking for people to test a pre-release. If you already use VSCode (or are willing to start doing so) and you would like access to the pre-release Serenji extension, please email me privately at the address on my DC profile at Tell me what InterSystems platform(s) and version(s) you're working with, and what platform(s) you run VSCode on. I'd also like to know approximately how many years you have worked with ObjectScript, and whether your ObjectScript codebase consists mainly of classes or MACs or INTs. Plus, please indicate if you're already familiar with VSCode or not.


John Murray
Senior Product Engineer
George James Software

Discussion (12)3
Log in or sign up to continue

To use our extension you have to install some code on the target server. This code works on the latest platforms (e.g. the IRIS 2018.2 Field Test container) and on versions back to well before InterSystems' Minimum Supported Version. Indeed, one of my targets is still on 2008.1.

So a single VSCode instance can connect to many different server versions.

Does that answer your question Robert?

Hi John,

Do you plan on integrating the vscode extension with git somehow?

Of course, when we are editing source code on the file system (like with Atelier), it's fairly straightforward to put the code in a git repo (however, sync against Caché can be a mess).

If you are editing code directly against a Caché DB, this would probably require manually exporting the changes to the filesystem, or perhaps making the vscode manage the git objects directly against the repo.