InterSystems Official
· May 10, 2023

InterSystems Studio is deprecated, starting with 2023.2

InterSystems is committed to providing a high quality developer experience including a great IDE (Integrated Developer Experience). For the past several years we have been evolving Visual Studio Code's ObjectScript tooling in parallel with our long-standing IDE, InterSystems Studio. There have been over 46,000 downloads of the VSCode-ObjectScript plugin, and the feedback from developers is that this is a great developer experience, and now superior to InterSystems Studio.

With our 2023.2 release we are deprecating InterSystems Studio (deprecated designates a feature or technology that InterSystems no longer actively develops, and for which better options exist). We will continue to maintain, release, and support InterSystems Studio for quite some time, and we appreciate that it is still an important tool for some customers. However, customers should be advised that we are not investing in it. Our focus is on VSCode.

I've appreciated all the customer input as we've grown our ecosystem of VS Code extensions, keeping them open source while offering full support, and maintaining regular and rapid release cycles.As we continue this journey, I look forward to continuing to hear your feedback, ideas, and code.

Feel free to comment below or direct message me. As always, your voice plays a major role in this important process.

Discussion (67)17
Log in or sign up to continue

For development VS Code is great. Indent is a lot better and also the syntax checking. One small functionality I'm missing is to open classes fast with a shortcut. We're using HealthConnect and at an item the Class Name is shown in the management portal:

I can copy the class name, go to studio press Ctrl-O and paste the class name:

In VS code I can open also with Ctrl-O but then I need to fill in /HS/FHIRServer/Interop.HTTPOperation.cls

Could be a small improvement?


This is possible . How to quickly open class in VS Code | InterSystems Developer Community |. The answer to this is here: if you are using the server-side editing paradigm, which matches what you're used to with Studio, make sure you follow the instructions in the "Enable Proposed APIs" section of the extension's README (also available here). you can then use Crtl+P to find the item you need. 

my setup instructions 

The additional features (and the APIs used) are:

  1. Download and install a beta version from GitHub. This is necessary because Marketplace does not allow publication of extensions that use proposed APIs.
    • Go to
    • Locate the beta immediately above the release you installed from Marketplace. For instance, if you installed 2.4.3, look for 2.4.4-beta.1. This will be functionally identical to the Marketplace version apart from being able to use proposed APIs.
    • Download the VSIX file (for example vscode-objectscript-2.4.4-beta.1.vsix) and install it. One way to install a VSIX is to drag it from your download folder and drop it onto the list of extensions in the Extensions view of VS Code.
  2. From Command Palette choose Preferences: Configure Runtime Arguments.
  3. In the argv.json file that opens, add this line (required for both Stable and Insiders versions of VS Code):

"enable-proposed-api": ["intersystems-community.vscode-objectscript"]

  1. Exit VS Code and relaunch it.
  2. Verify that the ObjectScript channel of the Output panel reports this:

intersystems-community.vscode-objectscript version X.Y.Z-beta.1 activating with proposed APIs available.

After a subsequent update of the extension from Marketplace you will only have to download and install the new vscode-objectscript-X.Y.Z-beta.1 VSIX. None of the other steps above are needed again.

@David Hockenbroch 
We just improved the UI for creating a new server-side editing workspace folder. If you have no workspace open, you can follow the steps here to create a new one. If you do, you can add a new folder to you workspace by right-clicking in the file explorer and selecting "Add Server Namespace to Workspace..". That command will follow steps 4 and on. To see CSP files, select "Web Application Files" in the menu from step 8. To see basic files, select "code files in <NS>", then select "Filter", then make sure your custom filter contains the "*.bas" pattern. It can include other file types as well.

Package Manager is going to be a part of a product in near future, but right now it is not a part and can be installed with the following command:

s r=##class(%Net.HttpRequest).%New(),r.Server="",r.SSLConfiguration="ISC.FeatureTracker.SSL.Config" d r.Get("/packages/zpm/latest/installer"),$system.OBJ.LoadStream(r.HttpResponse.Data,"c")

Caution!  This is for IRIS only.

The package manager.

It has documentation, a bunch of videos, and there is a tag here.

If for Interoperability productions it may also be appropriate to weigh up existing capabilities available for Production deployment. See:

It provides functionality for detecting implementation used by a production.

Have created idea for Production exports to generate IPM modules as well as the usual XML export deployment.

@Mikko Taittonen 
The vscode-objectscript extension does provide New File commands for Interoperability classes. You can read the documentation here. The SOAP wizard can be accessed from the Server Actions menu. BPL and DTL classes can be edited textually. Support for the graphical editors will be added when they are rewritten using Angular. For a preview of how that would work, you can try out the new Angular Rule Editor in VS Code.

With our 2023.2 release we are deprecating InterSystems Studio (deprecated
designates a feature or technology that InterSystems no longer actively develops, and for which better options exist). We will continue to maintain, release, and support InterSystems Studio for quite some time, and we appreciate that it is still an important tool for some customers. However, customers should be advised that we are not investing in it. Our focus is on VSCode.

