[wix-users] Experience of build with WiX 4 Toolset

Timofey Evsyutkin goldghost.oomphi.suppository at gmail.com
Tue Oct 18 23:48:05 PDT 2022 

The implementation WixToolset.Mba.Core.Engine throws more exceptions
than expected from the interface WixToolset.Mba.Core.IEngine.
I think there are not enough comments.

A question.
Is there any way to build a workable DotNETCore MBA
without adding a PackageReference of the WixToolset.Dnc.HostGenerator
explicitly?

вт, 9 авг. 2022 г. в 21:04, Rob Mensching <rob at firegiant.com>:

> > 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