[RESOLVED] How can my windows program reinstall itself when there's a new version?

[MMock]

I wrote a WinFomrs application that my users install using setup.exe and an msi file.
When the user starts the application I want it to recogize when there's a newer version so the user can update.
This is how I am doing it. I would appreciate your input to know if this is the right/best way.

        static void Main()
        {

            string thisVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString();
            // Cut off the 4th component, Revision.  I am not using it.
            int idx = thisVersion.LastIndexOf(".");
            thisVersion = thisVersion.Substring(0, idx);

            string currentVersion;
            using (tableAdapters.QueriesTableAdapter qry = new tableAdapters.QueriesTableAdapter())
            {
                currentVersion = qry.qryAskConfigurationForCurrentVersion();
                if (thisVersion != currentVersion)
                {
                    if (MessageBox.Show("There is a new version.  Would  you like to install it now?", "Update Required", MessageBoxButtons.YesNo, MessageBoxIcon.Information) == DialogResult.Yes)
                    {
                        try
                        {
                            System.Diagnostics.Process.Start(@"\\blah\blah\blah\setup.exe");
                        }
                        catch
                        {
                            ;
                        }
                        return;
                    }
                }
            }


            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            //Application.Run(new frmCaseFolderLauncher());
            Application.Run(new frmCaseFolderLauncherEnhanced());
        }

One thing I am not crazy about is if I say yes I would like to install it now, it asks me if I want to repair or remove it. If I chose repair I believe that works but I don't know if the users will get thown off because it's not really a repair, it's a reinstall. So as I said, I am not sure what I've coded is the ideal solution. Thanks.

[PlausiblyDamp]

I wrote a WinFomrs application that my users install using setup.exe and an msi file.
When the user starts the application I want it to recogize when there's a newer version so the user can update.
This is how I am doing it. I would appreciate your input to know if this is the right/best way.

        static void Main()
        {

            string thisVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString();
            // Cut off the 4th component, Revision.  I am not using it.
            int idx = thisVersion.LastIndexOf(".");
            thisVersion = thisVersion.Substring(0, idx);

            string currentVersion;
            using (tableAdapters.QueriesTableAdapter qry = new tableAdapters.QueriesTableAdapter())
            {
                currentVersion = qry.qryAskConfigurationForCurrentVersion();
                if (thisVersion != currentVersion)
                {
                    if (MessageBox.Show("There is a new version.  Would  you like to install it now?", "Update Required", MessageBoxButtons.YesNo, MessageBoxIcon.Information) == DialogResult.Yes)
                    {
                        try
                        {
                            System.Diagnostics.Process.Start(@"\\blah\blah\blah\setup.exe");
                        }
                        catch
                        {
                            ;
                        }
                        return;
                    }
                }
            }


            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            //Application.Run(new frmCaseFolderLauncher());
            Application.Run(new frmCaseFolderLauncherEnhanced());
        }

One thing I am not crazy about is if I say yes I would like to install it now, it asks me if I want to repair or remove it. If I chose repair I believe that works but I don't know if the users will get thown off because it's not really a repair, it's a reinstall. So as I said, I am not sure what I've coded is the ideal solution. Thanks.

Rather than deal with it yourself have you considered ClickOnce instead?

[MMock]

Yeah, I considered it. I guess I will consider it some more. Thanks.

[MMock]

We considered it and decided not to use it for this particular program.
The feedback I received from the engineer here who sometimes wears a developers hat, is that the code I wrote is fine so I'm going with it.
Thanks for your time and sorry to be stubborn. Our main application is click once but we want to do this application differently.

[jg.sa]

I think you need to be thinking about how to run your system from a USB stick.

When we started to think about that we realised you shouldn't have a setup image and need to be thinking about a configure and update option in the menus.

Let the user choose when they want to upd. etc.

Just my 2c worth

[MMock]

No one is running it from a USB stick. The application is internal to our company and only used by employees on their laptops.

[FunkyDexter]

One thing I am not crazy about is if I say yes I would like to install it now, it asks me if I want to repair or remove it.

I believe that's a function of how you build the installer package. I've got a piece of software that we use InstallShield to build the msi for. In that you have to set up an "Upgrade Path" for your application and then change the product code every time you build. That essentially tells the msi that this is a different version of the same application so it does a replace rather than a remove/repair.

If you're using InstallShield this is fairly easy to find once you know what to look for. If you're using something else I'm willing to bet it has something equivalent.

