IDE script now adds .app to CurrentBuildAppName breaking scripts

I’ve been chasing a post-build IDE script issue for a bit now and just uncovered the change in 22r1.1 that changes the behavior of the CurrentBuildAppName property to now include the .app extension. This breaks scripts where we need to drill down to the actual runtime inside of the app bundle.

Was this change on purpose or an oops?

On purpose

1 Like

This change was intentional for consistency. You can now consistently expect the application extension is part of CurrentBuildAppName.

This was changed for 2022r1.

1 Like

Shouldn’t that really be a new property - CurrentBuildAppBundleName?

1 Like

I think that debate has long since passed (there were discussions and warnings about this during the pre-release phase).

Luckily, updating shouldn’t be too hard, just search your script for + ".app" and you’ll find all the spots you have to change. All you need to do is delete that.

Not so easy - how do I convert the search to just the name WITHOUT the .app? My builds result in 5 sub-apps within the main bundle. To harden them, I need to go to the specific runtime, not its bundle. I will need to hard-code the names in the script - which obviates the usefulness of the existing property completely; you may as well have removed it.

If you’re navigating to a path inside the bundle, you very much so need the .app on the end.

You’ve confused me a little with what you need to do. Why do you need the app without the extension?

You could quick and dirty get that value like this probably:

var sApp as String = CurrentBuildAppName.Left(CurrentBuildAppName.Length -4)

theRes = theRes + DoShellCommand(“codesign -f --options runtime -s ““Developer ID Application: Other World Computing (Q9P8K45M5C)”” “”” + CurrentBuildLocationNative + “/” + CurrentBuildAppName + “/Contents/MacOS/” + CurrentBuildAppName + “”“”, 20000)

The second instance is now Broken

The reason this function changed is because the first instance is broken on some configurations with older IDEs. That script really should have included CurrentBuildAppName + ".app/Contents/MacOS/" for reliability, but I’m glad it was working.

Do you have a lot of these to convert? This might help:

var sExecutableName as String = CurrentBuildAppName.Left(CurrentBuildAppName.Length - 4)

theRes = theRes + DoShellCommand("codesign -f --options runtime -s ""Developer ID Application: Other World Computing (Q9P8K45M5C)"" """ + CurrentBuildLocationNative + "/" + CurrentBuildAppName + "/Contents/MacOS/" + sExecutableName + """", 20000)
2 Likes

That will resolve it. I was unclear on just how much of the main language is part of the IDE Script language. Thanks.

Just to be clear, the reason this was changed was that previous to 2022, whether or not CurrentAppBuildName included the .app extension was dependent on whether you had the Finder preference to always show extensions turned on, so it was possible for the behavior to change depending on the system the script was running on.

This setting never changed the “.app” in any state, checked or unchecked. On our system “always show extensions” checked or unchecked never did any thing to xojo other than “showing” the extention in finder things.

What I can tell you is that the underlying code used FolderItem.DisplayName which definitely follows the Finder setting on my system.

You can fix this for your scripts by doing something like this:

Dim appName as String = CurrentAppBuildName
If right(appName, 4) = ".app" then
    AppName = left(appName, len(appName)-4)
End if

And then just use appName in your script, and it’s backward compatible.