A good broadcast mechanism for inhouse .net applications to announce their location and version?

430 views Asked by At

I would like to provide a large number of inhouse .net applications with a lightweight way to announce that they are being used. My goal is to keep track of which users might benefit from support check-ins and/or reminders to upgrade.

This is on an inhouse network. There is definitely IP connectivity among all the machines, and probably UDP. (But probably not multicast.)

Writing to a known inhouse share or loading a known URL would be possibilities, but I would like to minimize the impact on the application itself as completely as possible, even at the expense of reliability. So I would rather not risk a timeout (for example if I'm accessing some centralized resource and it has disappeared), and ideally I would rather not launch a worker thread either.

It would also be nice to permit multiple listeners, which is another reason I am thinking about broadcasting rather than invoking a service.

Is there some kind of fire-and-forget broadcast mechanism I could use safely and effectively for this?

4

There are 4 answers

1
Eric J. On BEST ANSWER

There are certainly many options for this, but one that is very easy to implement and meets your criteria is an Asynchronous Web Service call.

This does not require you to start a worker thread (the Framework will do that behind the scenes). Rather than use one of the options outlined in that link to fetch the result, simply ignore the result since it is meaningless to the calling app.

0
Neil N On

I did something similar, though not exactly a "braodcast"

I have an in house tool several non-techies in the company use. I have it check a network share for a specific EXE (the same EXE you would download if you wanted to use it) and compares the version # of that file with the executing assembly. If the one on the network is newer, alert the user to download the new one.

A lot simpler than trying to set up an auto updater for something that will only be used within the same building as me.

4
BarrettJ On

If upgrading is not an issue (i.e. there are no cases where using the old version is better), you can do what I did with something similar:

The application that people actually launch is an updater program, it checks the file version and timestamp on a network share and if a newer version exists, copies it to the program directory. It then runs the program (whether it was updated or not).

var current = new FileInfo(local);
var latest = new FileInfo(remote);

if (!current.Exists)
    latest.CopyTo(local);

var currentVersion = FileVersionInfo.GetVersionInfo(local);
var latestVersion = FileVersionInfo.GetVersionInfo(remote);

if (latest.CreationTime > current.CreationTime || latestVersion.FileVersion != currentVersion.FileVersion)
    latest.CopyTo(local, true);

Process.Start(local)

I also have the program itself check to see if the updater needs updating (as the updater can't update itself due to file locks)

0
Eric On

After some experimentation, I have been getting good results using Win32 mailslots.

There is no official managed wrapper, but the functions are simple to use via PInvoke, as demonstrated in examples like this one.

Using a 'domain' mailslot provides a true broadcast mechanism, permitting multiple listeners and no requirement for a well-known server.