Pete
Wed Aug 13 12:26:17 CDT 2008
On Aug 13, 10:44=A0am, "Phil Wilson"
<phil.wil...@wonderware.something.com> wrote:
> One of the other things here is that file sharing (which happens when the
> upgrade is installed over the older product) depends on internal installe=
r
> Guids on each file. You can't see these in the IDE, and Visual Studio
> generates them using an algorithm that *may* (guessing) depend on the fil=
e's
> install path. If something like that changed then some odd things might
> happen. When you do the repair there may be event log entries that descri=
be
> what seems to be missing, Guids will be the ProductCode an and installer
> Component.
>
> These are the installer file replacement rules, and an equal version shou=
ld
> not replace the existing one. =A0Odd!
>
>
http://msdn.microsoft.com/en-us/library/aa367835.aspx
>
> There's a tool called Orca if you feel like seeing the internals of the M=
SI
> files, the Component table will show if the Guids in the old version are =
the
> same as in the new version for files that should be replaced.
>
> --
> Phil Wilson
> Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590=
592972
>
> "Alex Clark" <qua...@noemail.noemail> wrote in message
>
> news:Ogugu1M$IHA.4816@TK2MSFTNGP06.phx.gbl...
>
>
>
> > This does seem to at least partially explain the problem, however it
> > definitely overwrote *some* of my v1.3.0.0 DLLs, despite them having
> > identical file versions. =A0I haven't found any difference in the versi=
oning
> > attribute on those projects so I can't see why it would treat them
> > differently to other binaries in my solution.
>
> > One helluva gotcha though, thanks for enlightening me Phil. :-)
>
> > "Phil Wilson" <phil.wil...@wonderware.something.com> wrote in message
> >news:emBuIpM$IHA.4380@TK2MSFTNGP02.phx.gbl...
> >> Visual Studio 2008 upgrades (RemovePreviousVersions) depend on file
> >> versions, unlike previously. This means you must increase the file
> >> versions of your binaries to get them replaced. This may explain most =
of
> >> what you're seeing. =A0At the end of the install one product remains o=
n the
> >> system, and forcing a repair will force it to verify that every file
> >> installed matches the version on disk.
>
> >> --
> >> Phil Wilson
> >> Definitive Guide to Windows Installer
> >>
http://www.apress.com/book/view/1590592972
>
> >> "Alex Clark" <qua...@noemail.noemail> wrote in message
> >>news:u0R01lL$IHA.1184@TK2MSFTNGP04.phx.gbl...
> >>> Hi,
>
> >>> I'm having some strange problems with a setup project I created in
> >>> VS2008.
>
> >>> I have been working on v1.3 of my app. =A0I released "beta 1" to a gu=
y to
> >>> test it - sent it to him as my Setup.MSI file a couple of weeks ago.
> >>> Everything is fine.
>
> >>> I then released "beta 2", compiled it into an MSI file. =A0Increased =
the
> >>> version number in the MSI file, created new package code, all the usu=
al.
> >>> Sent it to my tester. =A0It installed absolutely fine for him without=
any
> >>> errors, but when he came to run it, half the binary files hadn't been
> >>> updated. =A0The main application exe was still beta 1, as was one of =
the
> >>> DLL files - the other DLLs (and one exe) had all been updated to beta=
2
> >>> without any fuss though.
>
> >>> I confirmed this behaviour on a different system. =A0I had installed =
v1.3
> >>> alpha (i.e. before Beta 1) onto a test system. =A0Tried this new inst=
aller
> >>> for beta 2, and it DID NOT update the main .exe file - it left it as
> >>> v1.3 alpha.
>
> >>> I have some custom actions in my installer which I thought might
> >>> possibly have interfered (it ngen's the files after installing) so I =
set
> >>> some breakpoints and tried to run it from within VS2008 by right
> >>> clicking on my setup project and selecting "Install".
>
> >>> Never hit the breakpoints. =A0Not one of them.
>
> >>> Confirmed that I *have* got my custom installer DLL referenced in the
> >>> Custom Actions section of my setup project for both install and
> >>> uninstall.
>
> >>> So can anyone shed any light on this? =A0Why on earth would the insta=
ller
> >>> decide not to update my main .exe but be happy to update most of my
> >>> supporting DLL files? =A0Why can't I debug the custom actions in VS20=
08?!
>
> >>> Just to make things even more weird, if I did a "repair" on the Beta =
2
> >>> MSI file after I'd installed it, that *did* update all files to their
> >>> beta 2 versions! =A0This is bizarre and inconsistent. =A0Please help =
me, MS!
>
> >>> Alex- Hide quoted text -
>
> - Show quoted text -
I am running into the identical problem with my setup project however,
it does not install the new application.exe file during the "Repair".
I have checked installed software version numbers and confirmed that
the version number of the application.exe file is being updated to the
new version but the file and the Date Modified time stamp is not being
changed either.
If I select "Remove" and then run the setup a third time the correct
application.exe file is finally installed.
I would also appreciate any help with this problem.