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.
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?
@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:
"enable-proposed-api": ["intersystems-community.vscode-objectscript"]
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:
s r=##class(%Net.HttpRequest).%New(),r.Server="pm.community.intersystems.com",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: 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 !
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:
Thanks Brett!
I will add the support of:
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:
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:
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.
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.
@Alex Woodhead
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.
Will you miss some things?
Now working 20 years with Studio I'm kind of "married" knowing all good and bad features.
I dislike the idea to face a "forced divorce". Dictated from outside.
It smells like very bad times in past. The opposite of freedom of decision.
some context about me.. I've been working with InterSystems technologies since 1991 so I've been thru all of the changes for the past 32 years. Unless you give it a chance you won't have an opportunity to see what are the good features in VS code.
and just today spotted https://blog.postman.com/introducing-the-postman-vs-code-extension/ . This isn't full formed as they report
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
Josef
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:
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 terminal.integrated.profiles.windows). 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.
one of my (former) customers suggested this approach:
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": [ "eamodio.gitlens", "georgejames.gjlocate", "github.copilot", "intersystems-community.servermanager", "intersystems-community.sqltools-intersystems-driver", "intersystems-community.vscode-objectscript", "intersystems.language-server", "mohsen1.prettify-json", "ms-azuretools.vscode-docker", "ms-python.python", "ms-python.vscode-pylance", "ms-vscode-remote.remote-containers" ] }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.
@Iryna Mykhailova please also look at VS Code's recently-introduced Profiles feature. I imagine this could be useful in learning contexts.
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!
Hi @Michael Davidovich, I can show you how to configure VS Code to see system classes. Are you using client-side or server-side editing?
@Brett Saviano
Sorry I didn't see this until just now. We are editing on client-side.
@Michael Davidovich you might find this extension useful for exploring inherited methods etc:
https://marketplace.visualstudio.com/items?itemName=georgejames.objectsc...
One quick/dirty(?) way is to do a "View Code in Namespace" for "%SYS". Under the %SYS namespace the percent classes are not filtered out.
Readers of this thread may be interested in this discussion I just started about the export/import topic:
https://community.intersystems.com/post/studio-vs-code-migration-address...