Edit> NB. Both your code and the upgrade path on the installer will identify an older version as newer (they're really just identifying a different version). ClickOnce would take care of that for you but your own code could also be trivially changed to handle this a bit better:-

if (thisVersion != currentVersion)

should probably be:-

if (thisVersion > currentVersion)

You might then consider adding Less Than case that advises the user that they're installing an older version. This might be a bit overly pedantic though.

[MMock]

Thanks, @FD, I believe I took care of that since posting when I was testing:

            string currentVersion;
            using (dms1DataSetTableAdapters.QueriesTableAdapter qry = new dms1DataSetTableAdapters.QueriesTableAdapter())
            {
                currentVersion = qry.qryAskConfigurationForCurrentVersion();
                //if (thisVersion != currentVersion)
                if (Convert.ToInt32(thisVersion.Replace(".", "")) < Convert.ToInt32(currentVersion.Replace(".", "")))
                    {
                    if (MessageBox.Show("There is a new version.  Would  you like to install it now?", "Update Required", MessageBoxButtons.YesNo, MessageBoxIcon.Information) == DialogResult.Yes)
                    {
                        try
                        {
                            System.Diagnostics.Process.Start(@"\\blah blah blah\setup.exe");
                        }
                        catch
                        {
                            ;
                        }
                        return;
                    }
                }
            }

It's in the hands of some beta users now so I will see if they have any problems with it.
Thanks!

[Axcontrols2]

I have a client application. It's in two separate executables.

1. Launcher.exe
2. MainApp.exe

The desktop icon that the user uses to start the program starts Launcher.exe

Launcher.exe compares the local version of MainApp.exe with the copy on the server. If the version on the server is newer it copies it down, checks the signature and then overwrites old MainApp with new MainApp.

Launcher.exe then executes MainApp and Launcher.exe closes itself.

I do not ask the user. If a new version is on the server then the user has no choice.

[MMock]

@Axcontrols2 - I like this. I am asking my boss to get her blessing. Thanks.

[jg.sa]

G'Day MMock

Once you have a launcher, you can

- Pass an activation code, not necessary via params
- Have images without the extension .exe, we use .sas
- Encrypt .sas so it can only be decrypted by launcher into memory and JMP
- Check licensing count and config. in launcher not in each app. - this is really cool downstream effect
- Add scripting engine to launcher and modify functionality via scripts not code changes

BTW - In some countries like .au and .nz it is illegal to change config. without getting permission 1st

[MMock]

@Axcontrols2 - I do believe I want to implement your method. I need some holes filled in.

1. How does launcher.exe initially get installed on every user's computer.
2. What does launcher.exe look at to compare the user's local version with the server version? How I am doing this currently is I have a database table xtblConfiguration where we maintain one row of static data for various purposes, so the column I use for this is called CMSCurrentVersion and I update it every time I update the CMS App executable (equivalent to your MainApp.exe). But where is the user's local version stored? Currently I am going to the registry, but that is only because I am currently installing CMS App.exe using MS setup.exe so it gets written out to the registry.
3. When you say Launcher.exe copies down the new version, how does it know the destination and are there situations when the copy to the user's local computer wouldn't be allowed?

Thank you again. The concept is straightforward but I am having trouble with these details.

[MMock]

@AxControls2 or @FunkyDexter, if you guys are still listening...
I now have 3 projects in my Visual Studio solution - the original CMS App application and the original CMS App Setup application which installs CMS App.
I added CMS App Starter. So going back to post #9 this is equivalen to Launcher.exe and CMS App to MainApp.exe.
Regarding "The desktop icon that the user uses to start the program starts Launcher.exe" - that means I need a desktop icon for CMS App Starter. How does it get there? Do I need a 4th project in my solution which would be a setup for this program? It would only be installed once because it would never change. Its job is to recognize when it needs to install a new CMS App.
I've written mostof this and it works except I want to make sure I'm not over-complicating the scenario by thinking I need another setup (yet to be written) because without it I am not sure how to get CMS App Starter out to my users.
Thanks.

[MMock]

OK, this is pretty much done and here is how.

I have two solutions because it's easier to keep them separate. I had one solution with 4 projects and I somehow managed to mess up code I hadn't wanted to touch. So now I have CMS App which is the application that will be getting updated here and there and CMS App Starter which is the little application in charge of getting the updated CMS App down to the user.

CMS App is in its own solution with a Setup Project, CMS App Setup.
CMS App Starter is in its own solution with a Setup Project, CMS App Starter Setup. Ideally, CMS App Starter will get installed once on each user's machine and never again have to be touched. So one time only, users will be instructed to go out to our server and run CMS App Starter\setup.exe.

CMS App Starter is a desktop icon on the user's machine and is listed in Programs->Start and the user can run it in one of those two ways.
CMS App does not have a desktop icon nor is it listed in Programs because I don't want the user starting it directly. It has to be started throught the Starter who keeps an eye on new versions.
Every time CMS App has a code change, I rebuild it and its setup and I update the record in xtblConfiguration, column CMSAppCurrentVersion. This value is kept in sync with AssemblyVersion in AssemblyInfo.cs. I copy setup.exe and the msi file to the server.

When CMS App Starter runs, it reads xtblConfiguration and gets latestVersion then it reads the Windows Registry, finds CMS App and gets appVersion and compares them. If the same it tells the user it's up to date, hit ok to run. If different, or if CMS App wasn't found in the registry because it's the first installation, it calls InstallNewVersion() which runs CMS App\setup.exe on the server. It runs it asynchronously so it can wait. Next, all three paths call StartCMSApp() which goes into the registry to get the path where CMS App was installed and runs it. The starter closes. The user runs CMS App all day long. I go home and have a nice glass of wine because this was exhausting and I am still not 100% sure of it but I guess that why God invented testing.