views:

99

answers:

4

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?

+1  A: 

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.

Eric J.
Thanks ... that is perfect except that it requires a well-known location for the listener. For the moment I'm going to use mailslots, but if that doesn't work out then I'll adopt your approach instead.
Eric
A: 

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.

Neil N
A: 

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)

BarrettJ
From a usability standpoint, doesn't this get frustrating for the user when they want to run their application *now* but instead they have to wait for the latest release to copy down? Do you provide an option which lets them postpone the update until later?
BenAlabaster
I don't (nor has a user ever once complained); with the caveat that this is going over our local intranet and all the files total are less than 5mb (only updated files are actually transferred). Additionally my program runs at startup, so the time is further hidden by all the other programs people have going at startup.
BarrettJ
Wouldn't this give you a similar result to Click Once deployment?
Glenn Condron
I'm not overly familiar with ClickOnce, but my understanding was that it doesn't install the application in Program Files and can only install certain prerequisites. Additionally users where I work are not allowed to install applications themselves (Limited User Accounts), it was not included in my sample code but in my application I have code to impersonate another user that does have permission on the application directory.
BarrettJ
A: 

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.

Eric