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