Console + Desktop apps sharing framework?

Hey guys, we are trying to figure out how to have a Console app and a Desktop app, both run from the same folder, and share the same Libs and Resources. This has proven certain difficulties depending on the platform we are running on.

For example, when run in Debugger mode, in Windows, we have a Copy Files build step to copy the already compiled console app to the parent folder of the desktop executable file, and all missing libraries (only those that are not already generated for the Desktop app) to the corresponding DebugMyApp Libs folder. The problem is the console app cannot locate the dll files.

On the Mac side, we tried putting the console app exe file inside the MacOS folder where the desktop app exe file is located, and then the missing framework libs for the console app within the corresponding Framework folder. But then again, the console app is unable to locate those files. Then we gave up on that and placed the whole Libs and Resources folders inside the MacOS folder, and even though that works, we end up having an issue when code signing the App bundle because of the Resources folder containing .lproj folders within it and, I guess, somewhat breaking the whole Bundle pack structure.

My question is: Is it possible to change the Libs/Resources lookup path for a console app at compilation time? Or is there another workaround?

Your inputs are very appreciated.

Although I have not tried this for your specific problem I have been successful in using SmartPacker Pro to bundle a Windows App into a single EXE file ( which is available on the Xojo third party store.

I would assume this would allow the command line program to run and be placed in the same directory as other Xojo programs that have different libraries.

This won’t be a free solution but maybe an option. And it is a Windows only solution.

Rename both app’s folders to Libs and Resources. Be warned though that both versions MUST be built with the same IDE version.

Edit: On Mac your options are limited. Probably have to use symlinks.

@Thom McGrath, I guess that may work for Windows, but not while running in the debugger…

On the other hand, we still have the issue with Mac…

On Linux and Windows this should work fine.
At least the Visual C Runtime files and the Plugin DLLs can be shared.

@Christian Schmitz , and how would you go about solving the code signing issue with the Mac, and is there a way to avoid duplicating shared libraries on the Mac too? We tested moving those into the Framework folder, but the console app is not able to find them there…

To be fair, do you really need this to happen during debug?

You can perfectly well copy your console app and folders within the /Contents/Helper folder of the bundle with a CopyFile after the build in Mac, so it runs in debug.

I see that you have started two threads, then closed the one I had tried to precisely answer how to place console or other helpers in the bundle :confused:

Well, with code signing, you better don’t do this.
On Mac you can merge several console apps in one GUI app bundle.
Than you need to sign things from inside to out.

If Sam Rowlands who is AFAIK the best specialist about sandboxing in this forum recommends placing helpers in /Contents/Helpers, I’ll blindly follow his advice, and use App Wrapper to sign, so I don’t have to deal with undue nitty-gritty.

He usually never posts anything without having tested first anyway.

You can store the console application in any of the following:

  • MacOS
  • Frameworks
  • Plugins
  • Helpers

You must keep the console apps libraries in the same relative location, putting them in the main bundle’s frameworks folder will not help. Apple have always advised against executable code in the Resources folder, it’s only now that’s actually enforced. App Wrapper used to warn developers, but I got a load fo complaints because it always worked, until Sierra that is.

I did some experimentation with App Wrapper, when it tried to dynamically merge a console application’s dylibs with the main executable’s. It was an absolute failure. I was able to use symbolic links okay, but I found that some dylib for console application are different than the GUI counterparts.

Merging multiple console libraries folders is fine (providing their built at the same time from the same version of Xojo with the same plugins).

In the last years people stopped worrying about app sizes. So it may be that the whole topic is not worth the trouble.

I agree with Christian, but within the last year I had a client inquire about getting my app size to < 500KB. This was not for some specialized hardware, but apparently some strange IT department rule from the 1990s. Sigh.

Are you talking about OS X or Win32?

On OS X you can do this with ‘otool’


Client is king, but sometimes king of idiots. < 500 KB is so last century …

The solution I found for AppleLib includes a bit of manual file tweaking, but it seems to be workable:
Like you, I host two different platforms which share a lot of common code.
The folder structure is like this:

Project Folder { Shared Files Folder {} macOS project folder {} iOS project folder {}}

Everything that is shared is saved into a subfolder in the Shared files folder. So when I finished a class on Mac, I make it external, save the class or its whole folder as external and copy this object via Clipboard into the iOS project.

I found out that this might interfere with Xojo’s trackkeeping of the files, so after uploading to a repository the projects looked in their own folders instead of the shared folder one level above.
The solution was to edit the project file – when I found a file in the mac project that points to macOSFolder/Shared Files …, I changed this to …/Shared Files …

Best practice to keep this working is to avoid saving over it if Xojo should have crashed before – the links might be reset then.