On Tue, Feb 9, 2010 at 06:02, Steve Borho <steve_at_borho.org> wrote:
> Hello,
>
> I'm the project lead of TortoiseHg. We're transitioning our project
> to use WIX and thus switching from bundling your excellent
> TortoiseOverlay MSI packages to using the provided merge modules
> instead. This leads to a couple of issues I'm hoping you can help me
> out with.
>
> First, our x64 MSI package installs our 32 bit applications and both
> the x86 and x64 shell extensions. This seems to mostly work, except
> light generates a validation error during the link step. Even though
> light generates this error message and returns an error code, it still
> generates a functional MSI.
Sorry, I seriously doubt that. Msi does not allow 32 and 64-bit
components in the same msi file (version 5 will have that ability,
although somewhat limited - but version 5 most likely won't run on
XP).
Also, what you call a "functional msi" might work on your system with
your specific version of the windows installer. Someone using another
version of the windows installer might get another result or the
installation won't work at all.
>
> light.exe : error LGHT0204 : ICE08: Component:
> OverlayRegistry.3C89127D_F335_46EB_8720_CAFE0C0FEB7E has a duplicate
> GUID: {87654321-4321-4321-4321-110987654321}
That's why it won't work to combine x64 and win32 packages in one msi.
Ok, it's actually a little bit more complicated...
> Digging through the TortoiseOverlay source, I can see that both the
> TortoiseOverlaysDir,wxi and TortoiseOverlaysDirx64.wxi define this
> component and GUID. Is this something that could be easily resolved
> on your side?
Nope.
A 32-bit msi can only register components in the 32-bit registry hive.
A 64-bit msi can only register components in the 64-bit registry hive.
You can try to manually specify the redirect path to the 32-bit
registry, but this will break the automatic update/upgrade checks msi
does when installing a component.
> The second issue is a simpler question: We've shipped three different
> versions of TortoiseOverlay*.msi since the project adopted your
> overlay shims about 18 months ago. When we finally release our new
> MSI packages, we're going to ask (well, actually force) that users
> uninstall their previous TortoiseHg packages to avoid having to
> upgrade the old InnoSetup based installs. What do we tell users about
> these (potentially several) TortoiseOverlay packages that are left on
> their machines? Should they be left installed unconditionally? Is
> there a way to tell when they can be safely removed?
It's an msi - uninstalling is always possible because msi keeps track
on how many times it was installed and when it can be safely removed.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2446090
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-09 09:20:33 CET