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
