unload scripting additions

Generally, Scripting Additions extend AppleScript's dictionary and are automatically loaded whenever a relevant command is executed.

The only way to absolutely prevent this is to remove the scripting addition file(s) from /Library/ScriptingAdditions or ~/Library/ScriptingAdditions but that's clearly not an option if you're planning to distribute your script to other users - you cannot arbitrarily remove Scripting Additions from their machines since you don't know when/if they're needed.

Furthermore, there's no direct way to prevent a Scripting Addition from being used, other than very carefully targeting your commands. For example the call chain that AppleScript uses when looking for a command should be <current tell target>, <default target>, <scripting addition> so if you have a Scripting Addition-based command that conflicts with another, you may be able to circumvent that by telling another application to execute the command, e.g. 'tell application "System Events" to blahblahblah'.

Finally, if the code is yours, then you might need to consider changing some of your handler names/classes so they don't conflict. A poor solution in many ways, but one that's inherent in AppleScript's loose syntax model.

First off, what scripting additions are you talking about, and what is the conflict? It's unusual to find significant conflicts of this sort if the osaxen are relatively well designed, and the only real way to prevent osaxen from loading is to remove them from the ScriptingAdditions folders and quit whatever apps/scripts might be relying on them. however, that will break any scripts that your users might have made with those osaxen and cause a whole lot of consternation/confusion, which will eventually lead them to reinstall whatever osax you removed and break your script.

it's better to just find the problem and fix it in your script (which is usually straight-forward) than go the other route.

for the Adobe Unit Types osax, you might want to read this solutions page. It may give you some ideas for how to deal with the problem. The osax is needed for anyone who applescripts Adobe products (basically it's a collection of custom types that adobe products use, without any actual commands). The osax usually throws warnings rather than errors (because it's just a badly designed osax, I think - Go Adobe!), but I do know how annoying that is. I cringe every time I open console.app and see the long list of complaints recorded there by applescript.

the QXPScriptingAdditions.osax problem (from what I see on the web) may be due to an outdated version of the osax, where it isn't compiled for intel machines. Those osaxen would be at least partially non-functional anyway - they might function for setting up types, like the Adobe osax, but the commands wouldn't work - so you probably wouldn't run into any problems deleting them remotely, since it's unlikely anyone is scripting it. check the version of the osax and the quark app to be sure, and maybe send particular users a note that their version of Quark is out of date and they ought to upgrade. you could try upgrading the osax remotely, but some osaxen are app dependent, and might not play well with older versions of the software.

well, just as a suggestion, you could download a trial version of the latest version of QXP, extract the osax, then toss the trial version out. Osaxen generally don't have any trial limitations built into them (who would bother?), though as I said there may be version dependencies. best thing would be to email QXP support and ask their advice. glad I could help somewhat, though. 🙂