I think you have two different issues going on here:
First issue is how to package (the bitness question):
Here is what I propose you consider for the bitness question (I didn't build
this to verify, but it should be close):
Don't include the Package/@Platform attribute. Instead, call candle/light
twice (like this, replacing "..." with appropriate data, and using the
x86/x64 pattern as the most typical):
candle ... -arch x86 -out ...\x86\ ...
light ... ...\x86\... ...
candle ... -arch -x64 -out ...\x64\ ...
light ... ...\x64\... ...
and in your WXS authoring (I am assuming this is a per-machine installation.
Change the directory tree below as appropriate if this is per-user):
- for your directory table:
<Directory Id="TARGETDIR" Name="SourceDir">
<?if $(sys.PLATFORM)=Intel?>
<?define BldPlatform=Intel?>
<?else?>
<?foreach BldPlatform in Intel;$(sys.PLATFORM)?>
<?endif?>
<?if $(var.BldPlatform)=Intel?>
<?define ProgFilesDirId=ProgramFilesFolder?>
<?define CapsPlatform=INTEL?>
<?else?>
<?define ProgFilesDirId=ProgramFiles64Folder?>
<?if $(var.BldPlatform)=x64?>
<?define CapsPlatform=X64?>
<?else?>
<?define CapsPlatform=INTEL64?>
<?endif?>
<?endif?>
<Directory Id="$(sys.ProgFilesDirId)">
<Directory Id="MYINSTALLDIR$(var.CapsPlatform)"/>
</Directory>
<?if $(sys.PLATFORM)!=Intel?>
<?endforeach?>
<?endif?>
</Directory>
- surround your components (individually or as a group) with:
<?if $(sys.PLATFORM)=Intel?>
<?define BldIs64=no>
<?define BldPlatform=Intel?>
<?else?>
<?define BldIs64=yes>
<?foreach BldPlatform in Intel;$(sys.PLATFORM)?>
<?endif?>
<?if $(var.BldPlatform)=Intel?>
<?define CapsPlatform=INTEL?>
<?elseif $(var.BldPlatform)=x64?>
<?define CapsPlatform=X64?>
<?else?>
<?define CapsPlatform=INTEL64?>
<?endif?>
<DirectoryRef Id="MYINSTALLDIR$(var.CapsPlatform)">
<Component Id="MyCompId$(var.BldPlatform)" Guid="*" Win64="$(var.BldIs64)"
...>
...
</Component>
</DirectoryRef>
<?undef BldIs64?>
<?if $(sys.PLATFORM)!=Intel?>
<?endforeach?>
<?endif?>
Using the above pattern/code you can build x86 (containing just 32-bit) and
either/both x64/ia64 packages that each contain both 32 and 64-bit
components (if you name your build directories "Intel/x64/Intel64" you can
access them using the $(var.BldPlatform) instead of having to add more
conditional code to what is above).
The other question has to do with how the user opts out of particular
registrations and how you protect any "required" values that are already
there, and if you would then somehow "restore" them upon removal, and if so
how you would validate that they are still valid at that time. Can't help
there without more details as to how you intend to implement "opt-out".
-----Original Message-----
From: Jan Wester [mailto:happyhon...@gmail.com]
Sent: Friday, November 20, 2009 3:56 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Supplemental shell extensions installation
On Fri, Nov 20, 2009 at 10:22 AM, Blair <os...@live.com> wrote:
> Aaron's blog will help you with building your two MSIs (32- & 64-bit)
using
> the exact same sources. On a 64-bit OS, explorer.exe will be a 64-bit app,
> so you won't need the 32-bit mirrored installation. However, if you feel
you
> really need them, you could use the <?foreach?> preprocessor command and
> "duplicate" the components.
>
> As I understand your issue regarding the shell-extension registration, it
is
> that you don't know what file types/extensions you support until such time
> as you are installing, correct? Or do you just need to only install into
> those filetypes you do support if they already existed in the system?
Could
> you please clarify?
>
> Once we know what your intended process is (as Chad seems to be saying),
we
> can then coach with ideas, with both how-to-implement as well as
> this-other-might-be-better styles of responses.
Hello Blair,
Sadly, I -do- need the 32-bit installation side-by-side. When using a
32-bit application (which is the majority of the stuff out there), it
will use the 32-bit explorer components rather than the 64-bit ones.
Since a good part of the focus lies with making metadata available in
explorer and its components (think of having a 32-bit application
going File->Open, using details view and sorting on some of this
custom metadata), both 32-bit and 64-bit are necessary on 64-bit
computers for a seamless experience.
The support for each filetype is fully optional to allow the user to
opt out. A filetype may either not be registered at all (application
using it hasn't registered it) or it may be registered to a (from our
point of view) random application. Suppose you have .XYZ:
* If there is no traces of a .XYZ registration, we make our custommade
ProgID called XYZHandler (I'm not all that original) and register the
appropriate stuff there. In the end, these files would still be
useless for doubleclicking and such, but that is not something I could
change either way as it is beyond the scope of my installation. (Not
installing anything in this case is not preferable - a surprising
amount of people/programs open everything through File->Open dialogs
in programs which don't register filetypes that I have noticed, so
there is most definitely added value by having these registrations.)
* If there is a trace of a .XYZ registration using a 'Xylophone.Zing'
ProgID, we make our modifications to that ProgID, and leave everything
we don't need to change alone. So stuff like open handlers, drop
targets, and whatever other fancy stuff... it remains. Registering
some thumbnail, property and preview handlers is all that is needed.
The point is to supplement the user in his/her daily activities, not
to take control of them. Either way, my apologies for another
long-winded email, and thank you for your valuable insights.
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
------------------------------------------------------------------------------
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
