When delivering Windows apps built with Xojo I bundle the Windows Runtime with the app due to the high rate of failure I’ve personally had with the runtime installer. I have a client who does not like the way the DLLs must be on the same level as the executable. Before offering them the runtime installer I’d like to offer some other solutions.
One I came up with is bundling it like a Mac app:
My App Directory
- Shortcut To My App.exe
- Resources
| - My App.exe
| - My App Libs
| - My App Resources
| - Runtime DLLs
I’d like to ask the Windows experts here if something like this might work?
Would the shortcut have to be created by the installer, or is Innosetup smart enough to handle a shortcut bundled inside?
This assumes the user will be looking in the app folder inside Program Files.
Most users just interact with the app icon
That lives on the desktop or start menu.
So if you install everything inside a folder called resources, its much the same as installing it in a folder called MyApp
This ‘up one level’ shortcut isnt normally ever going to be seen by the typical end user.
The DLLs will still be at the same level as the app,
The method above wont fool a busybody like the one you describe here.
But what difference does it make to them?
To deter the casual user, I set the Resources folder to be hidden in my installer.
It wont fool the semi-power users either.
You might try this:
My App Directory
| - My App.exe
| - My App Libs (hidden)
| - My App Resources (hidden)
| - Runtime DLLs (hidden)
But surely the questions are:
Does the app work?
Does it do anything illegal?
Did it break anything else?
If the answers are yes, no, and no, then what’s their problem?
The end user may be looking inside that folder. The client places certain app setup files next to the app.
This request comes from the client, so I can’t really tell them that it’s not the average use case
My idea was to kind of shuffle away all the resources, so setting all of the runtime DLLs to hidden might also work.
Thank you for that idea!
I’m experimenting with different ideas, so I’ll have to come back with answers.
This article is 1999 but the search path remains the same to today’s Windows. The last option in the article may offer a solution but writing to HKLM may require special care from the installer. I have avoided writing to HKLM for many years.
I have not tried the method. Just letting you know there is this option.
Sure
My point is that this sort of thing isn’t “abnormal” on Windows
That some still want it to be nice & clean without all the clutter requires fun “workarounds” as this sort of set up in Program files with tons of dll’s next to the exe is perfectly normal
The short cut should work as it’s not much different than one on the desktop
[quote=291259:@Cho Sing Kum]This article is 1999 but the search path remains the same to today’s Windows. The last option in the article may offer a solution but writing to HKLM may require special care from the installer. I have avoided writing to HKLM for many years.
I have not tried the method. Just letting you know there is this option.
I doubt this will work with the VS 2015 redistributable DLL’s and allow you to move them
We very diligently tried to do this so they would all be in the Libs folder like all other DLL’s
Those efforts didn’t work and you have what you see today
Honestly EXEPT for Windows 7 every other Windows version should install them system wide - and I believe with Windows update they are all installed system wide so they get security patches & updates
Then they do not need to be next to your app’s exe and all the clutter is gone
Customers who look in the Program Files directory are the exception, not the norm.
I rather have once in a while a loonie who does not like DLLs (God know what else he messes with anyway ?) , and a quasi totality of satisfied customers who use the installer, as is standard under modern Windows.
You cannot distribute a solution for idiots stuck in the dos era, anyway.
You are joking right? One client is complaining? Unless he pays a huge amount of cash for your app I would just ignore him and focus on developing your apps. If he doesn’t like it, then I suggest your client to use something else.
Seriously, that customer has more time on his hand to complain instead of using your app.
Look, we’re not disagreeing with any of you. We think it’s silly too. But the consulting client doesn’t like it so we’re investigating alternative solutions.
You can continue to harangue someone paying our bills or come up with an alternative. Otherwise I’ll just ask Xojo to lock the thread and move on.
Sure, there are different sorts of customers. In my opinion, prêt à porter, off the shelf software, should come with an installer, as is.
Bespoke software is a completely different case. Customer is defining the perimeter of the app, and if he prefers C redistribuable installer over DLL, that is his prerogative. I would suppose that a company that hires a contractor is able to have a software management policy that includes installing this kind of software.
This is not for Answers.
This is for a client of ours who delivers a product to their customers.
Client of ours adds a config to the folder that comes out of Xojo. Client of ours would like to hide the runtime DLLs because they may or may not need their customer to go into this folder, and client of ours knows that customers are not always up to date.
We are only looking for workarounds to using the redist installer, and cannot pass these remarks to the client.
On macOS you can hide files ( folderitem.hide=true). Not sure if this is possible in Windows though.
Edit: it is possible in Windows. So just initiate all the files when you launch your app and set the .hide property accordingly.
After the first launch of your app, all those files are not visible anymore.
Jeff’s idea is good. It is perfectly possible indeed to make the DLLs invisible. I have no idea if they will still work as expected. But that could be a solution.
Whats the likelihood your user would have “show hidden files” turned on ?
If they do the shortcut to the app like you outlined first to fake an OS X bundle might be a better option as even when they go into that dir there are no hidden files. Just a short cut to the app exe itself
Either way it sounds like you have a few possibilities without having to resort to a packer which is good as some have issues with packaging 32 bit Xojo apps
[quote=291277:@Norman Palardy]I doubt this will work with the VS 2015 redistributable DLL’s and allow you to move them
We very diligently tried to do this so they would all be in the Libs folder like all other DLL’s
Those efforts didn’t work and you have what you see today
…
[/quote]
I just tried this on a fresh Windows 7 x64 install. And it works!
