WIndows 64-bit Runtime Omnis 10.1

[Paul Mulroney]

Hi Scott,
I’ll say “me too” – we’ve had the same issue. First time you launch the app for a user, it seems to take a long time and there’s no visible indicator to the user that anything is happening. Sometimes we’ve had users try to launch twice, and then we get weird errors about “file already exists”.
We have our libraries etc setup in the firstruninstall folder for the app, but we also make sure that it can handle it’s own update the first time the app launches. For example, if you add a new user to the machine after a long period of time (and a few updates!) you want to make sure that your libs in the firstruninstall can be updated automatically without falling in a heap. For our system, we have “LAN Updates” folder on the client’s server, and the app can check the contents of the folder and install updates before proceeding.
Hope this helps!
Regards,
paul.

[Scott]

Hi Paul,
That’s great I’m interested to hear more about how you implement this server that from what I understand copies files to other user profiles. Our case is a bit different. We allow our clients to download our application install it on their workstation this workstation connects to our cloud servers “database servers”. So we don’t install any kind of local server components and we don’t want to install files on each user account unless the user is actually using the software. So I don’t think this solution will work for us, but I would still love to hear more in case there is any ideas we can generate from your works.
Thanks so much for sharing. Be well!

[Paul Mulroney]

Hi Scott,
When we deploy to businesses, they typically have a server, and we have either Postgres or the Omnis Databridge installed on that server. Each workstation has a config file that points to the database. We set it up as an INI file, so we can have other parameters including the location of the LANUpdates folder. When they first run the software in their user profile, it will ask them where the LANUpdates folder is. When they locate it, it copies all the other parameters like database connection details etc to the user’s AppData folder. Once they have the connection details, it can then query the database for the latest version and download the updated libs to their profile.
If you don’t have any kind of central server, but you want the software to be same across profiles on the workstation, perhaps you can use a central location such as the “Program Data” folder? The local app data profile still has some Omnis components, but you could have a “startup library” that points to the actual libraries in the Program Data folder, so that all profiles access the same libs.
Regards,
Paul.

[Scott]

Thanks Paul, I appreciate you explaining your process, so every windows users on a the workstation your omnis app copies the entire contents of AppData/Local from the server?
May I also ask which version of $O you are using?

[Paul Mulroney]

Hi Scott,
Thanks for your message.

so every windows users on a the workstation your omnis app copies the entire contents of AppData/Local from the server?

To clarify, Omnis copies everything from the firstruninstall folder into the user’s local app data. Once that’s copied over (and that’s a one-time thing, when the app is first launched in the user’s profile), our software then copies our libraries from the server into the local app data > omnis > startup folder. That process is a lot faster than the first copy, and they’re really the only components that change.
There’s no workaround for copying into the user’s app data folder, except to make the Program Files folder writable, and that’s frowned upon by Microsoft. If you make the program files > omnis folder writable, then you can do away with the firstruninstall folder, put everything in the Omnis application tree like we used to do prior to UAC, and you get the desired result – one set of libs for all users on a workstation. Not sure how that will work in Windows 10, we stopped doing that since Windows 7 was first introduced.

May I also ask which version of $O you are using?

We’re currently using Studio 8.1, but we’re working to update our clients to 10.1. We still have some clients using O$ 5.2, so it’s a bit of mix of versions right now. The same principles work on all versions.
Regards,
Paul.

[Scott]

Appreciate all that info Paul, unfortunately the copying from the firstruninstall folder to the AppData with no notification is a bit of a sticking point. We’ve always tried to make it easy for almost any user to install our application. Many times people will install without the help of an IT professional, even with one the process is pretty opaque. I’ve had people on my staff have double launch the app I think it’s just intuitive to do so when you see no indication of it launching. At least on Mac you see the app launch.
I guess we’ll limp along right now, I’m sure we’ll find a way around this it will just take some time and some time. I’m surprised this isn’t something that’s been worked out by now since it’s been around for quite a while. We’ve only recently upgraded to 10.1 from 4.3.2.1.