How to develop and deploy a launcher application?

[VinnyAstro]

Hi,

It is more out of curiosity, but also it will be useful to me later:

How to develop and deploy a launcher application?

Typically, over the years I have developed a few (labview) applications for my company, some other colleagues have also developped (non-labview) stuff. And I would find interesting to have have 1 launcher that can:

• Gather all tools and applications in one window, showing their versions and usage
• automatically maintain applications versions by server checks
• Simply look nicer to have our own company panel rather than having to look for an app in a specific folder (believe it or not, my colleagues can be creative when we tell them to do a simple update on a machine)

Essentially that would be "just" a .exe that runs other .exe...

Another advantage would be to have one single installer that would install all driver and applications at once for new PCs (even if it's by executing various installer), rather than to having to install them all manually.

How do you deal with such thing?

• In term of development, I suppose its own project file
• What specific tool in the Installation builder do you use?
• Any tips and tricks and good measures to keep in mind?

Thanks,

Vinny.

PS: I also just like the idea of creating my own fancy splash screen.

[aputman]

For a splash screen, you can refer to my posts here. 

[Jay14159265]

---

@VinnyAstro wrote:

...

How do you deal with such thing?

• In term of development, I suppose its own project file
• What specific tool in the Installation builder do you use?
• Any tips and tricks and good measures to keep in mind?

---

1) I would vote yes for this.

2) It would be a standard app as far as the installer builder is concerned. The question is if you want this new app to only work with local LabVIEW applications or with any application. If you want it to work with any application you will need to create a consistent interface for each of the applications such that for each application you have at least these three calls: 

- open_application (this is the easy one, just call the exe)

- update_applicaiton ( this is a bit harder as each application must have it's own update app)

- get_info this would return some information (like version number, description, image, etc...)  about the application that can be displayed in the app you are developing 

3) The job of updating an application should be handled by another application that can be called by the original app or some other app (like windows settings). In many cases, the updater app should be part of the original app project, not its own project. 

[paul_a_cardinale]

Also, your installer should be able to install:

• Custom menus used by the installed app
• Help files for the installed app

[VinnyAstro]

---

@Jay14159265  a écrit :

2) It would be a standard app as far as the installer builder is concerned. The question is if you want this new app to only work with local LabVIEW applications or with any application. If you want it to work with any application you will need to create a consistent interface for each of the applications such that for each application you have at least these three calls: 

- open_application (this is the easy one, just call the exe)

- update_applicaiton ( this is a bit harder as each application must have it's own update app)

- get_info this would return some information (like version number, description, image, etc...)  about the application that can be displayed in the app you are developing 

3) The job of updating an application should be handled by another application that can be called by the original app or some other app (like windows settings). In many cases, the updater app should be part of the original app project, not its own project. 

---

about 2.2 (update app) would be in most cases fairly easy too as long as it is not the updater that is updated, or I would need an updater for the updater, but at this point I'm happy to ask my fellow humans to do it manually. In most cases our software updates only very rarely involves news drivers or any other windows or hardware specific updates requiring a proper windows wizard installer. So most cases it is about moving the .exe and additional files to the right places.

But I guess updating or installing for the 1st time should be the same task... And I'm fine with having 2 separate apps for that (1 launcher, and 1 updater/installer for the apps). But what would the installer/updater do? Simply execute a .batch file that gives the path for each and every installer files?

---

@paul_a_cardinale a écrit :

Also, your installer should be able to install:

• Custom menus used by the installed app
• Help files for the installed app

---

What do you mean by custom menus? The .rtm?

And with the help files, we're just talking about moving them on disk, right?

---

@aputman a écrit :

For a splash screen, you can refer to my posts here.

---

 Thanks! The splash screen is really the lowest on my prio since we're talking about in-house sw, more of a NiceToHave-LetsGoFancy type of things. I've done one or two in the past, but I'll see if I can make some better ones.

[Peacekeeper]

---

@VinnyAstro wrote:

---

@Jay14159265 MyLabCorp a écrit :

2) It would be a standard app as far as the installer builder is concerned. The question is if you want this new app to only work with local LabVIEW applications or with any application. If you want it to work with any application you will need to create a consistent interface for each of the applications such that for each application you have at least these three calls: 

- open_application (this is the easy one, just call the exe)

- update_applicaiton ( this is a bit harder as each application must have it's own update app)

- get_info this would return some information (like version number, description, image, etc...)  about the application that can be displayed in the app you are developing 

3) The job of updating an application should be handled by another application that can be called by the original app or some other app (like windows settings). In many cases, the updater app should be part of the original app project, not its own project. 

---

