Ok, I am working with Jonathan today in my day job capacity and I have an
understanding of PROBABLY what is happening. If the WiX-devs list is better for
this, let me know...
Based on the install logs and the way BURN appears to work, transforms seem a
bit limited in how BURN handles them (and if someone knows the section of code
I would appreciate the pointer).
Background:
So the transform is working on install. The installation works as expected and
the appropriate transform is applied and installed. On uninstall they are
getting an error saying that the item is not installed (weird cause we did
install it). So looking at the log we see that the initial product GUID is one
value and the transform changes it to a different value. Also the registry
shows that the transform was applied as expected. So far so good.
When we go to uninstall we notice the GUID being used is the old GUID for the
application not the transformed one. This leads to the uninstall error.
What we believe is happening is that BURN is tracking the MSI GUIDs that are
being installed and when the transform is applied and changes that GUID, BURN
has no trace of it.
What we need:
So what we need to do is when a transform is applied, update the XML list that
BURN maintains with the new GUID so that the uninstall tracks it appropriately.
We just need to update this on install only. Once updated it should be fine
going forward. I can see in the BURN source where it reads this XML information
and operates based on that, but I am not 100% sure where this information is
generated. Is it on install or is this done at build time? If at build time is
there a way for us to tell BURN what the GUID will change to? That will resolve
their uninstall problem...
Below are some of the logs during install:
[09B4:06A0][2013-03-13T07:48:14]: Verified acquired payload:
cab07A065F47DD6E9FCDAE62ABCDDF335E7 at path: C:\Documents and Settings\All
Users\Application Data\Package
Cache\.unverified\cab07A065F47DD6E9FCDAE62ABCDDF335E7, moving to: C:\Documents
and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\cab1.cab.
[09B4:0D50][2013-03-13T07:48:14]: Applying execute package: RADInstall30,
action: Install, path: C:\Documents and Settings\All Users\Application
Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\RADInstall30,
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TRANSFORMS=":Jon2T"
ARPSYSTEMCOMPONENT="1"'
[09B4:0D50][2013-03-13T07:48:16]: Unable to register source directory:
C:\Documents and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\, product:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, reason: 0x80070645. Continuing...
[09B4:0D50][2013-03-13T07:48:16]: Registering package dependency provider:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, version: 1.0.0.0030, package:
RADInstall30
[09E8:0A84][2013-03-13T07:48:16]: Applied execute package: RADInstall30,
result: 0x0, restart: None
[09B4:0D50][2013-03-13T07:48:16]: Registering dependency:
{08b55420-861a-4f92-b56f-120c85eb2455} on package provider:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, package: RADInstall30
[09B4:0D50][2013-03-13T07:48:16]: Removing cached package: RADInstall30, from
path: C:\Documents and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\
[09E8:0A84][2013-03-13T07:48:16]: Apply complete, result: 0x0, restart: None,
ba requested restart: No
Final registry key after transform is applied:
Here is a snapshot of :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CA11308E-C505-48B9-BD2F-340095256AE9}
Below is the log from the uninstall:
[07E8:0544][2013-03-13T07:55:15]: Detected partially cached package:
RADInstall30, invalid payload: RADInstall30, reason: 0x80070570
[07E8:0544][2013-03-13T07:55:15]: Detected partially cached package:
RADInstall30, invalid payload: cab07A065F47DD6E9FCDAE62ABCDDF335E7, reason:
0x80070570
[07E8:0544][2013-03-13T07:55:15]: Detected package: RADInstall30, state:
Absent, cached: Partial
[07E8:0544][2013-03-13T07:55:15]: Detect complete, result: 0x0
[07E8:0544][2013-03-13T07:55:17]: Plan 1 packages, action: Uninstall
[07E8:0544][2013-03-13T07:55:17]: Planned package: RADInstall30, state: Absent,
default requested: Absent, ba requested: Absent, execute: None, rollback: None,
cache: No, uncache: Yes, dependency: Unregister
[07E8:0544][2013-03-13T07:55:17]: Plan complete, result: 0x0
[07E8:0544][2013-03-13T07:55:17]: Apply begin
[0D8C:090C][2013-03-13T07:55:24]: Automatic updates could not be paused due to
error: 0x80070422. Continuing...
[0D8C:090C][2013-03-13T07:55:24]: Creating a system restore point.
[0D8C:090C][2013-03-13T07:55:28]: Created a system restore point.
[0D8C:090C][2013-03-13T07:55:28]: Removed dependency:
{08b55420-861a-4f92-b56f-120c85eb2455} on package provider:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, package RADInstall30
TechX - Technology eXperts
Technical Support & Consulting
Phone: 559.464.5042
Web: http://on.fb.me/Ztd9ns
Sent from Windows Mail
From: David Watson
Sent: March 12, 2013 6:08 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using transforms (regular) to install mulitple times
per application
Hi,
Shared components can be managed several ways how you implement depends on
your application.
If your application is purely designed to be used by others you can ship a
merge module or wixlib that they can include inside their MSI and install
privately into their program folder, this puts them in charge of making
updates if you release a new version.
You can also implement this as a full msi to be included in their
bootstrapper as a pre-requisite and be handled like any other pre-requisite,
ideally this will be installed into a shared location (common files). Updates
to this would be created by you but shipped by your customers, or possible
auto-updated directly by you. Small updates would be done in place (by msp or
msi), major updates that are not backwards compatible would be installed in
parallel (upgrade code and install location change) -so you don't break other
software installed on the machine. Burn should handle if multiple products
have a shared MSI.
Your software architecture has to support this of course.
-----Original Message-----
From: jeamis [mailto:jonathan.a...@intergraph.com]
Sent: 12 March 2013 10:48
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using transforms (regular) to install mulitple times per
application
What I am trying to do is to allow customer bootstrappers the ability to
install my package for thier application. In some cases the customer has two
applications (installed in one setup) that use my product. So how can I use
a transform that will allow this customer to install my product twice?
And also support patches etc.... My product is delivered as a msi file.
<http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7584257/
New_Bitmap_Image.bmp>
I currently have a msi that implements instance tranforms to do this. If I
were using scripts msiexec.exe installs it fine with MSINEWINSTANCE=1 and
TRANSFORMS set. And if I were using scripts I could uninstall fine by
calling msiexec.exe without the MSINEWINSTANCE=1 parameter. However, using a
msiPackage in wix I don't see how I can provide a msiProperty
(MSINEWINSTANCE) on Install and not have the msiProperty on uninstall.
So we are thinking of abondoning instance transforms and seeing if there is
a way to use regular transforms to do the same.
Being green on the subject of installer and Wix, I would love some direction
on how I can solve this problem.
My component is used by several independent applications as well and they
want to be able to exist on machines that may have other applications that
use my component (thier own copy).
-----
- jon
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-transform
s-regular-to-install-mulitple-times-per-application-tp7584257.html
Sent from the wix-users mailing list archive at Nabble.com.
-----------------------------------------------------------------------------
-
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to tackle
endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-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.
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
