It can be used either interactively or as a Scheduled Task (with the needed parameters passed as arguments in the command line). Until this morning, I've been running it myself from my laptop and updating the jpg's on the units manually about once a week. This really doesn't work for me. I'd much rather have the whole stupid process completely automated, but we're having some network issues that prevent the screens from communicating with our server room (UP&P is being blocked at the router). So until that is fixed (pr: circumvented), the jpg's have to be updated manually with a thumb drive.
Before I go any further, I should explain a little about what the app is actually doing. It opens a Powerpoint 2007 document, updates its content with information provided by the National Weather Server, Google News, and a web service from our local web server (for the course location information). Powerpoint really wasn't needed, but it did make it easier to design the slides.
So, like I said I've been running this from my laptop. I decided that it would be much better to try to put the executable right on the thumb drive and set it up so that anyone could use it. After copying the executable to a thumb drive I tried to run it from another computer (other than my laptop). I had already suspected that I would have some problems since the app is referencing the Powerpoint 2007 interop DLL, which is exactly what happened. Powerpoint 2007 had not been installed on this particular - I had chosen this set up on purpose to see what would happen.
So here was the question: How can I run this executable from a computer that doesn't have the Office 2007 DLL's on it, without having to acutally install this app?
Since I'm normally focused on Web apps, I haven't had to deal with this type of problem before. So after a little exploring in Visual Studio...
In Visual Studio, if you select the specific Reference in question (in this case the Office and Office.Powerpoint references), the IDE will expose several properties of the specific References in the Properties window. The one that I immediately focused on is called "Copy Local". This property indicates whether the reference will be copied to the output directory. After setting this option to "True" for both of the non-.NET DLL's, I rebuilt the app, copied the executable and both DLL's to the thumbdrive, and off to the "other" computer I went.
With the DLL's now in the startup folder of the executable, the app ran just fine. So next time you're at the ITTC, check out our new LCD screens powered by this little app.