Re: [WiX-users] Major update disallowing component
Have you tried moving RemoveExistingProducts to before InstallInitialise ? That worked for us in a similar situation. -Original Message- From: Quinton Tormanen [mailto:quint...@deltamotion.com] Sent: 29 November 2010 20:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major update disallowing component No this isn't anything in the GAC. The component in question is a piece of a driver installed using the DifxAppExtension, and its absence wreaks havoc on the attempt to install the driver, failing the major update. However, the problem itself occurs prior to this, in that very early on the installer decided not to update that component and it doesn't change its mind even though we are removing remove the existing product. Notice that I do have the RemoveExistingProducts action coming after InstallInitialize: InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence Not sure of the history for why that code is in my wxs file. What is the suggested location for this action? I notice that the KB you reference talks about moving RemoveExistingProducts to after InstallFinalize. However, even if I move RemoveExistingProducts to the end, I'll still have a problem with my installer not updating the component that I wanted to totally replace. (The component is installed in a subfolder of the product install path, and therefore not shared by other products.) To summarize the core question, how can I change a keyfile in a non-shared component to a previous version with a major upgrade? Perhaps I need to change the key path for this component from the file to a registry entry? --Quinton Is this in the GAC? Sounds like that upgrade GAC problem. http://support.microsoft.com/kb/905238 Phil Wilson -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ 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. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
Wow. Uhh, easiest fix is probably going to be to release the 1.1 DLL with
the version 1.3. Time travel is hard so just go forward naturally.
On Mon, Nov 29, 2010 at 11:00 AM, Quinton Tormanen quint...@deltamotion.com
wrote:
Perhaps this question has been answered before, but I couldn't find
anything in the wix-users archive.
I found a problem where when we do a major update when a component in
the newer version has a key file with an older version than the version
its updating. The problem is that the component gets rejected because a
higher versioned keyfile exists, but then gets uninstalled by the major
update, so in the end no version of the component exists. This behavior
seems incorrect, since my application is the only one that uses this
component (although perhaps Windows Installer can't know that).
Here are some specifics to clarify:
1. The installer has a component {E1E586EE-69CE-43B1-8707-01537674AABD}
with a keyfile of ftcserco.dll. In the previous release, this DLL was
version 1.2. In the new release, this DLL had to be reverted back to
1.1.
2. When running the update for our product I get the following entry in
the MSI log during the CostFinalize step:
MSI (c) (0C:F0) [09:05:34:528]: Disallowing installation of component:
{E1E586EE-69CE-43B1-8707-01537674AABD} since the same component with
higher versioned keyfile exists
What is the proper way to work around this? I'm thinking of just
changing the component ID.
Quinton Tormanen
Software Engineer
Delta Computer Systems, Inc.
http://www.deltamotion.com http://www.deltamotion.com/
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually, Rob Mensching - http://RobMensching.com LLC
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
No. Looking at the log, it appears that the decision to skip those components was made in CostFinalize so it doesn't seem like it'd help. Thanks though. --Quinton Peter Shirtcliffe wrote: Have you tried moving RemoveExistingProducts to before InstallInitialise? That worked for us in a similar situation. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
Unfortunately, the files are part of a driver package that I don't want to mess with. I'm consider (brace yourself) of doing the REINSTALLMODE=amus thing since all files are within our install folder. Anything less ugly? --Quinton On Tues, Nov 30, 2010 7:06 AM, Rob Mensching r...@robmensching.com wrote Wow. Uhh, easiest fix is probably going to be to release the 1.1 DLL with the version 1.3. Time travel is hard so just go forward naturally. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Major update disallowing component
Perhaps this question has been answered before, but I couldn't find
anything in the wix-users archive.
I found a problem where when we do a major update when a component in
the newer version has a key file with an older version than the version
its updating. The problem is that the component gets rejected because a
higher versioned keyfile exists, but then gets uninstalled by the major
update, so in the end no version of the component exists. This behavior
seems incorrect, since my application is the only one that uses this
component (although perhaps Windows Installer can't know that).
Here are some specifics to clarify:
1. The installer has a component {E1E586EE-69CE-43B1-8707-01537674AABD}
with a keyfile of ftcserco.dll. In the previous release, this DLL was
version 1.2. In the new release, this DLL had to be reverted back to
1.1.
2. When running the update for our product I get the following entry in
the MSI log during the CostFinalize step:
MSI (c) (0C:F0) [09:05:34:528]: Disallowing installation of component:
{E1E586EE-69CE-43B1-8707-01537674AABD} since the same component with
higher versioned keyfile exists
What is the proper way to work around this? I'm thinking of just
changing the component ID.
Quinton Tormanen
Software Engineer
Delta Computer Systems, Inc.
http://www.deltamotion.com http://www.deltamotion.com/
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
Just an update on this. I tried changing the Component GUID, but realized that that won't work, because the files still target the same location, so I get the same error. That is, it's not looking up the Component GUID for determining if the component is pre-existing, but rather the destination itself. Any suggestions on how to cleanly get around this issue? --Quinton I found a problem where when we do a major update when a component in the newer version has a key file with an older version than the version its updating. The problem is that the component gets rejected because a higher versioned keyfile exists, but then gets uninstalled by the major update, so in the end no version of the component exists. This behavior seems incorrect, since my application is the only one that uses this component (although perhaps Windows Installer can't know that). What is the proper way to work around this? I'm thinking of just changing the component ID. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
Is this in the GAC? Sounds like that upgrade GAC problem. http://support.microsoft.com/kb/905238 Phil Wilson -Original Message- From: Quinton Tormanen [mailto:quint...@deltamotion.com] Sent: Monday, November 29, 2010 11:20 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major update disallowing component Just an update on this. I tried changing the Component GUID, but realized that that won't work, because the files still target the same location, so I get the same error. That is, it's not looking up the Component GUID for determining if the component is pre-existing, but rather the destination itself. Any suggestions on how to cleanly get around this issue? --Quinton I found a problem where when we do a major update when a component in the newer version has a key file with an older version than the version its updating. The problem is that the component gets rejected because a higher versioned keyfile exists, but then gets uninstalled by the major update, so in the end no version of the component exists. This behavior seems incorrect, since my application is the only one that uses this component (although perhaps Windows Installer can't know that). What is the proper way to work around this? I'm thinking of just changing the component ID. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
No this isn't anything in the GAC. The component in question is a piece of a driver installed using the DifxAppExtension, and its absence wreaks havoc on the attempt to install the driver, failing the major update. However, the problem itself occurs prior to this, in that very early on the installer decided not to update that component and it doesn't change its mind even though we are removing remove the existing product. Notice that I do have the RemoveExistingProducts action coming after InstallInitialize: InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence Not sure of the history for why that code is in my wxs file. What is the suggested location for this action? I notice that the KB you reference talks about moving RemoveExistingProducts to after InstallFinalize. However, even if I move RemoveExistingProducts to the end, I'll still have a problem with my installer not updating the component that I wanted to totally replace. (The component is installed in a subfolder of the product install path, and therefore not shared by other products.) To summarize the core question, how can I change a keyfile in a non-shared component to a previous version with a major upgrade? Perhaps I need to change the key path for this component from the file to a registry entry? --Quinton Is this in the GAC? Sounds like that upgrade GAC problem. http://support.microsoft.com/kb/905238 Phil Wilson -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
