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

Sean Hall r.sean.hall at gmail.com
Mon Aug 1 14:51:24 PDT 2022 

> 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_aeM?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-4C25-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\tools\WixToolset.Bal.wixext.dll"^
>> >> >  -ext
>> >> >
>> >>
>> "~\wix_toolset\.wix4\extensions\WixToolset.Netfx.wixext\4.0.0-source\tools\WixToolset.Netfx.wixext.dll"^
>> >> >  -ext
>> >> >
>> >>
>> "~\wix_toolset\.wix4\extensions\WixToolset.Util.wixext\4.0.0-source\tools\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_aeM?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/
>
>

More information about the wix-users mailing list