Re: [WiX-users] Conditional registry entries and handling them properly on uninstall
Hello Blair, Leaving registry keys behind isn't the biggest issue, and I could deal with leaving some things behind if they didn't replace existing values. But as I wrote in an earlier post, my application deals in the improvement of the experience dealing with files outside the applications installed by the user, either because they do not provide such support or haven't done a thorough enough job. Suppose I allow my overwritten Infotip entry to remain, that breaks any Infotips the native application has used. I guess my problems are only reinforced by the fact that I haven't fully grasped understanding of and the advantages of WiX mechanism over a more procedural approach where I could do it in a simple if-statement. I have already got rough sketches working in a simple DLL register/unregister function, but that is a strong no-no for deployment according to all places I have read up on the matter. (Although the reason escapes me - run the unregister before deleting the file, and you get the same net effect..) -Jan On Wed, Nov 25, 2009 at 6:19 AM, Blair os...@live.com wrote: If you want to restore a previously existing registry key, you would have had to have saved it someplace, or at least saved the fact that it previously existed with enough information to recreate it. That means that in your RegistrySearches you would need to be able to distinguish the difference between a non-existent key (that you are defaulting, perhaps?) and a previously existing key. Or, can you change the situation a bit? Is it bad to leave the registry key behind when you uninstall? Sometimes old droppings really aren't as bad as the destruction that can be caused by trying to do a comprehensive job cleaning up after yourself. -Original Message- From: Jan Wester [mailto:happyhon...@gmail.com] Sent: Saturday, November 21, 2009 11:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Conditional registry entries and handling them properly on uninstall Hello WiX community, After the advice given to me yesterday, I've been focusing on the subject I've had least replies on. Basically, I am trying to only write a registry entry if it does not exist and create some keys to go with it, or if it does exist, I want to modify things, and at uninstall time, restore things to how they were. Since my attempts so far combined with examples will probably be more informative, here they come: Property Id=PROGID_XYZ Value=Test.ProgID RegistrySearch Id='ExtXyzRegistry' Type='raw' Root='HKLM' Key='Software\CLASSES\.xyz' / /Property That ought to fill PROGID_XYZ with an already existing ProgID, or if the filetype is unknown, substitute my own default handler. Component Id=ComponentXYZ Guid=snip snip RegistryKey Root=HKLM Key=Software\Classes\[PROGID_XYZ] Action=createAndRemoveOnUninstall RegistryValue Type=string Name=SomeWeirdValue Value=Stuff / /RegistryKey /Component This created the value in the proper place, but upon uninstallation, it removed the entire key, which makes sense since I asked it to. But in this case, the RegistrySearch was successful, and thus the appropriate ProgID already existed, and I essentially wiped out the file associations. Oops. How can I avoid this? If I were to make it action=create, I would never remove the handler afterwards if I understand correctly. To have it all in a little neat list, these are the requirements I am trying to achieve: * .XYZ exists - make changes in existing ProgID. * .XYZ does not exist - make the .XYZ key, and make my default ProgID. * Uninstallation: .XYZ already existed at installation - place back any settings I overwrote in the 'foreign' ProgID, and remove any new entries I made. * Uninstallation: .XYZ never existed at installation - remove .XYZ and my default ProgID. I have studied conditions, features, components and the various options available to me with a RegistrySearch, but I am pretty much lost. As such I appreciate any advice or examples you folks can give me to work off. :) 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
[WiX-users] Conditional registry entries and handling them properly on uninstall
Hello WiX community, After the advice given to me yesterday, I've been focusing on the subject I've had least replies on. Basically, I am trying to only write a registry entry if it does not exist and create some keys to go with it, or if it does exist, I want to modify things, and at uninstall time, restore things to how they were. Since my attempts so far combined with examples will probably be more informative, here they come: Property Id=PROGID_XYZ Value=Test.ProgID RegistrySearch Id='ExtXyzRegistry' Type='raw' Root='HKLM' Key='Software\CLASSES\.xyz' / /Property That ought to fill PROGID_XYZ with an already existing ProgID, or if the filetype is unknown, substitute my own default handler. Component Id=ComponentXYZ Guid=snip snip RegistryKey Root=HKLM Key=Software\Classes\[PROGID_XYZ] Action=createAndRemoveOnUninstall RegistryValue Type=string Name=SomeWeirdValue Value=Stuff / /RegistryKey /Component This created the value in the proper place, but upon uninstallation, it removed the entire key, which makes sense since I asked it to. But in this case, the RegistrySearch was successful, and thus the appropriate ProgID already existed, and I essentially wiped out the file associations. Oops. How can I avoid this? If I were to make it action=create, I would never remove the handler afterwards if I understand correctly. To have it all in a little neat list, these are the requirements I am trying to achieve: * .XYZ exists - make changes in existing ProgID. * .XYZ does not exist - make the .XYZ key, and make my default ProgID. * Uninstallation: .XYZ already existed at installation - place back any settings I overwrote in the 'foreign' ProgID, and remove any new entries I made. * Uninstallation: .XYZ never existed at installation - remove .XYZ and my default ProgID. I have studied conditions, features, components and the various options available to me with a RegistrySearch, but I am pretty much lost. As such I appreciate any advice or examples you folks can give me to work off. :) 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 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
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
