LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mads

New build option: Service

Status: New

It is fairly common to build applications in LabVIEW that are useful to run as a service (monitoring software e.g.) , however to do so today you need to "cheat" and use srvany, and write and run batch files to get it installed. 

 

It would be great if we could build real services, and the installer would take care of the installation process. You could even have a nice template for services with an accompanying user interface client, with notification icon and everything.

 

LabVIEW everywhere...Not just on different targets, but in every part of the system. 🙂 

 

5 Comments
Jim_Kring
Trusted Enthusiast
I've seen considerable energy spend by people to achieve this -- it would be great if it were built into LabVIEW.
altenbach
Knight of NI
It should also allow running the service in the system tray (or linux, mac equivalent?) with an mechanism to modify the tray icon based on service state, for example.
wired
Active Participant

Trying to do this now (the hard way) - what a pain! Kudos given!

GregR
Active Participant

If NI is going to support development of services, we would probably support development based on current best practices. The main guidelines for Windows services is that they be CPU friendly, have no UI and run with limited privileges. The first one we don’t control but the second two we might. Running with limited privileges mainly affects your network authentication, so you probably wouldn’t be able to access network shares. Having no UI means just that. You would not be able to show any dialogs/panels. There are mechanisms that get around this but they are for legacy support and highly discouraged.

 

Items that show up in the notification area are typically not services. In cases where they are related to services, this is typically done with a normal process (running with logged in user’s privileges) that monitors the state of the service.

 

Does a UI-less service really solve sufficient use cases? Is not having network authentication a problem for these use cases (no logging to a network drive, ...)? If providing UI requires some kind of remote communication to the service, are you willing to do that or would that mean you wouldn’t use our solution?

Mads
Active Participant
Yes to all of the above...(access to network drives would be nice, but it is ok to follow the guidelines). think a template for the notification app should be included with labview if bulding a service becomes an option, but thats just to make things more streamlined for the developer. It would also be nice to have a way to communicate with the service that was strictly local, i.e that would not depend on a firewall e.g to be unavailable from the outside). Right now we use TCP/IP for this, but have to take measures to allow local clients (seemingly)authentication-free access while requiring authentication from remote users. This link between the service and notification app could be part of a set of templates included with LV.