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.
Comments
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:
.png)
I can copy the class name, go to studio press Ctrl-O and paste the class name:
.png)
.png)
In VS code I can open also with Ctrl-O but then I need to fill in /HS/FHIRServer/Interop.HTTPOperation.cls
.png)
.png)
Could be a small improvement?
@Menno Voerman
Unfortunately I don't think this is possible. That command is for opening files, and technically the name of the file is "HS/FHIRServer/Interop.HTTPOperation.cls", not "HS.FHIRServer.Interop.HTTPOperation.cls".
Hi:
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:
- Server-side searching across files being accessed using isfs (TextSearchProvider)
- Quick Open of isfs files (FileSearchProvider).
- 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 https://github.com/intersystems-community/vscode-objectscript/releases
- 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.
- From Command Palette choose Preferences: Configure Runtime Arguments.
- 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"]
- Exit VS Code and relaunch it.
- 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.
I still can't see my csp files or .bas routines in VS Code. What do I have wrong?
@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.
To see CSP files with server side editing if you hold shift before clicking the pencil icon it will load up a web files view .png)
VS Code is great for development, while InterSystems extensions behavior is disappointing sometimes.
E.g., since some update was installed, <Ctrl/Mouse pointer> stopped referencing the methods of another class. <Right button menu -> Goto Definition> stopped working as well. Is it a bug or a feature?
@Alexey Maslov
That sounds like a bug to me. Can you file a GitHub issue with steps to reproduce? It would also help to know the versions of the extensions you have installed, the version of IRIS you're connected to, and the text of the file that you see the bug in.
Done, expecting that InterSystems ObjectScript was the right choice for the kind of issue.
The export capabilities in VSCode are very poor compared to Studio. There should be a possibility to export multiple classes/routines in xml format.
VSCode also lacks the different Wizards (SOAP/XML) and the guided way (File/New...) to create classes, processes, DTLs, BPLs and so on. You can't edit BPLs and DTLs with VSCode.
Why would you need XML?
Hi @Mikko Taittonen! Why would you need XML export for classes/routines? Why not UDL? UDL is much more readable?
The format doesn't matter as long as you can easily package multiple classes/routines in a single file. By easily I that mean that you should be able to choose the exported classes/routines eg. from a class tree.
If I can guess you need export several classes/routines/macro in one file e.g. to deploy to another server.
I'd recommend to use InterSystems Package Manager for it
Is there documentation for this? I searched "package manager" in the documentation and didn't get anything in the results....
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:
sr=##class(%Net.HttpRequest).%New(),r.Server="pm.community.intersystems.com",r.SSLConfiguration="ISC.FeatureTracker.SSL.Config"dr.Get("/packages/zpm/latest/installer"),$system.OBJ.LoadStream(r.HttpResponse.Data,"c")Caution! This is for IRIS only.
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: https://docs.intersystems.com/irisforhealth20232/csp/docbook/DocBook.UI…
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. https://ideas.intersystems.com/ideas/DPI-I-382
@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.
For what it is worth: I don't agree.
Studio is a Objectscript dedicated IDE (Editor), rather clean and unobtrusive.
It could be enhanced quite simple.
The only problem is Windows only (which is still 57.37% of all desktops)
Fully support this!
It's a sense less attack to the traditional installed base !
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"?
C'mon! we heard this to often: WebLink, Caché, ...
- We will continue to maintain, release, and support ....
- and every IRIS Version needs a new Studio version
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.
Is there a recent and detailed article comparing VSCode plugin and the latest Studio? Something like this is what Studio still does better and this is what plugin does better.
Hi @Anna.Golitsyna. This recent discussion, First Community Roundtable: VSCode vs Studio, may be useful.
I'll watch it, thanks, Raj. I have to say though that I really prefer searchable text that can be visually scanned diagonally in 5 minutes as opposed to watching a 45-minute video. Oh well...
@Anna Golitsyna
We have a documentation page that describes some useful features for migrating from Studio that you may find useful.
Thanks, @Brett Saviano . I'd like to assess what are plusses and minuses of migrating first.
@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.
Thanks Brett!
I will add the support of:
- Docker
- Git source control
- Github/Gitlub interactive plugins
- Embedded Python
- Co-pilot (when VScode writes ObjectScript for you instead of you)
- Full-functional IRIS Terminal
And options to use 3rd-party plugins, e.g. from George James, @John Murray mentioned earlier.
@Brett Saviano @Evgeny Shvarov You listed VSCode plusses, thanks. How about what Studio does that VSCode plus free plugins still do not? One of our programmers complained about debugging as of July 2022. Is it on par now?
@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.
In the interest of accuracy, Studio does allow looking at OREFS to see their properties (View As > Object, or Dump object).
I've never used VS Code, and I don't know anything about it. I am wondering whether there are equivalents for a couple things we often do in InterSystems Studio:
- Export (to XML) and import classes.
- Find in Files.
Also, is there an equivalent to the Namespace Workspace that is available in Studio? That's the arrangement we use the most.
Yeah,
moving code between Studio instances to other namespaces on same or different server
simply by drag & drop
Yes, you can do this in VS Code. Even better, when using the server-side editing paradigm a single VS Code instance can connect simultaneously to multiple namespaces on one or more servers, and you can drag/drop and copy/paste between them.
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.
@Larry Overkamp my reply was focused on what @jaroslav rapp had posted.
You also wrote:
(We don't use a source control system.)
Have you considered changing this situation? If so please take a look at Deltanji from George James Software (my employer). Some videos are available at https://www.youtube.com/playlist?list=PLGnA3ZIngG4oOUCEmplIYgSknQpNOtF08
What is the benefit of exporting to XML vs exporting to CLS?
We sometimes export classes from one environment and import them to another. I don't see .cls as a supported file type for those activities.
Hi @Larry Overkamp !
You can use $system.OBJ.ExportUDL() to export in CLS or MAC or INC.
and $System.OBJ.Load or $system.OBJ.LoadDir() to import CLS or XML or MAC.
As for transferring code between systems I'd recommend to maintain code in repositories (e.g. git) and deploy code via InterSystems Package Manager.
Find in Files works with the Enable proposed APIs and valid version working.
Was not aware of drag/drop for export/import.
I find even though a lot of the discussions around source control are great and easier using vs code I still don't feel there is an easy jumping in point to really get started to use a control system.
I agree. Adopting source control is like committing to a workout regimen. It's hard to get started and feels like a big hassle, but eventually you can't imagine living any other way, and you love the way your body of code looks ;)
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.
Just to clarify for everyone, Studio source control classes that import/export XML files will continue to work and be supported. There just won't be a menu option in VS Code to export files as XML.
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.