[wix-users] Experience of build with WiX 4 Toolset
Rob Mensching
rob at firegiant.com
Tue Aug 9 07:04:04 PDT 2022
> Yes, it so happened because I have incorrect command line parameter values.
> I pass to '-culture' a value something like this "en-US, de-DE" how it was in v3.
> But at the same time for example I do not have a wxl for "en-US, de-DE".
This makes sense. From the command-line provide a single culture to the `-culture` switch. Specify the `-culture` switch as many times as you need.
> Also I tried to set different values, for example -culture pt-PT and - loc ENU.wxl,
> and I got the same error.
> So I think wix can not find the related wxl-file to the entered culture but it
> reported that "The localization variable !(loc.DisplayName) is unknown".
The `-culture` switch filters the provided wxl files. So, using `-culture pt-PT` will only include .wxl files that declare they are in the `pt-PT` culture. Presumably the ENU.wxl file specified a different culture so it was filtered out causing the localization variable to be undefined.
If you do not need to filter cultures then you don't specify a -culture switch.
-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Timofey Evsyutkin via wix-users
Sent: Monday, August 8, 2022 4:00 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Timofey Evsyutkin <goldghost.oomphi.suppository at gmail.com>
Subject: Re: [wix-users] Experience of build with WiX 4 Toolset
Thanks, Sean!
> Your BA was parsing the whole command line and not just the one
> provided in the BootstrapperCommand? Was it smart enough to get "-q"
> as well as "-quiet"? It wasn't using the display value from the
> BootstrapperCommand?
I parse the whole command line before running the bundle to redirect the log file and to get the elevated process from initially.
So all I need is to look for 'burn.embedded' along with / instead of 'quiet'.
I have re-designed my launcher and tried it.
That solved some problems and the Upgrade was a success as a result now.
Maybe it matters how you have ordered the command line parameters?
Yes, it so happened because I have incorrect command line parameter values.
I pass to '-culture' a value something like this "en-US, de-DE" how it was in v3.
But at the same time for example I do not have a wxl for "en-US, de-DE".
Also I tried to set different values, for example -culture pt-PT and - loc ENU.wxl, and I got the same error.
So I think wix can not find the related wxl-file to the entered culture but it reported that "The localization variable !(loc.DisplayName) is unknown".
чт, 4 авг. 2022 г. в 02:07, Sean Hall via wix-users <
wix-users at lists.wixtoolset.org>:
> I tried to add tests for the issues you reported while converting your
> files and the wxl issue in
> https://github.com/wixtoolset/wix4/pull/212. I could not reproduce the
> wxi or wxl issues. Maybe it matters how you have ordered the command line parameters?
>
> On Mon, Aug 1, 2022 at 4:51 PM Sean Hall <r.sean.hall at gmail.com> wrote:
>
> > > My question was about the switch "-quiet" which was in v3.
> >
> > The "-quiet" switch still exists in v4 but there was no reason to
> > pass it in this case because embedded mode is its own special
> > display mode. I'm
> not
> > sure what to do here. Your BA was parsing the whole command line and
> > not just the one provided in the BootstrapperCommand? Was it smart
> > enough to get "-q" as well as "-quiet"? It wasn't using the display
> > value from the BootstrapperCommand? The engine will operate in
> > embedded mode even if
> your
> > BA wants to run full UI. So for example, it won't show the splash screen.
> > If the bundle is running in embedded mode and as a related bundle,
> > then showing full UI is probably not the right thing to do.
> >
> > For the wxl question - as far as I know nothing has changed in this
> > area except the namespace. If it worked in v3 then it's supposed to
> > work in
> v4.
> >
> > For the wix.dll question - the short answer is to use
> > WixToolsetServiceProviderFactory from WixToolset.Core.dll and get
> > the appropriate interface. I don't remember off the top of my head
> > what interface you need, you might need to create a feature request
> > if it
> wasn't
> > exposed through one.
> >
> > On Fri, Jul 29, 2022 at 6:20 AM Timofey Evsyutkin <
> > goldghost.oomphi.suppository at gmail.com> wrote:
> >
> >> Thanks, Sean!
> >>
> >>
> >>> I'm surprised you were
> >>> able to get something like this working in v3.
> >>>
> >>
> >> Yes, It works in v3.11.2.
> >>
> >> 0x800705b4 is ERROR_TIMEOUT. The child process is probably crashing.
> >>> Hopefully there is a log in %TEMP% with more information. Worst
> >>> case would be that you enable crash dumps and we'd have to debug
> >>> that.
> >>
> >>
> >> You won't do anything about it. I use "runner" which contains
> >> Bundle as an embedded resource.
> >> It uses a Mutex for Full UI and another Mutex for Silent. So I need
> >> to redesign my code.
> >> My question was about the switch "-quiet" which was in v3.
> >>
> >>
> >> Let's go back to one of the previous questions.
> >>
> >> I'm guessing your wxl file was not upgraded to the new namespace:
> >>>
> >> http://wixtoolset.org/schemas/v4/wxl. If that's the case, I don't
> >> know
> >>> why
> >>> the toolset isn't giving some kind of error if it had the v3 namespace.
> >>
> >>
> >> I have Bundle like this:
> >> <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs" xmlns:bal="
> >> http://wixtoolset.org/schemas/v4/wxs/bal" xmlns:netfx="
> >> http://wixtoolset.org/schemas/v4/wxs/netfx">
> >> <?include $(var.WixSourcesRoot)\common\Shared\DEF.wxi?>
> >> <?include
> >> $(var.ProductSourcesRoot)\$(var.PathProductName)\productdata.wxi ?>
> >> <Bundle
> >> Name="$(var.DisplayProductName)"
> >> Version="$(var.ProductSetupVersion)"
> >> Manufacturer="$(var.ManufacturerName)"
> >> UpgradeCode="$(var.ProductUpgradeCode)"
> >> DisableModify="no"
> >> DisableRemove="yes">
> >> </Bundle>
> >> <?include
> >> $(var.ProductSourcesRoot)\$(var.PathProductName)\fragments.wxi ?>
> >> </Wix>
> >>
> >> In productdata.wxi:
> >> <Include xmlns="http://wixtoolset.org/schemas/v4/wxs">
> >> <?define DisplayProductName = "!(loc.DisplayName)" ?> </Include>
> >>
> >> In loc file:
> >> <WixLocalization Culture="en-us" xmlns="
> >> http://wixtoolset.org/schemas/v4/wxl" Codepage="1252">
> >> <String Id="DisplayName" Overridable="yes">Test Product</String>
> >> </WixLocalization>
> >>
> >> Should it work? This throws an error.
> >>
> >> ~\src\Bundle.wxs(4) : error WIX0102:
> >>
> >> The localization variable !(loc.DisplayName) is unknown. Please
> >> ensure
> >>> the variable is defined.
> >>
> >>
> >> It looks like I shouldn't specify wxl files and I should pre-define
> >> all variables when building the bundle.
> >>
> >> I have an extra question.
> >> Previously, it was possible to unpack a bundle from MBA using the
> >> Microsoft.Tools.WindowsInstallerXml.Unbinder class and wix.dll and
> >> winterop.dll libraries from v3.
> >> winterop.dll is missing in v4. However, my code is compiled. How
> >> can
> this
> >> be done now?
> >> I am seeing how it works in ExtractSubcommand.cs, Is it the only
> >> one
> way?
> >>
> >> пт, 29 июл. 2022 г. в 02:29, Sean Hall via wix-users <
> >> wix-users at lists.wixtoolset.org>:
> >>
> >>> There's no need to apologize, bundles have a lot of moving parts
> >>> so there's not really a way around the back and forth that we're
> >>> doing here.
> >>>
> >>> Bundles don't support the MSI changing between build time and
> >>> runtime,
> so
> >>> they don't support transforms (
> >>> https://github.com/wixtoolset/issues/issues/6472). I'm surprised
> >>> you were able to get something like this working in v3. I can only
> >>> think of two issues that might be impacting this change in
> >>> behavior - 3643 and 4663.
> >>>
> >>> > After install and re-run the installer DetectRelatedMsiPackage
> >>> > event
> >>> fires only for the x64 package on the x86 operating system.
> >>>
> >>> Yes, that is by design. DetectRelatedMsiPackage is only for
> >>> packages on the machine with the same upgrade code but different
> >>> product code. You're supposed to use the state parameter from
> >>> DetectPackageComplete for the actual package.
> >>>
> >>> > e000: Error 0x80070020: Failed to cache bundle from... to:
> >>> 'C:\ProgramData\Package
> >>> Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe'
> >>>
> >>> 0x80070020 is ERROR_SHARING_VIOLATION. Your MBA appears to be
> >>> touching this file as well so it could be interfering:
> >>>
> >>> i000: MBA#: Copying extractor to temp directory:
> >>> C:\ProgramData\Package
> >>> Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe in
> >>> C:\Users\Evsyutkin.Tim\AppData\Local\Temp\uoelhrqv.y4d\Boot.exe
> >>>
> >>> On the other hand, I think v3 skipped trying to copy the file if
> >>> it already existed. v4 always tries to copy over it in case it was
> >>> corrupted.
> Maybe
> >>> v4
> >>> needs to ignore this error.
> >>>
> >>> > e000: Error 0x800705b4: Failed to wait for child to connect to
> >>> > pipe
> >>>
> >>> 0x800705b4 is ERROR_TIMEOUT. The child process is probably crashing.
> >>> Hopefully there is a log in %TEMP% with more information. Worst
> >>> case would be that you enable crash dumps and we'd have to debug
> >>> that.
> >>>
> >>> > Why don't command line arguments contain the "-quiet" switch?
> >>>
> >>> It is running the bundle as an embedded bundle, which is its own
> version
> >>> of
> >>> quiet.
> >>>
> >>> > Also some Detect events fire twice.
> >>>
> >>> The DetectRelatedMsiPackage duplicate is because there are
> >>> different languages (0 and 1033).
> >>>
> >>> I don't understand the DetectRelatedBundle duplicate. This might
> >>> be a
> bug
> >>> on x86 machines where it tries to enumerate the 64-bit registry
> >>> but
> that
> >>> ends up enumerating the 32-bit registry a second time.
> >>>
> >>> On Thu, Jul 28, 2022 at 5:49 AM Timofey Evsyutkin <
> >>> goldghost.oomphi.suppository at gmail.com> wrote:
> >>>
> >>> > Thanks, Sean!
> >>> >
> >>> > Your answer kicked me. I am really sorry! I should have provided
> >>> > more information.
> >>> > I found out why it happens.
> >>> > I use embedded transformations to create MUI MSI like this:
> >>> > @cscript "%_WindowsSdkDir%bin\x86\WiLangId.vbs"
> >>> > "%MSI_PATH%\%MSI_NAME%.msi" Product %LANGUAGE_ID%
> >>> > @"%_WindowsSdkDir%bin\x86\MsiTran.exe" -g %MUI_SETUP%
> >>> > %MSI_PATH%\%MSI_NAME%.msi %UnloadMuiMsiPath%\%CULTURE%.mst
> >>> > @cscript "%_WindowsSdkDir%bin\x86\WiSubStg.vbs" "%MUI_SETUP%"
> >>> > "%UnloadMuiMsiPath%\%CULTURE%.mst" %LANGUAGE_ID% @cscript
> >>> > "%_WindowsSdkDir%bin\x86\WiSubStg.vbs" "%MUI_SETUP%"
> >>> >
> >>> > Transformation changes the ProductCode during the install.
> >>> > >> Product Code passed to Engine.Initialize: ''
> >>> > >> Product Code from property table before transforms:
> >>> > '{3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}'
> >>> > >> Product Code from property table after transforms:
> >>> > '{3D8554F9-E2B4-40B0-869E-10FADD1EF636}'
> >>> > >> Product not registered: beginning first-time install Product
> >>> > >> {3D8554F9-E2B4-40B0-869E-10FADD1EF636} is not managed.
> >>> >
> >>> > After that I am getting the installed product with two different
> >>> > ProductCode in the registry.
> >>> > It looks so strange. I uploaded extra files.
> >>> >
> >>>
> https://drive.google.com/drive/folders/1SIL4xzyd9S5KqbuJmgHNk3qygKpU_a
> eM?usp=sharing
> >>> > So, MSI doesn't work as earlier. But It worked with version 3.
> >>> > I am going to freeze Package/@Id for the MSIs build process and
> >>> continue
> >>> > my journey in this way.
> >>> > However, what should I do if I take strange MSI with embedded
> >>> > transformations?
> >>> >
> >>> >
> >>> > Also I tried it out with MSI which has only one language. There
> >>> > is a similar log:
> >>> > >> Product Code passed to Engine.Initialize: ''
> >>> > >> Product Code from property table before transforms:
> >>> > '{A9B478AB-23B1-4787-B574-FA71EB79D181}'
> >>> > >> Product Code from property table after transforms:
> >>> > '{A9B478AB-23B1-4787-B574-FA71EB79D181}'
> >>> > >> Product not registered: beginning first-time install Product
> >>> > >> {A9B478AB-23B1-4787-B574-FA71EB79D181} is not managed.
> >>> >
> >>> > It works and seems like all good but it is not exactly.
> >>> >
> >>> > After install and re-run the installer DetectRelatedMsiPackage
> >>> > event fires only for the x64 package on the
> x86
> >>> > operating system,
> >>> > so MBA has incorrect info about the system state. For example,
> >>> > if I
> >>> plan
> >>> > Repair, then the product will be removed.
> >>> > Should I use bal:PrimaryPackageType?
> >>> >
> >>> > When I run installer from Package Cache by link I get this error
> >>> > on register process:
> >>> > i000: MBA#: EVENT: RegisterBegin
> >>> >
> >>>
> ({"RecommendedRegistrationType":2,"RegistrationType":2,"Cancel":false,
> "HResult":0})
> >>> > i370: Session begin, registration key:
> >>> >
> >>>
> SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{76B4A6BF-A40F-4C2
> 5-BAC1-182F0EF5848A},
> >>> > options: 0x3, disable resume: No
> >>> > i000: Caching bundle from:
> >>> > 'C:\Windows\TEMP\{6C28A1FE-C63E-4A96-8A37-66C33029A122}\.be\Boot.exe'
> >>> to:
> >>> > 'C:\ProgramData\Package
> >>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe'
> >>> > e000: Error 0x80070020: Failed to cache bundle from:
> >>> > 'C:\Windows\TEMP\{6C28A1FE-C63E-4A96-8A37-66C33029A122}\.be\Boot.exe'
> >>> to
> >>> > 'C:\ProgramData\Package
> >>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe'
> >>> > e000: Error 0x80070020: Failed to cache bundle from path:
> >>> > C:\Windows\TEMP\{6C28A1FE-C63E-4A96-8A37-66C33029A122}\.be\Boot.
> >>> > exe
> >>> > e000: Error 0x80070020: Failed to begin registration session.
> >>> > e000: Error 0x80070020: Failed to begin registration session in
> >>> > per-machine process.
> >>> > i000: MBA#: EVENT: RegisterComplete
> >>> ({"Status":-2147024864,"HResult":0})
> >>> > e000: Error 0x80070020: Failed to register bundle.
> >>> >
> >>> > When I try to Update the installed product I get this error on
> >>> uninstall a
> >>> > previous bundle:
> >>> > i301: Applying execute package:
> {76B4A6BF-A40F-4C25-BAC1-182F0EF5848A},
> >>> > action: Uninstall, path: C:\ProgramData\Package
> >>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe, arguments:
> >>> > '"C:\ProgramData\Package
> >>> > Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe"
> >>> > -uninstall -burn.related.upgrade
> >>> > -burn.ancestors={5634A379-6E22-40D3-85D8-6C5A4DD609CE}
> >>> > -burn.filehandle.self=1004'
> >>> > e000: Error 0x800705b4: Failed to wait for child to connect to pipe.
> >>> > e000: Error 0x800705b4: Failed to wait for embedded process to
> connect
> >>> to
> >>> > pipe.
> >>> > e000: Error 0x800705b4: Failed to run bundle as embedded from path:
> >>> > C:\ProgramData\Package
> >>> Cache\{76B4A6BF-A40F-4C25-BAC1-182F0EF5848A}\Boot.exe
> >>> > e000: Error 0x800705b4: Failed to execute related bundle.
> >>> > e000: Error 0x800705b4: Failed to configure per-machine related
> bundle.
> >>> > As a result the previous bundle is not removed. Why don't
> >>> > command
> line
> >>> > arguments contain the "-quiet" switch?
> >>> > Also some Detect events fire twice.
> >>> >
> >>> > ср, 27 июл. 2022 г. в 00:16, Sean Hall via wix-users <
> >>> > wix-users at lists.wixtoolset.org>:
> >>> >
> >>> >> I'm guessing your wxl file was not upgraded to the new namespace:
> >>> >> http://wixtoolset.org/schemas/v4/wxl. If that's the case, I
> >>> >> don't
> >>> know
> >>> >> why
> >>> >> the toolset isn't giving some kind of error if it had the v3
> >>> namespace.
> >>> >>
> >>> >> For the bundle, can you run 'wix.exe burn extract
> >>> >> path\to\bundle.exe
> >>> -o
> >>> >> path\to\outputfolder'? Then upload the BA\manifest.xml file for
> >>> >> both bundles. I don't understand what I'm seeing in the logs.
> >>> >> The CacheId
> >>> >> ({3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}v1.1.1.1) and dependency
> >>> provider
> >>> >> ({3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}_v1.1.1.1) say that the
> product
> >>> >> code
> >>> >> is '{3B12D03A-FAD1-4EB7-AC3A-1C9C51AF67ED}' but the detected
> package's
> >>> >> product code is '{3D8554F9-E2B4-40B0-869E-10FADD1EF636}'.
> >>> >>
> >>> >> On Tue, Jul 26, 2022 at 9:11 AM Timofey Evsyutkin <
> >>> >> goldghost.oomphi.suppository at gmail.com> wrote:
> >>> >>
> >>> >> > Thanks, Sean!
> >>> >> >
> >>> >> > I'm confused why you brought up missing loc variables. Did
> >>> >> > you
> >>> expect
> >>> >> them
> >>> >> >> to be found?
> >>> >> >>
> >>> >> >
> >>> >> > Yes, I did. I passed loc.DisplayName from a file by the
> >>> >> > following
> >>> >> command
> >>> >> > line
> >>> >> > as similar that as I did with light in WiX Toolset v3:
> >>> >> >
> >>> >> > "~\wix_toolset\wix.exe" build -wx^ -ext
> >>> >> >
> >>> >>
> >>>
> "~\wix_toolset\.wix4\extensions\WixToolset.Bal.wixext\4.0.0-source\too
> ls\WixToolset.Bal.wixext.dll"^
> >>> >> > -ext
> >>> >> >
> >>> >>
> >>>
> "~\wix_toolset\.wix4\extensions\WixToolset.Netfx.wixext\4.0.0-source\t
> ools\WixToolset.Netfx.wixext.dll"^
> >>> >> > -ext
> >>> >> >
> >>> >>
> >>>
> "~\wix_toolset\.wix4\extensions\WixToolset.Util.wixext\4.0.0-source\to
> ols\WixToolset.Util.wixext.dll"^
> >>> >> > -arch "x86"^
> >>> >> > -culture "en-US"^
> >>> >> > -loc "~\test_product\loc\ENU\ENU.wxl"^ -trackingfile
> >>> >> > "~\temp\test_product\track_boot_ENU_x86.log"^
> >>> >> > -intermediatefolder "~\temp\test_product\ENU\"^ -d
> >>> >> > "PathProductName=test_product"^ -d "ProductSourcesRoot=~"^
> >>> >> > -d "SharedComponentsPath=~\src\shared_components"^
> >>> >> > -d "SharedSrcPath=~\src\common_code"^
> >>> >> > -out ~\test_product\Bundle\ENU\Boot.exe^
> >>> >> > -src "~\src\Bundle.wxs"
> >>> >> >
> >>> >> > I should not configure wxl for Bundle and add switches "-culture"
> >>> "-loc"
> >>> >> > to build commands, is it right?
> >>> >> >
> >>> >> > Custom BAs are very complex so it's pretty much impossible to
> guess
> >>> >> what's
> >>> >> >> wrong. It would help if you could provide the Burn log from
> %TEMP%
> >>> >> along
> >>> >> >> with the relevant code from your BA.
> >>> >> >>
> >>> >> >
> >>> >> > I apologize for misleading you.
> >>> >> > I looked deeper.
> >>> >> > The DetectRelatedMsiPackage event (after DetectPackageBegin)
> >>> determines
> >>> >> > the incorrect state of the package and features (returns the
> >>> incorrect
> >>> >> > operation - Downgrade).
> >>> >> > It happens even with the expected upgrade.
> >>> >> > Unfortunately, I can not provide the relevant code from my BA.
> >>> >> > But the logs here:
> >>> >> >
> >>> >>
> >>>
> https://drive.google.com/drive/folders/1SIL4xzyd9S5KqbuJmgHNk3qygKpU_a
> eM?usp=sharing
> >>> >> >
> >>> >> > чт, 21 июл. 2022 г. в 22:10, Sean Hall via wix-users <
> >>> >> > wix-users at lists.wixtoolset.org>:
> >>> >> >
> >>> >> >> Thanks for trying it out and reporting your findings here.
> >>> >> >>
> >>> >> >> WIX1150 is a warning, you must have opted in to treating
> >>> >> >> warnings
> >>> as
> >>> >> >> errors. It was added in v4 and it looks like we missed the
> Fragment
> >>> >> >> symbol.
> >>> >> >> Fragment/@Id is not deprecated, but at the same time it
> >>> >> >> doesn't
> >>> >> actually
> >>> >> >> do
> >>> >> >> anything.
> >>> >> >>
> >>> >> >> WIX8500 is also a warning, and it was also added in v4. The
> >>> >> >> issue
> >>> that
> >>> >> it
> >>> >> >> is warning about existed in v3 as well, it just didn't tell
> >>> >> >> you
> >>> about
> >>> >> it.
> >>> >> >>
> >>> >> >> I'm confused why you brought up missing loc variables. Did
> >>> >> >> you
> >>> expect
> >>> >> them
> >>> >> >> to be found?
> >>> >> >>
> >>> >> >> Custom BAs are very complex so it's pretty much impossible
> >>> >> >> to
> guess
> >>> >> what's
> >>> >> >> wrong. It would help if you could provide the Burn log from
> %TEMP%
> >>> >> along
> >>> >> >> with the relevant code from your BA.
> >>> >> >>
> >>> >> >> On Thu, Jul 21, 2022 at 6:03 AM Timofey Evsyutkin via
> >>> >> >> wix-users < wix-users at lists.wixtoolset.org> wrote:
> >>> >> >>
> >>> >> >> > Hi there
> >>> >> >> >
> >>> >> >> > I have recently converted and built a small "Test Project"
> >>> >> >> > from
> >>> v3 to
> >>> >> >> v4.
> >>> >> >> > I took 4.0.0-preview.1-build.425 for this and got some errors.
> >>> >> >> >
> >>> >> >> > Converter did not cover some situations.
> >>> >> >> >
> >>> >> >> > Related to WIX0022 after converting:
> >>> >> >> > 1. There is an empty condition. For example,
> >>> >> >> > <Text><![CDATA[]]></Text> 2. There is an inner
> >>> >> >> > comment. For example,
> >>> >> >> > <Custom Action ... something here ... >
> >>> >> >> > <!-- comment of action -->
> >>> >> >> > <![CDATA[ ... something here ... ]]]
> >>> >> >> > </Custom>
> >>> >> >> > <Condition Message="!(loc.UpdateKB2533623NotFound)">
> >>> >> >> > <!-- comment of condition -->
> >>> >> >> > <![CDATA[NOT ((UpdateKB2533623Exist = "No") AND
> >>> (VersionNT =
> >>> >> >> > 601))]]>
> >>> >> >> > </Condition>
> >>> >> >> > 3. There is a condition in include file (wxi). For example,
> >>> >> >> > <Include xmlns="http://wixtoolset.org/schemas/v4/wxs">
> >>> >> >> > <Condition Message="!(loc.InvalidOsVersion)">
> >>> >> >> > <![CDATA[NOT (VersionNT < 601)]]>
> >>> >> >> > </Condition>
> >>> >> >> > </Include>
> >>> >> >> >
> >>> >> >> > Related to WIX1150. For example,
> >>> >> >> > ~\test_product\fragments.wxi(7) : error WIX1150:
> >>> >> >> > The binder doesn't know how to place the following
> >>> >> >> > symbol
> >>> into
> >>> >> the
> >>> >> >> > output:
> >>> >> >> > SymbolName: 'WixFragment', Id: 'MsiPackages'
> >>> >> >> > Are identifiers of fragments deprecated?
> >>> >> >> >
> >>> >> >> > I submitted it because the converter did not mark them as
> >>> >> >> > an
> >>> error.
> >>> >> >> > However it is taking place when you are building with wix.
> >>> >> >> >
> >>> >> >> > When I was building a Bundle, I got these errors:
> >>> >> >> > ~\test_product\components\test_product.wxi(21) : error WIX8500:
> >>> >> >> > The Payload 'cabqsnbgoiL2yJhlIDGB7CrS2Lfb7k' has a
> >>> >> >> > duplicate
> Name
> >>> >> >> > 'setup.cab' in the attached container.
> >>> >> >> > When extracting the bundle with dark.exe, the file will
> >>> >> >> > get
> >>> >> overwritten.
> >>> >> >> > ~\test_product\components\test_product.wxi(12) : error WIX8501:
> >>> >> >> > The location of the payload related to the previous error.
> >>> >> >> >
> >>> >> >> > I suppressed them, is it ok?
> >>> >> >> >
> >>> >> >> > Also I've got these errors:
> >>> >> >> > ~\src\Bundle.wxs(55) : error WIX0102:
> >>> >> >> > The localization variable !(loc.DisplayName) is unknown.
> Please
> >>> >> ensure
> >>> >> >> the
> >>> >> >> > variable is defined.
> >>> >> >> > ~\src\Bundle.wxs(11) : error WIX0102:
> >>> >> >> > The localization variable !(loc.DisplayName) is unknown.
> Please
> >>> >> ensure
> >>> >> >> the
> >>> >> >> > variable is defined.
> >>> >> >> > ~\src\Bundle.wxs(11) : error WIX0102:
> >>> >> >> > The localization variable !(loc.DisplayName) is unknown.
> Please
> >>> >> ensure
> >>> >> >> the
> >>> >> >> > variable is defined.
> >>> >> >> >
> >>> >> >> > I "fixed" my code. After that I got MSIs and
> >>> >> >> > EXE-installer. MSI
> >>> works
> >>> >> >> fine
> >>> >> >> > as expected.
> >>> >> >> > However, I noticed strange behavior with EXE.
> >>> >> >> > After a successful installation, when I run the installer
> again,
> >>> >> >> > the bootstrapperCommand is determined to downgrade.
> >>> >> >> > It was expected that there would be an opportunity to
> >>> >> >> > choose an
> >>> >> action:
> >>> >> >> > modify/repair/remove.
> >>> >> >> > But when I skipped the downgrade action in debugging and
> >>> >> >> > chose
> >>> the
> >>> >> >> remove
> >>> >> >> > action,
> >>> >> >> > the uninstall didn't happen.
> >>> >> >> > note: I use WixManagedBootstrapperApplicationHost and
> >>> >> >> > WixDotNetCoreBootstrapperApplicationHost.
> >>> >> >> > What am I doing wrong? Can I influence the engine through
> events
> >>> or
> >>> >> >> should
> >>> >> >> > I not do this?
> >>> >> >> > I do not expect a detailed answer, at least the direction
> >>> >> >> > where
> >>> to
> >>> >> move.
> >>> >> >> > Thanks.
> >>> >> >> >
> >>> >> >> > --
> >>> >> >> > Best Regards, Timofey Evsyutkin P.H.D., Software Engineer
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > CONFIDENTIALITY NOTICE: The information contained in this email
> >>> and
> >>> >> >> > attached document(s) may contain confidential information that
> is
> >>> >> >> intended
> >>> >> >> > only for the addressee(s). If you are not the intended
> >>> recipient, you
> >>> >> >> are
> >>> >> >> > hereby advised that any disclosure, copying, distribution or
> the
> >>> >> taking
> >>> >> >> of
> >>> >> >> > any action in reliance upon the information is prohibited. If
> you
> >>> >> have
> >>> >> >> > received this email in error, please immediately notify the
> >>> sender
> >>> >> and
> >>> >> >> > delete it from your system.
> >>> >> >> >
> >>> >> >> >
> >>> ____________________________________________________________________
> >>> >> >> > WiX Toolset Users Mailing List provided by FireGiant
> >>> >> >> > http://www.firegiant.com/
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> ____________________________________________________________________
> >>> >> >> WiX Toolset Users Mailing List provided by FireGiant
> >>> >> >> http://www.firegiant.com/
> >>> >> >>
> >>> >> >
> >>> >>
> >>> >> ____________________________________________________________________
> >>> >> WiX Toolset Users Mailing List provided by FireGiant
> >>> >> http://www.firegiant.com/
> >>> >
> >>> >
> >>>
> >>> ____________________________________________________________________
> >>> WiX Toolset Users Mailing List provided by FireGiant
> >>> http://www.firegiant.com/
> >>
> >>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-users
mailing list