XML export of Studio project unexpectedly omits webapp (CSP) files when webapp name doesn't contain any slashes

I encountered this quirk when investigating an unrelated issue affecting how Studio projects are handled in VS Code.

When you add the top level of the webapp to a %Studio.Project this inserts a %Studio.ProjectItem with a .DIR suffix. For example, if Studio or VS Code is connected to the USER namespace and you add the /csp/user webapp to a project the new ProjectItem name is "csp/user.DIR".

When you export this project to XML from the project's context menu in Studio, or by calling the %Studio.Project.Export classmethod, the file contains the project definition plus all of the files in the /csp/user webapp's physical path subtree (i.e. all your CSP, JavaScript, CSS etc files). Importing this to a namespace on another server on which a webapp of the same name exists is a convenient way of transferring the webapp's code.

The quirk/bug is that if your webapp name doesn't contain any slashes (ignoring the leading one that begins all webapp names), then the Export classmethod fails to put the webapp's files into its XML output file.

For example, if the namespace MYAPP hosts a webapp named /myapp and you create a Studio project consisting of "myapp.DIR" as its ProjectItem, an export of this project doesn't contain your webapp's files.

Here's why this happens:

Line 871 calls the Exists method of %Library.RoutineMgr with the argument "myapp.DIR"

The code at line 653 above is apparently there to ensure that names of webapp files or directories have a "/" prefix before being used in calls to $$GetFilename^%apiCSP on line 661 (for .DIR items) or to ..IsCSPName on line 664 (everything else).

But for a .DIR item without a slash within it (e.g. "myapp.DIR" as opposed to "csp/user.DIR", line 653 is ineffective and Exists("myapp.DIR") returns 0.

This could be fixed by moving line 657 ahead of line 653, then amending that line (now 654) to add ext="dir" to the existing OR conditions. However the entire %Studio package no longer appears in the latest Class Reference (aka Documatic), so I reckon the chances of this getting fixed are low, and of being backported even lower. I'm posting the information here in case it's useful to anyone else. A workaround is not to use webapp names that have a single path component.