Hello WiXers,
I am new to Windows Installer and WiX, and thus have been pouring over
documentation. tutorials, samples and google the last few days. I see
a lot of basic information which is nice, but sadly, my needs aren't
all that typical. (This might become a rather long posting, so I will
apologize in advance for that.)
The reason is that my 'application' is fully compromised out of shell
extensions, the purpose being to give a more seamless experience in
using the applicable documents in every day use. (I have one
production-ready at this point, so I figured I'd look into getting a
basic installer ready that meets my requirements.) I foresee the
following big problems:
1. Architecture. Basically, there are two (or technically three)
possible scenario's:
* 32-bit shell extension on 32-bit platform.
* 64-bit shell extension on 64-bit platform. For maximum
compatibility, I would want the 32-bit shell extension installed as
well.
>From what I understand based on some older posts on this mailing list,
WI/WiX sincerely dislikes mixed-architecture installations. Sadly,
this is a matter that can't be avoided. Paths, registry, they're both
things to be careful of. And ideally, there would be a single .msi and
no chance for user-error.
2. File extension ownership is an issue. Whereas dedicated
applications can simply take ownership of a file-extension, define
their own progid's, verbs and all that magic. This would be a
supplemental package that has no external dependancies, so the
extensions it registers to may be registered to ProductA, ProductB or
even nothing at all. This means the -target- ProgID for these
registrations is flexible, falling down to a default where nothing was
hooked up just yet. And in the case overwriting something IS
unavoidable, it would be nice to be able to restore these values upon
uninstallation.
3. Making points 1 and 2 meet eye-to-eye, which would probably be the
most difficult.
For as far solutions go, let me first explain how I imagine the setup.
The entire application configuration experience would be done from a
feature tree in the setup. Think of something along the lines of:
[ ] .XYZ support.
[x] .DEF support.
[x] .DEF2 support.
Afterwards, the Change feature in the Installed Programs list could be
used to change or repair these shell extensions.
I was thinking of solving one of the architecture problems using the
bootstrapper burn. (I might be getting that one wrong, the
fire-related names are all one big blur after all this reading...) It
could activate the proper MSI for the proper platform.
The 32-bit support for 64-bit platforms is tricky. I thought about
having it optional, but I decided my users would only be confused if I
offered them a bitness option, so I want to have it turned on by
default. I recall reading somewhere that it is possible to do hidden
installs of other .msi packages, having no entries pop up in Installed
Programs etc. Assuming I understood that right, and assuming I can
somehow feed the 'installed features' from the 64-bit .msi to the
32-bit .msi, I could avoid having two entries pop up in the Installed
Programs applet ('MyApp 32-bit', 'MyApp 64-bit').
At this point, it is kind of obvious to me that I will probably not
want to make the installable directory configurable, but have the
setup copy to 'C:\Program Files\MyApp' and 'C:\Program Files
(x86)\MyApp' as appropriate. If I did not and would let the user pick
a location, they might very will pick one of those places only to have
half of the functionality disappear on them depending on whether my
shell extensions were to be utilized from the native Explorer or a
32-bit application using an Open File dialog.
The file extension ownership issues, and how to deal with different
ProgID's, are mysteries to me. I could probably figure out how to
install to a fixed ProgID with no regard of the users current
installed affairs, but that is not what I want. The concept of
installing extensions for files you don't actually own seems to be
like a rare occurrance. Who'd have guessed! :)
If anyone read this far, I commend you.
Now my questions are as follows, maybe not too specific, but still:
a) Objectively, is WiX the right option, or should I look at other
installers for this purpose?
b) Are there any samples of scripts that install shell extensions? I
have looked around, but found nothing. Reinventing the wheel is
something I will probably be pretty crappy at.
c) Likewise, are there any samples dealing with such specific
requirements for as far the platform goes? Again, my wheel would
likely not be all that round.
And similarly... I welcome any comments or other thoughts based on my
research so far. There's probably a few bad assumptions and
understandings, but as I said, I'm new to WI/WiX, and have studied as
much as I can make sense of.
Regards,
Jan Wester
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
