I'm afraid I spoke too soon at 2am last night.... although they apply to the
Spanish MSI just fine when verifying with Orca, when actually trying to
install against the Spanish version yeilds "No valid sequence could be found
for the set of patches."  It works fine against English version of the MSI.

I tried putting the torch arguments back to "-serr a -serr b -serr c -serr d
-serr e -val g -val u -val x" but I get the same error.  I will continue to
experiment but was hoping someone here might have some insight, as we're
hoping to release these patches today.

Thanks

On Thu, Nov 12, 2009 at 2:21 AM, Shawn Dwyer <shawn.o.dw...@gmail.com>wrote:

> I've finally got a solution that works I think.  I've basically gone back
> to option 1 - having an admin old and admin new image for each language and
> running torch for each one.  However, because the actual files installed are
> the same regardless of language, I don't have to carry around the full set
> for each language, but just one file set and each MSI generated from doing
> and admin install.  My new structure looks like this:
>
> Admin
>             PFiles
>             Installer_English.msi
>             Installer_Spanish.msi
>             ....
> Patch
>             PFiles
>             Installer_English.msi
>             Installer_Spanish.msi
>             ...
>             MSP.wxs
>
> My new torch and pyro commands look like:
>
> setlocal EnableDelayedExpansion
> set LANGUAGES=English French German Italian Japanese Portuguese Spanish
>
> for %%l in (%LANGUAGES%) do (
>     torch -t patch -p -xo -ax Patch\torch\%%l\bin Admin\Installer_%%l.msi
> Patch\Installer_%%l.msi -out Patch\torch\%%l\Diff.wixmst -v >Patch\torch.log
> || EXIT /B
> )
>
> for %%l in (%LANGUAGES%) do (
>     set PYROT=!PYROT! -t RTM Patch\torch\%%l\Diff.wixmst
> )
> pyro Patch\MSP.wixmsp -out Patch\Patch.msp %PYROT% -delta -v
> >Patch\pyro.log || EXIT /B
>
> This seems to allow the MSP to be applied to any language installer.  I
> still don't understand what I was missing about the other method and why I
> couldn't get that to work, but I didn't want to waste anyone's time looking
> into it since I will be going with this other method now.
>
> Thanks again for all your help, I’ve learned a lot about how this works
> through your explanations that I just wasn’t picking up from the help files.
>
> Thanks,
>
> Shawn
>
>
>
> On Wed, Nov 11, 2009 at 1:26 PM, Shawn Dwyer <shawn.o.dw...@gmail.com>wrote:
>
>> Hi Blair,
>>
>>
>>
>> Thanks again for the prompt and detailed response.  I'm sorry to say even
>> with the updated command line it's still failing to apply to the Spanish
>> install (it applies fine to the English install).  I'm thinking maybe the
>> command line options aren't where my misunderstanding is, but perhaps the
>> setup for running the tools.  Here is my setup:
>>
>>
>>
>> Admin
>>
>>             PFiles
>>
>>             Installer.msi
>>
>> Patch
>>
>>             PFiles
>>
>>             Installer.msi
>>
>> MSP.wxs
>>
>>
>>
>> The Admin folder is an admin install of the English version of my
>> installer.  The Patch folder is an exact copy of the Admin folder, and
>> then replacing a couple of the dlls under PFiles.  MSP.wxs has only one
>> PatchFamily element with the ProductCode matching the ProductCode in the
>> English version of Installer.msi.  (It didn’t help to add a PatchFamily
>> for the Spanish ProductCode)
>>
>>
>>
>> I then run the following commands
>>
>>
>>
>> torch -serr a -serr b -serr c -serr d -serr e -val g -val u -val x -p -xo
>> -ax Patch\torch\bin Admin\Installer.msi Patch\Installer.msi -out
>> Patch\torch\Diff.wixmst -v >Patch\torch.log || EXIT /B
>>
>>
>>
>> candle Patch\MSP.wxs -out Patch\MSP.wixobj -v >Patch\candle.log || EXIT /B
>>
>>
>>
>> light Patch\MSP.wixobj -out Patch\MSP.wixmsp -v >Patch\light.log || EXIT
>> /B
>>
>>
>>
>> pyro Patch\MSP.wixmsp -out Patch\Patch.msp -t RTM Patch\torch\Diff.wixmst
>> -delta -v >Patch\pyro.log || EXIT /B
>>
>>
>> All commands complete successfully and I end up with an MSP that I can
>> apply to the English version of Installer.msi but not the Spanish version.
>>
>> Thanks again,
>>
>> Shawn
>>
>> On Wed, Nov 11, 2009 at 2:06 AM, Blair <os...@live.com> wrote:
>>
>>> Digging out the sources for 3.0 RTM, here is what I see:
>>>
>>> The help built into the tool says that the accepted values for the -val
>>> argument are (all are in the list of accepted values):
>>>
>>>   g          UpgradeCode must match
>>>   l          Language must match
>>>   r          Product ID must match
>>>   s          Check major version only
>>>   t          Check major and minor versions
>>>   u          Check major, minor, and upgrade versions
>>>   v          Upgrade version < target version
>>>   w          Upgrade version <= target version
>>>   x          Upgrade version = target version
>>>   y          Upgrade version > target version
>>>   z          Upgrade version >= target version
>>>
>>> Also, the -serr argument accepts (via the same form) the following
>>> values:
>>>
>>>   a          Ignore errors when adding an existing row
>>>   b          Ignore errors when deleting a missing row
>>>   c          Ignore errors when adding an existing table
>>>   d          Ignore errors when deleting a missing table
>>>   e          Ignore errors when modifying a missing row
>>>   f          Ignore errors when changing the code page
>>>
>>> If the "-t" argument (such as "-t patch") is also present the command
>>> will
>>> fail and you will be shown the help, so make sure that is gone (if you
>>> removed just the "-t" and not its argument that followed, that may be the
>>> issue). "-t" sets both the -val and the -serr values.
>>>
>>> For reference, "-t patch" = -serr a -serr b -serr c -serr d -serr e -val
>>> g
>>> -val r -val u -val x
>>>
>>> *   a          Ignore errors when adding an existing row
>>> *   b          Ignore errors when deleting a missing row
>>> *   c          Ignore errors when adding an existing table
>>> *   d          Ignore errors when deleting a missing table
>>> *   e          Ignore errors when modifying a missing row
>>>
>>> *   g          UpgradeCode must match
>>> *   r          Product ID must match
>>> *   u          Check major, minor, and upgrade versions
>>> *   x          Upgrade version = target version
>>>
>>> What we want to eliminate is "-val r". So, the command line we really
>>> want
>>> is
>>>
>>> "-serr a -serr b -serr c -serr d -serr e -val g -val u -val x"
>>>
>>> Let us know what it does with that.
>>>
>>> Blair
>>>
>>> -----Original Message-----
>>> From: Shawn Dwyer [mailto:shawn.o.dw...@gmail.com]
>>> Sent: Tuesday, November 10, 2009 1:06 PM
>>> To: General discussion for Windows Installer XML toolset.
>>>  Subject: Re: [WiX-users] One MSP for multiple MSI
>>>
>>> Thanks Blair.  What you've described makes perfect sense, I wish I had
>>> reviewed the command line options more thoroughly before posting :)
>>>
>>>
>>>
>>> I'm afraid I might have misunderstood something though, because I still
>>> can't get this to work.  I'm attempting to go with option 2 to reduce the
>>> size of the MSP and so I don't have to have an admin image for each
>>> language.  So if I undestand correctly, I should be able to have only the
>>> 'English old' and 'English new', and by passing "-val gstu" to torch I
>>> will
>>> be able to take the MSP that I eventually generate and apply it to any
>>> MSI
>>> with the same UpgradeCode, regardless of ProductCode and Language?  I
>>> attempted a number of combinations but I couldnt quite get it.
>>>
>>> First I tried
>>>
>>> -val gstu
>>>
>>> and got
>>>
>>> torch.exe : error TRCH0251 : val is expected to be followed by a value
>>> argument.
>>>
>>>
>>>
>>> Then looking at examples online I figured I had to split them up:
>>>
>>> -val g -val s -val t -val u
>>>
>>> But torch then spat out the usage statement
>>>
>>>
>>>
>>> Then I guessed that s, t, and u were overlaps, and so all I really needed
>>> was 'u'
>>>
>>> -val g -val u
>>>
>>> This generated an MSP, however when I applied to the Spanish MSI I was
>>> back
>>> to:
>>>
>>> "This patch can not be applied to packages with the current Product
>>> Code."
>>>
>>>
>>>
>>> I then hoped that the validation flags might really mean what to -not-
>>> validate, so I tried
>>>
>>> -val l -val r
>>>
>>> However I still got the same error.
>>>
>>>      "This patch can not be applied to packages with the current Product
>>> Code."
>>>
>>>
>>> Thanks again,
>>>
>>> Shawn
>>>
>>> On Mon, Nov 9, 2009 at 9:44 PM, Blair <os...@live.com> wrote:
>>>
>>> > The safest way requires that you prepare both admin images and call
>>> torch
>>> > twice, once for the English old against the English new and the other
>>> time
>>> > for the Spanish old and Spanish new. You then need to supply both
>>> wixmst
>>> > files to pyro by supplying the -t argument twice. This means you will
>>> be
>>> > using two different baselines (one for each wixmst file), both of which
>>> > need
>>> > to be represented under the Media element and on the command-line (one
>>> with
>>> > each instance of the -t argument).
>>> >
>>> > The biggest disadvantage with above is that the patch is roughly twice
>>> as
>>> > big as with just one baseline, since you have basically the same
>>> transforms
>>> > in there twice.
>>> >
>>> > There is an alternative way of using just one baseline: pass "-val
>>> gstu"
>>> as
>>> > an argument to torch to change the validation flags (and don't use the
>>> "-t"
>>> > argument). However, any changes to the text in the admin image you use
>>> will
>>> > be applied to both languages without regard to the language itself
>>> (meaning
>>> > you will bleed those text changes across the translations, losing your
>>> > localization).
>>> >
>>> > -----Original Message-----
>>> > From: Shawn Dwyer [mailto:shawn.o.dw...@gmail.com]
>>> > Sent: Monday, November 09, 2009 2:32 PM
>>> > To: General discussion for Windows Installer XML toolset.
>>> > Subject: [WiX-users] One MSP for multiple MSI
>>> >
>>> > Hello,
>>> >
>>> >
>>> >
>>> > I've seen multiple similar posts but none seemed quite what I was
>>> looking
>>> > for, sorry if this has already been answered.
>>> >
>>> >
>>> >
>>> > We have released one MSI for each language we support - each with it's
>>> own
>>> > ProductCode and CodePage.
>>> >
>>> >
>>> >
>>> > Using Wix only patching, I thought it should be possible to specify the
>>> > patch in such a way that it would apply to multiple products
>>> >
>>> >
>>> >
>>> > <!-- English -->
>>> >
>>> > <PatchFamily
>>> >
>>> >                ProductCode="68B543C9-2412-45AB-9327-D49189A8A13B"
>>> >
>>> >                Id='XPIM30059'
>>> >
>>> >                Version='3.0.60.0'
>>> >
>>> >                Supersede='no' />
>>> >
>>> > <!-- Spanish -->
>>> >
>>> > <PatchFamily
>>> >
>>> >                ProductCode="7E481F23-6792-4F89-A7CA-2F889FFE4DE7"
>>> >
>>> >                Id='XPIM30059'
>>> >
>>> >                Version='3.0.60.0'
>>> >
>>> >                Supersede='no' />
>>> >
>>> >
>>> >
>>> > However, when using Orca to apply the MSP to the Spanish MSI I get
>>> "This
>>> > patch can not be applied to packages with the current Product Code."
>>> >
>>> >
>>> >
>>> > I'm using the admin image / loose file patching method described here:
>>> >
>>> >
>>> >
>>>
>>> http://blogs.msdn.com/pmarcu/archive/2008/05/30/Patching-something-you-didnt
>>> >
>>> -build-with-WiX-using-WiX-.aspx<
>>> http://blogs.msdn.com/pmarcu/archive/2008/05
>>>  /30/Patching-something-you-didnt-build-with-WiX-using-WiX-.aspx>
>>> >
>>> >
>>> >
>>> > I'm assuming this has something to do with the fact that the admin
>>> image
>>> > has
>>> > the English MSI.  If I instead point to the Spanish admin image I have
>>> the
>>> > reverse problem.  Is there any way this can be done?
>>> >
>>> >
>>> >
>>> > In future releases I'm planning on having the Product Code be the same
>>> for
>>> > all languages since the only difference between the MSIs will be the
>>> text
>>> > on
>>> > the screen.  I think this would greatly simplify creating patches, will
>>> > there be any issues with this method?
>>> >
>>> >
>>> >
>>> > Thanks,
>>> >
>>> >
>>> >
>>> > Shawn
>>> >
>>> >
>>>
>>> ----------------------------------------------------------------------------
>>> >  --
>>> > 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
>>> >
>>>
>>> ----------------------------------------------------------------------------
>>> --
>>> 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
>>>
>>
>>
>
------------------------------------------------------------------------------
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

Reply via email to