• Facebook
  • RSS Feed
  • Instagram
  • LinkedIn
  • Twitter
Oct 102011
 

I love writing tools.  I hate that I have 10 different versions of them on 8 different PC’s !  So, for quite some time I’ve been thinking of ways of automatically keeping them up to date.  The problem is that these tools run from all sorts of machines, with and without internet connectivity… and I want to keep it (and the tool) simple.

So I set off to think of ways of making things automatically keep up to date, whilst staying simple.

The prototype implementation of this is some assistance that I’ve provided to Paul Juster and Andrew Jones, who live with the DSS project.  This project aims to make some sense out of EV Deployment Scanner Output.  It shows some very valuable information, and is evolving all the time.

Most of the tools I have written, so far, are in VBScript, as is DSS.  I’ve not (yet) put the following in to practice on C++ or C# but it should still work I think.

The Plan
Have the version number stored in the file, as a variable.
Read the currently executing VBScript file, and get the version number by reading it line by line (until we encounter that version number mentioned above)
Download the file from the internet somewhere (Google code seems a good place to me)
Repeat the process of reading the file to find out the version information.

If they don’t match :
    Give the end user some information.
    Give them the option of updating.
    If they want to update then
        Rename the current file to filename.oldversion
        Rename the recently downloaded file to be the filename we’re executing
        Relaunch the file we’re executing with any appropriate command line parameters
       
Do whatever the tool needs to do

Run Through
So the first time through, when there is a mismatch, we update to the latest version, and relaunch.  On relaunch the files will match, so we will continue onwards with whatever the tool is doing.

From a Tool Point Of View
What it means from a tool point of view is that it needs to have stable versions stored out on the internet somewhere.  That’s okay.  It means that when you make a stable version you need to put it on that location out on the internet, and tidy up any other versions if need be.

From an Environment Point Of View
Lots of my VM’s don’t have connectivity to the internet.  This will, for the short term, have to change.   It is easy enough to add an additional NIC which is NAT’ed out of the VM environment.  So that’s also okay.

Summary
Hopefully the above is something that I can start incorporating (largely cut and paste) in to future tools that I develop for myself and others, and will stop me "losing" valuable changes that I make, and then can’t remember which VM I did them on (or worse still… losing the VM’s)

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)