1

I am having a very annoying problem.

I have an application with a setup project included in the solution that builds a .msi. I use VS 2008. I have incremented the version of the setup project - selected the project in solution explorer, pressed F4, and incremented version, and modified "Manufacturer" and "Author" fields. I then rebuilt the application and the setup project also afterwards.

The most bizarre thing happens then: when I run the resulting .msi file in a non-silent manner, it installs the latest version in the correct C:\Program Files (x86)[Manufacturer]\ path.

But when I call the setup file from the application code, with the silent arguments:

processStartInfo.Arguments = "/i " + "\"" + file + "\"" + "/qn";

...then it installs the previous version (the one before incrementing the setup project version) and also it installs it in the old manufacturer path.

Is the .msi setup file storing two versions inside it that hold different variables/ setup properties?! I am stumped and very annoyed, I have now lost four hours on this issue. I have deleted temp files. I have verified the correct .msi is in the correct path a dozen times.

I need to force the .msi to consider the updated setup properties when installing with silent argument as well.

Here is the code from the application that calls the setup:

    private static void RunSetupFile()
    {
        string file = Path.Combine(Utils.GetAppTempPath(), Utils.ApplicationUpdate_SetupFileName);
        ProcessStartInfo psi = new ProcessStartInfo(Path.Combine(Environment.SystemDirectory, "msiexec.exe"));
        psi.WindowStyle = ProcessWindowStyle.Hidden;
        psi.Arguments = "/i " + "\"" + file + "\"" + "/qn"; 
        psi.UseShellExecute = true;
        psi.Verb = "runas";
        try
        {
            Process process = Process.Start(psi);
        }
        catch (System.ComponentModel.Win32Exception)
        {
        }
    }

And below is the code that calls the above method, perhaps here is the culprit:

    public static void InitializeAppUpdate()
    {
        DownloadNewSetupVersionFromServer();
        RunSetupFile();
        Utils.CloseApplication();
    }

Thank you for any idea. Let me know if I should provide more details.

Amc_rtty
  • 3,662
  • 11
  • 48
  • 73
  • Did you try creating a verbose log (/l*v "") to see what happens exactly with your installation path? – Cosmin Sep 22 '11 at 17:53
  • yes i have saved a setupLog.txt file. It reports no error and exits with setup successful and state 0 - as i said the application installs successfully, it's just that it installs a previous version and in the old path. – Amc_rtty Sep 22 '11 at 18:45
  • Can you post it somewhere so we can take a look? What happens when MigrateFeatureStates action is executed? – Cosmin Sep 22 '11 at 18:46
  • Of course - I have uploaded the file on http://andreicristof.com/setupLog.zip . When setup is silent, it installs version 1.0.12. If it's non-silent, it installs 1.0.13. I should also note that I use the custom action javascript from here: http://stackoverflow.com/questions/1668274/run-exe-after-msi-installation/1681410#1681410 to have the application run after installing, so perhaps that helps. – Amc_rtty Sep 22 '11 at 19:02
  • Please also see the edit I just added to the post, containing the code that calls the method which runs the setup. – Amc_rtty Sep 22 '11 at 19:32
  • So pretty much what I assumed. Did you try debugging to see what happens? Perhaps you are downloading the wrong MSI. – Cosmin Sep 22 '11 at 19:38

1 Answers1

2

The log seems ok and I'm pretty sure the problem is not caused by the package.

The only causes I can think of are an incorrect path or an incorrect MSI file. Based on your code I assume you're trying to handle some sort of update, perhaps with a downloaded MSI file.

Try debugging your application to see what path is stored in file variable. Right before executing Process.Start go to that path and check the MSI:

  • open it with Orca
  • select Property table
  • check the Manufacturer and ProductVersion properties

Perhaps it's the old MSI file and not the new one. If it isn't, try running the command line manually with and without /qn right before Process.Start.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
  • 1
    i always fail at these very incredible simple things. it was so obvious. the server path was wrong i was downloading an older version. thank you for your help. – Amc_rtty Sep 22 '11 at 19:39