In what sense is this an "attack"?

Hi @jaroslav rapp. Attack may be a strong word, but I understand the feeling when beloved tools get less attention than others. We'd love to never leave a technology behind, but the reality is that with limited resources we sometimes have to devote more effort to technologies that will have bigger benefits for our users going forward. It's not always an easy decision, but I believe the short-term pain is well worth the long-term benefits.

@Anna Golitsyna 
The big plus is that VS Code is in active development, while Studio hasn't seen enhancements in years and now is deprecated. Other than that, here are some benefits of VS Code:

  • Supports Mac, Linux and Alpine Linux in addition to Windows.
  • Much faster release cycles so you get new features and fixes faster.
  • Always forward compatible without needing to install a new version.
  • Much better intellisense support. (a large list of features can be found here)
  • Modern UI with fully customizable themes.
  • Can be connected to multiple server-namespaces in the same window.
  • Debugging supports expanding OREF's to see their properties.

@Anna Golitsyna 
I think the debugging experience in VS Code is actually better than Studio since you can view the properties of OREF's in the variables view in VS Code but not Studio. You can have that developer file an issue report on GitHub, or contact the WRC if you have a support contract.

As for features in Studio but not VS Code, the biggest one is the Inspector. It is very unlikely that it will ever be implemented in VS Code. VS Code also does not support integration with the legacy Zen BPL and DTL editors. VS Code will support integration with the new Angular versions of those editors when they are implemented. VS Code also doesn't support syntax coloring for Cache Basic or MultiValue Basic, but you can still edit those files.

