Re: [WiX-users] Supplemental shell extensions installation
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
Re: [WiX-users] Supplemental shell extensions installation
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. -Original Message- From: Jan Wester [mailto:happyhon...@gmail.com] Sent: Thursday, November 19, 2009 1:04 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Supplemental shell extensions installation On Thu, Nov 19, 2009 at 9:25 PM, Michael Clark mcl...@fullarmor.com wrote: a) Objectively, is WiX the right option, or should I look at other installers for this purpose? [Michael] It's a great tool for this purpose and its free! 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. [Michael] I think this is what your looking for http://stackoverflow.com/questions/138550/how-to-register-file-types-ext ensions-with-a-wix-installer 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. [Michael] Checkout this link for 32/64 bit installs http://blogs.msdn.com/astebner/archive/2007/08/09/4317654.aspx -Michael 2243 Michael, The file extension stuff seems wrong for me. I don't have an application to hang on the Open verb, or whatever other choice. I just have shell extensions that need to play ball with any existing settings of the computer without disrupting anything else. So far, I have thumbnail and property handlers for my first file format, but a preview is on my plans. Basically, think of stuff that spruces stuff up in Explorer. I had seen that link on 32-bit and 64-bit installations. It is somewhat old though, and I had read older versions of WiX were different in some ways, so I figured there might be actual samples out there demonstrating the kind of thing I am looking for. (Something to be put besides an article like the one you linked - such articles are a great resource, but for a wix beginner like me, nearly everything implies a lot of searching and studying where a simple example document would clarify more in a simpler glance.) 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
Re: [WiX-users] Supplemental shell extensions installation
I was looking at sharing file extension registrations between
applications only yesterday. This page and its related content were most
useful
http://msdn.microsoft.com/en-us/library/bb166183(VS.80).aspx
-Original Message-
From: Happy Hondje [mailto:happyhon...@gmail.com]
Sent: 19 November 2009 20:08
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Supplemental shell extensions installation
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
Re: [WiX-users] Supplemental shell extensions installation
On Thu, Nov 19, 2009 at 11:00 PM, Chad Petersen chad.peter...@harlandfs.com wrote: Aren't shell extensions either a DLL or OCX file as the entry point? Think about what you have to do to manually deploy your shell extensions and write down the steps (if it helps). These are the steps that you would then author in WiX to automate the process through an MSI. A simple outline with things that are common 1. Confirm it is a Windows OS 2. Confirm it is one of the version(s) of Windows you support 3. Detect where Windows is installed if needed 4. Copy extension to proposed folder (your own, or perhaps System32) 5. Register the extension with the system 6. Restart Windows if needed Hello Chad, Aye, shell extensions are all DLLs. I believe I know the requirements of my shell extensions, but I am unsure as to the best installing habits. For example, you recommend system32, but I recall reading that starting with Vista I believe it was, Microsoft is advising against installing stuff into System32. I have no real need for backwards compatibility (thankfully), so I focusing fully on Windows 7 compatibility and guidelines in this matter. But to me, this also means I should be getting it mostly right at my first try, rather than mostly wrong. :) 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
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
Re: [WiX-users] Supplemental shell extensions installation
On Fri, Nov 20, 2009 at 10:59 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: I was looking at sharing file extension registrations between applications only yesterday. This page and its related content were most useful http://msdn.microsoft.com/en-us/library/bb166183(VS.80).aspx That is an interesting post, but (correct me if I am wrong) it seems quite different from my situation. 1) I am supplementing with extra information, not writing a product to compete with the registration for the filetypes. 2) I have no 'open' action attached to my application and installation at all. 3) Minimum change is my goal for installation - I don't know how other applications act/deal with their file registrations. I can imagine quite a few applications will have a check for the progid and pop up a 'ProductA is no longer configured to handle .XYZ files. Do you wish to repair the file associations?' dialog... which would most likely break the few things I need in the registrations. This is one of THE reasons I want to modify existing ProgIDs rather than take ownership of the extension and copy any existing configuration in the old ProgID to my new one. Thank you for the link however, it is an interesting resource on how to deal with that facet of filetype associations. 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
Re: [WiX-users] Supplemental shell extensions installation
Ah you are right. I misunderstood the part where you were talking about *other* applications sharing file type registrations. Apologies for any confusion. -Original Message- From: Jan Wester [mailto:happyhon...@gmail.com] Sent: 20 November 2009 12:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Supplemental shell extensions installation On Fri, Nov 20, 2009 at 10:59 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: I was looking at sharing file extension registrations between applications only yesterday. This page and its related content were most useful http://msdn.microsoft.com/en-us/library/bb166183(VS.80).aspx That is an interesting post, but (correct me if I am wrong) it seems quite different from my situation. 1) I am supplementing with extra information, not writing a product to compete with the registration for the filetypes. 2) I have no 'open' action attached to my application and installation at all. 3) Minimum change is my goal for installation - I don't know how other applications act/deal with their file registrations. I can imagine quite a few applications will have a check for the progid and pop up a 'ProductA is no longer configured to handle .XYZ files. Do you wish to repair the file associations?' dialog... which would most likely break the few things I need in the registrations. This is one of THE reasons I want to modify existing ProgIDs rather than take ownership of the extension and copy any existing configuration in the old ProgID to my new one. Thank you for the link however, it is an interesting resource on how to deal with that facet of filetype associations. 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 SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- 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
Re: [WiX-users] Supplemental shell extensions installation
a) Objectively, is WiX the right option, or should I look at other
installers for this purpose? [Michael] It's a great tool for this
purpose and its free!
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.
[Michael] I think this is what your looking for
http://stackoverflow.com/questions/138550/how-to-register-file-types-ext
ensions-with-a-wix-installer
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.
[Michael] Checkout this link for 32/64 bit installs
http://blogs.msdn.com/astebner/archive/2007/08/09/4317654.aspx
-Michael 2243
-Original Message-
From: Happy Hondje [mailto:happyhon...@gmail.com]
Sent: Thursday, November 19, 2009 3:08 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Supplemental shell extensions installation
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
Re: [WiX-users] Supplemental shell extensions installation
On Thu, Nov 19, 2009 at 9:25 PM, Michael Clark mcl...@fullarmor.com wrote: a) Objectively, is WiX the right option, or should I look at other installers for this purpose? [Michael] It's a great tool for this purpose and its free! 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. [Michael] I think this is what your looking for http://stackoverflow.com/questions/138550/how-to-register-file-types-ext ensions-with-a-wix-installer 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. [Michael] Checkout this link for 32/64 bit installs http://blogs.msdn.com/astebner/archive/2007/08/09/4317654.aspx -Michael 2243 Michael, The file extension stuff seems wrong for me. I don't have an application to hang on the Open verb, or whatever other choice. I just have shell extensions that need to play ball with any existing settings of the computer without disrupting anything else. So far, I have thumbnail and property handlers for my first file format, but a preview is on my plans. Basically, think of stuff that spruces stuff up in Explorer. I had seen that link on 32-bit and 64-bit installations. It is somewhat old though, and I had read older versions of WiX were different in some ways, so I figured there might be actual samples out there demonstrating the kind of thing I am looking for. (Something to be put besides an article like the one you linked - such articles are a great resource, but for a wix beginner like me, nearly everything implies a lot of searching and studying where a simple example document would clarify more in a simpler glance.) 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
Re: [WiX-users] Supplemental shell extensions installation
Aren't shell extensions either a DLL or OCX file as the entry point? Think about what you have to do to manually deploy your shell extensions and write down the steps (if it helps). These are the steps that you would then author in WiX to automate the process through an MSI. A simple outline with things that are common 1. Confirm it is a Windows OS 2. Confirm it is one of the version(s) of Windows you support 3. Detect where Windows is installed if needed 4. Copy extension to proposed folder (your own, or perhaps System32) 5. Register the extension with the system 6. Restart Windows if needed -Original Message- From: Jan Wester [mailto:happyhon...@gmail.com] Sent: Thursday, November 19, 2009 1:04 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Supplemental shell extensions installation On Thu, Nov 19, 2009 at 9:25 PM, Michael Clark mcl...@fullarmor.com wrote: a) Objectively, is WiX the right option, or should I look at other installers for this purpose? [Michael] It's a great tool for this purpose and its free! 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. [Michael] I think this is what your looking for http://stackoverflow.com/questions/138550/how-to-register-file-types-ext ensions-with-a-wix-installer 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. [Michael] Checkout this link for 32/64 bit installs http://blogs.msdn.com/astebner/archive/2007/08/09/4317654.aspx -Michael 2243 Michael, The file extension stuff seems wrong for me. I don't have an application to hang on the Open verb, or whatever other choice. I just have shell extensions that need to play ball with any existing settings of the computer without disrupting anything else. So far, I have thumbnail and property handlers for my first file format, but a preview is on my plans. Basically, think of stuff that spruces stuff up in Explorer. I had seen that link on 32-bit and 64-bit installations. It is somewhat old though, and I had read older versions of WiX were different in some ways, so I figured there might be actual samples out there demonstrating the kind of thing I am looking for. (Something to be put besides an article like the one you linked - such articles are a great resource, but for a wix beginner like me, nearly everything implies a lot of searching and studying where a simple example document would clarify more in a simpler glance.) 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
