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

Tue Jul 26 10:16:30 PDT 2022

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