I feel that I have not explained clearly enough the Studio features that we use. We often export classes to XML files. Similarly, we import XML files, compiling them as classes during import. I didn't mean to imply that this was done simply to transfer classes to other namespaces or servers. Rather, it's a way to archive classes as XML files. (We don't use a source control system.)

We use the Find in Files utility to determine the classes and other files in which a given string exists.

I mentioned the Namespace variation of the Studio Workspace pane because that is the arrangement of files (classes, lookup tables, message schemas, etc.) that we most often use.

@Larry Overkamp 
VS Code does not support exporting or importing source code as XML files. There are existing tools in the terminal and SMP for that. The server-side editing paradigm that John mentioned above is conceptually similar to Studio in that the files you edit are "virtual" and do not need to be exported to the file system to be edited. It supports viewing all files in a namespace like in Studio, and it also supports importing local .cls, .mac, .int and .inc files into that namespace.

Searching for text across those virtual files is supported and the UI is much better than Studio since you can click on the match and jump right to that location in the file. Enabling that feature requires some extra steps due to a VS Code core limitation, but this is something that we anticipate will be resolved in the future.

  We use the TrackWare SCCS, for both our Cache/IRIS and Delphi application development.

  TrackWare has the unique distinction of being written in both Delphi and Cache.  It integrates well with Studio SCCS.

  We now own the TrackWare package and I have had to make updates to the Cache/IRIS side to keep it current.

  (It was formerly owned by Jorma Sinnoma (sp?) who is now a member of the InterSystems team.)

  It works for us and we would want to stay with it for as long as Studio functionality and SCCS integration stays intact.

A real bugaboo for us, besides the ease with which we can check out and check in our Cache/IRIS code elements, is that we would have to come up with another product to maintain source control on the Delphi side.

So, please do not stray from what Studio offers us now both as an IDE and its SCCS integration.

Thank you

Rich Filoramo

InTempo Software

@Richard Filoramo 
The server-side editing paradigm in VS Code is conceptually similar to Studio in that the files you edit are "virtual" and do not need to be exported to the file system. This mode supports Studio source control classes, so you can continue using them if you want. We have a documentation page that describes some useful features for migrating from Studio that describes where the Studio source control integration can be found in the VS Code UI.

I'll add to this, we use the same "embedded" source control behavior across Studio and VSCode for my team within InterSystems, and haven't had issues.

@Richard Filoramo , one question re: TrackWare - do you know offhand which "Actions" and "Other Studio actions" it uses in the UserAction method from %Studio.Extension.Base (see class reference)? There are some limitations/differences between VSCode and Studio but they're on things we see as either less common or undesirable to support from VSCode. One such case we've previously deemed "undesirable" is Action = 3, "Run an EXE on the client. The Target is the name of an executable file on the client machine. It is the responsibility of the customer to ensure this EXE is installed in a suitable location." Your statement that your source control system is written in ObjectScript and Delphi makes me think this might matter to you.

More generally, @Brett Saviano , there may be other aspects of complete support for the interface defined in %Studio.Extension.Base to consider.

A thought about moving from *.xml source controlled files to *.CLS (UDL) file content with VSCode.

  • The exported source content is different from existing in source control
  • The export name is different and may be seen as an unrelated resource

A while back I had shared community application ompare

I mention as this utility allows the comparison of what is installed in a namespace, regardless if the external format was XML or UDL. Some may find useful to see the real differences between their own historic product releases and a current release. At least until have a few releases / baseline in their new source repository.

Have notice other community apps like xml-to-udl that might be appropriate for need.

With the discussion of Intersystem IRIS Studio or VS Code, I understand the initial reaction to think you are losing something using VS Code.  Will you miss some things, I'm sure you will, but measured on the whole I feel like VS Code is a much better environment even if all you ever do is objectscript work.  I feel like that's the critical thing to remember, there may be some differences but measured on the whole it is better, give it a try and give it a chance, especially learning the full capabilities.

and just today spotted .  This isn't full formed as they report 

 We will continuously ship features and improvements—such as support for Postman Collections and environments—so be on the lookout. We value your input, so if you have any feedback on this beta version, please feel free to leave it in the comments. 

but just one more example why measured on the whole VS Code really is a better environment IMHO.

I've also used Studio for 20+ years. I can still remember how much better it was than what we had before. We can all still use Studio if we want; it's not a forced divorce. But we hope that VS Code -- ObjectScript's features will make you comfortable enough to decide to do a conscious uncoupling. And as Frank Sinatra sang: "Love's much lovelier, the second time around." And he could have sung that at the Diplomat Hotel in Fort Lauderdale in 1974, where coincidentally InterSystems is hosting our Global Summit this year!

There is no doubt that working with VSCode is more productive than working with ISC Studio. I've been working with ISC Cache since 1997 and thank God ISC finally has a normal development IDE. But there are small things that need to be fine-tuned:
1. When overriding, be able to include the original implementation as well
2. The terminal cannot process Home End keys, etc., and it throws lines.
3. Close automatically opened routines/classes when debugging is finished
4. In the debug console, the zwrite option
5. Option to switch from read only file to edit file on GIT disk
6. Debugging INT source codes does not work well
7. jump to label+offset

and a lot of little things will certainly appear.

Maybe the problem is that I'm still working on Ensemble 2018


Hi @Josef Zvonicek, I'm glad that VS Code is making you more productive, and thanks for the feedback. I have some comments about your fine-tuning list:

  1. The "override class members" functionality is implemented by the Language Server extension. If you file an issue on its GitHub repository I would be happy to consider this enhancement request.
  2. The VS Code integrated terminal is part of the core product, and not our extensions, so I'm not sure we can do anything about this. Can you provide more details about how you started the terminal and the expected vs actual behavior?
  3. Newer versions of the vscode-objectscript extension should avoid opening that extra copy of the file when debugging. If you're using  recent version like 2.8.0 or 2.8.1 and this isn't working, please file a GitHub issue in that extension's repository and I will take a look at it.
  4. The debug console can only evaluate expressions. It's not a full terminal and cannot execute commands, so this isn't possible unfortunately.
  5. I'm not sure what a GIT disk is. Are you editing files on your local file system?
  6. Can you describe what doesn't work well, and what we could do to make things better?
  7. There is a command called "Open Error Location..." that you can execute from the command palette. It prompts you to enter a "label+offset^routine" string and then opens that location. It only works for INT routines though.  

With #2 (at least for me anyway), the issue seems to be related to running iris session when using the Windows version of ssh.exe (called from VS Code, configured in settings under node Home and End work normally at the Linux shell prompt, but when running iris session the effect is that either key produces the same result as pressing the Enter key. The current command is executed and a new IRIS prompt is generated.

It doesn't seem to be a VS Code problem so much as an ISC problem, at least on Windows.

For me it's a horrible news 😭 I really prefer to use Studio when explaining how to create properties (particularly relationships) and queries (particularly Class Queries based on COS) to students who see IRIS for the first and the last time during my classes. And when something goes wrong (and it does a lot of the time) it's usually easier to ask them to delete the code that produces error and rewrite it while I'm looking than to figure out what's wrong with it. And if it something more complicated than simple properties it can take a lot of time.

Besides, not all students know (and want/need to learn) how to use VS Code and look for proper plug-ins, extensions etc. It will really make my life that much harder.

Please, give VSCode a try.

Regarding of extensions, you can give students a repository with .vscode/extensions.json, that will already contain examples. E.g. here is how my extensions.json looks like:

    "recommendations": [

This will not install extensions automatically, but they will be shown as recommended for the workspace, like that:

Here is the template they can start from and here is an example extensions.json file.

Maybe my VS Code setup isn't correct, but if I need to explore % class files to learn more about behavior of some methods (let's face it, the documentation isn't always revealing), I use Studio.  A recent example was learning what methods of %CSP.Page I could override and which order the override-ed methods were called in the code.

I know in the past I've referenced other things.  It's not often but it's helpful when we can.  I haven't found a way to view % classes in VS Code.  

Maybe someone can help me if that's something I've missed!