about 2.2 (update app) would be in most cases fairly easy too as long as it is not the updater that is updated, or I would need an updater for the updater, but at this point I'm happy to ask my fellow humans to do it manually. In most cases our software updates only very rarely involves news drivers or any other windows or hardware specific updates requiring a proper windows wizard installer. So most cases it is about moving the .exe and additional files to the right places.

But I guess updating or installing for the 1st time should be the same task... And I'm fine with having 2 separate apps for that (1 launcher, and 1 updater/installer for the apps). But what would the installer/updater do? Simply execute a .batch file that gives the path for each and every installer files?

---

@paul_a_cardinale a écrit :

Also, your installer should be able to install:

• Custom menus used by the installed app
• Help files for the installed app

---

What do you mean by custom menus? The .rtm?

And with the help files, we're just talking about moving them on disk, right?

---

@aputman a écrit :

For a splash screen, you can refer to my posts here.

---

 Thanks! The splash screen is really the lowest on my prio since we're talking about in-house sw, more of a NiceToHave-LetsGoFancy type of things. I've done one or two in the past, but I'll see if I can make some better ones.

---

Great insights from everyone! 👏 I agree—having a launcher app paired with an updater/installer makes things modular and manageable. For most in-house apps, a simple file-based updater (copying .exe and required files) works just fine, especially when no driver-level changes are involved. As for installers, using a .bat or script-driven method is simple and effective—just ensure paths and permissions are handled properly. Custom menus like .rtm and help files can definitely be part of the install process—just a matter of placing them in the right locations. And yes, splash screens are fun polish, but definitely optional for internal tools!

[paul_a_cardinale]

---

@VinnyAstro wrote:

---

@Jay14159265  a écrit :

2) It would be a standard app as far as the installer builder is concerned. The question is if you want this new app to only work with local LabVIEW applications or with any application. If you want it to work with any application you will need to create a consistent interface for each of the applications such that for each application you have at least these three calls: 

- open_application (this is the easy one, just call the exe)

- update_applicaiton ( this is a bit harder as each application must have it's own update app)

- get_info this would return some information (like version number, description, image, etc...)  about the application that can be displayed in the app you are developing 

3) The job of updating an application should be handled by another application that can be called by the original app or some other app (like windows settings). In many cases, the updater app should be part of the original app project, not its own project. 

---

about 2.2 (update app) would be in most cases fairly easy too as long as it is not the updater that is updated, or I would need an updater for the updater, but at this point I'm happy to ask my fellow humans to do it manually. In most cases our software updates only very rarely involves news drivers or any other windows or hardware specific updates requiring a proper windows wizard installer. So most cases it is about moving the .exe and additional files to the right places.

But I guess updating or installing for the 1st time should be the same task... And I'm fine with having 2 separate apps for that (1 launcher, and 1 updater/installer for the apps). But what would the installer/updater do? Simply execute a .batch file that gives the path for each and every installer files?

---

@paul_a_cardinale a écrit :

Also, your installer should be able to install:

• Custom menus used by the installed app
• Help files for the installed app

---

What do you mean by custom menus? The .rtm?

And with the help files, we're just talking about moving them on disk, right?

---

It's possible for an app to have custom shortcut (pop-up) menus.  They would be .llb files and would be copied to either:

<default data directory> \PopupMenus\edit time panel and diagram\    (accessible to all installed versions of LabVIEW)

or

<labview 20xx directory> \resource\plugins\PopupMenus\edit time panel and diagram\   (accessible to only LabVIEW 20xx)

Depending on the particulars, help files might be located with the installed app, or in:

<vi.lib directory> \help\<folder for topic>\

[otto__]

am I alone in thinking this is opening a giant can of worms? CI/CD pipelines? Integration to the likes of Azure devops? Am I totally misreading this one?

for me, the basics are: everything needs daqmx, visa, serial

YMMV, of course, just trying to state that you need to know what you need to have

I'd love for my company to be able to deploy labview runtime (2019-present) via MS software center.

Back to the questions:

How to develop and deploy a launcher application?

Make sure it exits labview at the end. Make sure it brute force cleans up after itself. Otherwise, go nuts!... Said somewhat sarcastically, but startup and shutdown both need careful considerations for each unique use case.

----------

Gather all tools and applications in one window, showing their versions and usage

Hooo, so you want something like shared services that are discoverable? You'll be rolling your own framework in no time. I would bet $1 this is a lot of what full time labview devs work on. On a more serious note, you'll need to manage your own way to discover messaging queues or message handlers. This is not something provided "out of the box" by LV.

----------

Automatically maintain applications versions by server checks

I *think* the proper way of managing this is with source code control but I definitely don't know what your specific use case is. Some of (what I am implying) you use case may involve falls back on having a solid service locator-like framework you app is based off of.

