This is caused by how version 2.12.0 and above of the ObjectScript extension depends on the Server Manager extension, which hasn't yet been made compatible with VS Code in the browser.

I have created https://github.com/intersystems-community/intersystems-servermanager/iss...

Workaround is to use the gearwheel on the extension's detail page, then choose to install the latest pre-2.12 version.

Maybe the page is trying to display details of a previously-opened prodclass that is giving it a problem.

I suggest you use the %G utility in an IRIS Terminal in your namespace (INTERFACES?) to see what this lists:

INTERFACES>d ^%G
 
Device:
Right margin: 80 =>
Screen size for paging (0=nopaging)? 24 =>
For help on global specifications DO HELP^%G
Global ^EnsPortal.Settings(,"LastProduction")
^EnsPortal.Settings("XXX","LastProduction")="Foo.Bar"
 
Global ^

I came up with a better technique for using Yuzinji and Structure101g Studio to reveal which deprecated classes an app's codebase uses. Here's a screenshot showing the results for the Web Terminal 4.9.6 package on IRIS 2024.1

I adapted the tagging technique to identify the use of deprecated methods in non-deprecated classes. In the case of the Web Terminal codebase, no such usage was found.

If anyone reading this is interested in trying this on your own codebase please contact me through DC's DM facility, or email info@georgejames.com

Here's one way to verify from VS Code (but independent of the InterSystems ObjectScript extension) that the /api/atelier REST APIs are available on that server.

  1. Start a new VS Code window (no workspace open)
  2. In Extensions view, use the filter @id:humao.rest-client to find and install the REST Client extension.
  3. From the File menu create a New Text Document, setting its language to http.
  4. Paste this content:
GET http://localhost/api/atelier/v1/%25SYS HTTP/1.1
Authorization: Basic _system:SYS

Now click on the "Send Request" codelens that appears above the first line.

I think it's possible to do this using our Yuzinji tool. Here's my idea:

  1. Go to https://structure101.com/downloads/, fill in your details, and download Structure101g Studio (S101g) for your desktop platform (one of the 3 icons circled red below):
  2. Read the instructions in https://structure101.com/help/generic/flavors/yuzinji/index.pdf to install Yuzinji into S101g, then to add Yuzinji's server-side component to your InterSystems server.
  3. Analyze all your classes and load the results into Structure101g Studio.

But how to identify which deprecated methods or classes are being referenced?

S101g has facility for tagging items on its diagrams. Its "Tag" menu can also export and import a list of tags.

  1. Tag an arbitrary class and an arbitrary method.
  2. Export your tags.
  3. Examine the file.
  4. Write a SQL query to list deprecated classes: select ID from %Dictionary.ClassDefinition where deprecated=1 order by ID  
  5. Format the output to match the structure of the exported tags file, and write this to a file. I'm leaving this as an exercise for the reader.
  6. Import the file into S101g
  7. Repeat previous steps to create a tags file for deprecated methods.
  8. Explore your diagrams to pinpoint the tagged (and therefore deprecated) items.

It is often the case with large applications that developers would like to or need to work on unrelated parts of an application simultaneously. It is a limitation of the Git for Shared Development Environments application from the InterSystems Open Exchange that you cannot do this in a single namespace. That's because it is built on git, where you can only have a single branch checked out to a working folder at any one time.

Our InterSystems-native source control and integrated deployment solution Deltanji allows developers to create multiple separate branches within the same namespace.  Because Deltanji has finer granularity it can handle concurrent non-overlapping sets of changes in a single namespace, enabling users to check code entities out onto separate Change Requests, then promote these independently.

Even with a team as small as one person it is common for Deltanji-controlled development to take place this way. Use of QA and/or Staging environments ensures that unforeseen dependencies created in the Development environment between supposedly independent Change Requests will be detected before they can impact the Production environment.