3

I'm using Visual Studio 2010, InstallShield LE on a solution with about 10 total projects.

I've selected the main GUI's primary project output for the 'files' portion, installed to a subdirectory of Program Files, pretty standard.

I built the installer a few weeks ago and installed it on my test machine, everything was working fine. Since then, I've made changes to each project in the solution. Today, I incremented my assembly version and rebuilt my setup project to continue testing.

After installation, in the program files installation directory, I noticed that one of my project's assemblies still lists the previous version, 1.0.0.0, and the file date is over a month old. The other assemblies in the directory show the current versions and current modified date.

I've tried deleting every bin and obj folder in my solution directory and the installer project folder as well. I reinstalled but the problem remains.

I searched google, but as the problem is odd, a good search phrase has been elusive.

Obviously, I need the most current version of my assemblies to be included in the installer msi.

Thanks for any help or suggestions!

Erikest
  • 4,997
  • 2
  • 25
  • 37

4 Answers4

1

You need to do two things: extract the actual file in the MSI to know whether the updated binary is there in the MSI, and get a verbose log of the install looking for what Windows Installer says about the component that contains the assembly in question. Btw, you have each assembly file as the key file of its own component, don't you? Windows Installer only checks for version updates for they paths.

fsimonazzi
  • 2,975
  • 15
  • 13
  • I'm using InstallShield LE, I'm not sure if the "key file of its own component" is something I can manipulate - if so please give me more details on how. Similarly, I'm not sure how to get a more verbose log than what is displayed in the output window during the build, please do tell. – Erikest Nov 16 '12 at 21:08
  • I don't know how you can do it in IS LE, but if you have each assembly in its own component then it will probably become the key path. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa368269(v=vs.85).aspx for the recommendations. As for the log, I meant the windows installer log as described in http://technet.microsoft.com/en-us/library/cc759262(v=ws.10).aspx#BKMK_SetLogging. In the resulting file you will be able to see what happened with that file, and in particular whether windows installer decided not to update it. – fsimonazzi Nov 16 '12 at 21:15
  • But first check whether the updated version is indeed in the installer. – fsimonazzi Nov 16 '12 at 21:16
  • Got the logging worked out, there's a command line switch for the installshield LE setup exe that allows you to pass the logging parameters on to the msi. Looked at the log and didn't actually see my assembly getting installed. Now I'm wondering if there's some assembly cache that it searched through when the installer didn't have the file... At any rate, I modified my installer to explicitly include the offending project's primary output instead of relying on it to be picked up as a dependency and voila it worked. I'm marking yours as the answer because the logging was just what I needed! – Erikest Nov 23 '12 at 15:15
1

I've had the same problem with the VS Setup Project before. I would double-check the assembly references in your solution that reference the project with the old DLL. You should just be able to look at the Properties window to see the version it's referencing. In my case, it would reference the DLL from another project's bin folder, rather than the project itself.

I know you deleted all your bin and obj folders, but it's probably worth a try.

If you find the problem reference, just remove and re-add it and you should be good.

Brandon Dybala
  • 324
  • 2
  • 11
  • All my references for the assemblies that have problems are 'project references'. As part of my sanity check, I did go through and verify each of the references. Additionally, in the actual Bin folders, the correct version is present. It is only in the installer that the file gets reverted to an old version. – Erikest Nov 23 '12 at 15:07
1

Dump InstallShield and go with WiX .. you'll never look back.

WiX has e.g. UpgradeCode to help you control version checks on features.

mhoff
  • 403
  • 4
  • 11
  • Actually Windows Installer Technology has UpgradeCode. WiX and InstallShield just tools which help us create Windows Installers. – Igor Shenderchuk Nov 23 '12 at 08:36
  • @Igor I'm no expert on InstallShield LE, but to my understanding the tool itself only allows a visual (IDE) approach to generating MSI files, which is inferior to the more elaborate WiX XML approach, exposing most MSI details. I've looked up the InstallShield LE way of fidling with UpgradeCode's and found the following [link](http://stackoverflow.com/questions/6447404/configuring-installshield-le-to-remove-previous-versions-built-using-visual-stud). Perhaps it can be of use. – mhoff Nov 23 '12 at 13:41
  • I've been thinking about making this transition for some time. The learning curve always steered me away in favor of something I could throw together more quickly. However, after years of frustration with the limitations of Setup Projects and now InstallShield LE, I can't imagine the total cost of a WiX implementation to be any higher. – Erikest Nov 23 '12 at 15:07
1

You'll want to read:

Default File Versioning

Note: Make sure you are comparing AssemblyFileVersion. It's not the AssemblyVersion attribute that is important rather the AssemblyFileVersion attribute. The former is used by the GAC and Strong Name contracts while the later maps to the Windows Native FileVersion structure.

Community
  • 1
  • 1
Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Thanks Christopher, now I have my versioning set up with * to automatically increment the build version, but alas the problem persists. The strange thing is, the old version of the file can't be found anywhere on my machine.. – Erikest Nov 16 '12 at 20:38