/p and some APIs care about the target ProductCodes and will actually
modified the resulting PATCH property if a ProductCode is not targetted. You
should use the TargetProductCodes element in that case. I have a blog post
coming about that (hopefully) soon at http://blogs.msdn.com.

On Wed, Apr 8, 2009 at 12:47 AM, Yan Sklyarenko <y...@sitecore.net> wrote:

> Thanks a lot for the hint, Heath!
> That's fantastic I can achieve the same without "shaman dancing"
> dismembering msp file!
> WiX rules!! :)
>
> One small question: is there any reason why this command format works:
>   msiexec /i {42A33A91-36B0-4700-A6F5-1289D22F358C}
> PATCH=*path\to\patch.msp*
>
> but this doesn't (throwing that "The upgrade patch cannot be installed
> ..." error):
>   msiexec /p *path\to\patch.msp* /n
> {42A33A91-36B0-4700-A6F5-1289D22F358C}
>
> ?
> This is reproduced without "TargetProductCode" elements.
>
> -- Yan
>
> -----Original Message-----
> From: Heath Stewart [mailto:clubs...@gmail.com]
> Sent: Friday, April 03, 2009 9:46 AM
> To: General discussion for Windows Installer XML toolset.
>  Subject: Re: [WiX-users] Multiple instance installations and patches
>
> Actually, WiX supports this already without having to execute code.
> Under
> your PatchBaseline element add the Validation element and set
> ProductCode="no". The "double-click" scenario for the resulting MSP will
> only apply to the default instance (the instance you created the patch
> from)
> but it will apply explicitly to any instance even if the ProductCode is
> the
> same (assuming your instance transforms aren't changing the
> ProductVersion,
> ProductLanguage, or UpgradeCode). So they'd apply like so:
>
> msiexec /i {42A33A91-36B0-4700-A6F5-1289D22F358C}
> PATCH=*path\to\patch.msp*
>
> If you want to enable the double-click scenario while only building the
> patch against the default instance (which makes sense - it's all the
> same
> differences and files) use the new TargetProductCodes element added to
> WiX
> 3.0.5106.0. Under your Patch element, add;
>
> <TargetProductCodes>
>  <TargetProductCode Id="{42A33A91-36B0-4700-A6F5-1289D22F358C}"/>
>  <TargetProductCode Id="{68C62C01-D064-4CF0-9239-F5D2FF36BD9A}"/>
> </TargetProductCodes>
>
> Now when the MSP is double-clicked it will apply to any and all
> instances
> installed.
>
>
> On Tue, Dec 30, 2008 at 4:48 AM, Yan Sklyarenko <y...@sitecore.net> wrote:
>
> > Hello,
> >
> > Well, I managed to overcome this myself. For those who interested in
> > details, please visit my blog:
> >
> http://ysdevlog.blogspot.com/2008/12/multiple-instance-installations-and
> >
> .html<http://ysdevlog.blogspot.com/2008/12/multiple-instance-installatio
> ns-and%0A.html>
>  >
> > I would appreciate any comments.
> >
> > -- Yan
> >
> > -----Original Message-----
> > From: Yan Sklyarenko [mailto:y...@sitecore.net]
> > Sent: Wednesday, December 24, 2008 4:44 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] Multiple instance installations and patches
> >
> > Hello WiX community,
> >
> >
> >
> > I'm just stuck with this scenario and I'd appreciate any hint.
> >
> > I have a product which supports multiple instance installations with
> the
> > help of instance transforms. In order to make the components data
> > isolated, it is installed to different folders (like best practice
> guide
> > suggests), and also I apply another transform to change component
> GUIDs
> > for each instance. Hence, in order to install instance 1 I use the
> > following command line:
> >
> >   Msiexec /i MyPackage.msi MSINEWINSTANCE=1
> > TRANSFORMS=:InstanceId1;:ComponentGUIDTransform1.mst
> INSTALLLOCATION=...
> >
> > And for instance 2:
> >
> >   Msiexec /i MyPackage.msi MSINEWINSTANCE=1
> > TRANSFORMS=:InstanceId2;:ComponentGUIDTransform2.mst
> INSTALLLOCATION=...
> >
> > Etc.
> >
> >
> >
> > This works perfectly.
> >
> > Now I'd like to build a patch which then can be applied to any of the
> > instance. I use the "pure-WiX" way of building the .msp:
> >
> > candle Patch.wxs
> >
> > light Patch.wixobj -out Patch.wixmsp
> >
> > torch -p -xi v100\MyPackage.wixpdb v101\ MyPackage.wixpdb -out
> > diff.wixmst
> >
> > pyro Patch.wixmsp -out Patch.msp -t UpdatePatch diff.wixmst
> >
> >
> >
> > The output patch.msp can successfully patch the default instance only.
> > Now, again following the guide, I'm going to populate the Targets
> > property of the patch SummaryInfo stream with the product codes of
> other
> > instances. Something like this:
> >
> >
> >
> >      static void SetTargetProductGUIDs(string mspPath, List<string>
> > productCodes)
> >
> >      {
> >
> >         using (Database patchDatabase = new Database(mspPath,
> > DatabaseOpenMode.Transact))
> >
> >         {
> >
> >            StringBuilder targetsBuilder = new StringBuilder();
> >
> >            foreach (string productCode in productCodes)
> >
> >            {
> >
> >               targetsBuilder.Append(targetsBuilder.Length == 0 ?
> > productCode : string.Format(";{0}", productCode));
> >
> >            }
> >
> >            patchDatabase.SummaryInfo.Template =
> > targetsBuilder.ToString();
> >
> >            patchDatabase.Commit();
> >
> >         }
> >
> >      }
> >
> >
> >
> > This really updates the patch file. I can see this in Orca: View - >
> > Summary Information - > Targets field contains all product codes.
> >
> >
> >
> > BUT, when I try to apply this modified patch to other instances of my
> > application (not only default), I get the same error:
> >
> > "The upgrade patch cannot be installed by the Windows Installer
> service
> > because the program to be upgraded may be missing, or the upgrade
> patch
> > may update a different version of the program. Verify that the program
> > to be upgraded exists on your computer and that you have the correct
> > upgrade patch."
> >
> >
> >
> > Does anyone know what can be wrong? Any hint... Please, help...
> >
> > Thank you.
> >
> >
> >
> > -- Yan
> >
> >
> >
> >
> ------------------------------------------------------------------------
> > ------
> > _______________________________________________
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> ------------------------------------------------------------------------
> ------
> > _______________________________________________
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
>
>
> --
> Heath Stewart
> Deployment Technologies Team, Microsoft
> http://blogs.msdn.com/heaths
> ------------------------------------------------------------------------
> ------
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
>  _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to