You could stick version metatdata into various typedefs or objects as you please and inspect them at runtime. I am also led to believe that the labview object system has a pretty good mutating system that is version aware of changes to its private data, so use that as you please but at your own risk.

----------

Simply look nicer to have our own company panel rather than having to look for an app in a specific folder (believe it or not, my colleagues can be creative when we tell them to do a simple update on a machine)

Templates are a thing. When it comes to internal practices, it really depends on the team. My best results are just to provide a tool or template, make everyone aware, and adhere to best practices. Each group likes or simply must work with files a certain way, so there isnt a one size fits all solution here.

My best recommendation would be to dive into a subpanel architecture for user interfaces, where the main panel has all the company graphics and each subpanel is a strictly defined width and height that gets loaded when a button is clicked from the parent UI.

[VinnyAstro]

---

@otto__  a écrit :

am I alone in thinking this is opening a giant can of worms? CI/CD pipelines? Integration to the likes of Azure devops? Am I totally misreading this one?

---

Well... Of course there's always a very complex way of seeing things, but given our use case, I don't think it needs to be super complicated with our scale: we're talking about 10-20 Computers, 10-15 operators, 1-3 developers, and so far about 5 or 6apps and tools (mix of labview and others), some more complex than others.

So arguably it is not ultra necessary for me to come up with this launcher. But 1. it would look a bit more professional, 2. wee more scalable when updates are generated(*), 3. I would just learn a bit more about labview, and deployment in general (which I know nothing about the latter)

*: Currently, software update are generating both the installer and the .exe and placing it on our servers (with or without Version COntrol depending on the app), and locally copy pasting it on computers .... I am working on getting away from that but it takes time, especially when you're not 100% on this.

---

@otto__  a écrit :

Gather all tools and applications in one window, showing their versions and usage

Hooo, so you want something like shared services that are discoverable? You'll be rolling your own framework in no time. I would bet $1 this is a lot of what full time labview devs work on. On a more serious note, you'll need to manage your own way to discover messaging queues or message handlers. This is not something provided "out of the box" by LV.

---

Why can't that be just having a list of the .exe on your computer (the one we're interested in obviously) and simply reading the logs from the SVN, just checking the version of the .exe on the computer and comparing it to the last version updated on the server?

---

@otto__  a écrit :

You could stick version metatdata into various typedefs or objects as you please and inspect them at runtime. I am also led to believe that the labview object system has a pretty good mutating system that is version aware of changes to its private data, so use that as you please but at your own risk.

---

You genuinely lost me here, I don't get why I would go that deep. 

---

@otto__  a écrit :

Simply look nicer to have our own company panel rather than having to look for an app in a specific folder (believe it or not, my colleagues can be creative when we tell them to do a simple update on a machine)

Templates are a thing. When it comes to internal practices, it really depends on the team. My best results are just to provide a tool or template, make everyone aware, and adhere to best practices. Each group likes or simply must work with files a certain way, so there isnt a one size fits all solution here.

My best recommendation would be to dive into a subpanel architecture for user interfaces, where the main panel has all the company graphics and each subpanel is a strictly defined width and height that gets loaded when a button is clicked from the parent UI.

---

I think this is off-subject. You're talking about graphics within specific apps. I'm talking about 1 application that simply let's the user select which application they want to use.

Once selected the launcher fetches the .exe (locally) and runs it. In case this .exe is not up-to-date confirmed after a quick server check; then the Launcher would executes another app instead (which is the Updater), getting the latest .exe on the server, and placing it at the proper place locally on the machine, then runs the .exe.

My current situation is: Someone made a sw update, puts the .exe on the server, informs the teams to update the computers in the labs. People take the .exe and place it *somewhere on the pc* (often on the desktop and they make sure to delete the previous version.... Clearly not optimised and even dangerous.

What we're working on: Having SVN with lookout folders. Devs create their .exe, and commit it. Employees need to make sure to have their lookout folder up-to-date. That's much better IMO.

What I would like: A launcher that automatically checks the latest sw versions for all apps and gather all their shortcuts in one window. A glorified Shortcut in a way.

[otto__]

Okay, that helps. After a re-read I definitely went too deep in my own headspace because I face similar issues and don't have great answers and got a little excited. I'd like a similar solution, for sure.

A lot of what you want sounds like a plug-in architecture, perhaps a "one executable to rule them all" type of launcher where its aware of all the software your team has created and is a single entry point to a specific built application, without having to constantly rebuild everything when you make an update.

I haven't made something like that myself, but the thought definitely nags me in my own work because my test group runs a lot of similar machines which have their own bespoke executable, so pushing updates feels like it consumes more time than it should.

I *think* you'd be looking at a launcher which uses the factory pattern that loads classes by name, making sure you have good dependency injection as part of your overall architecture, and some sort of discovery service that can identify what's available to load on-demand.