WIX0200: The BootstrapperApplication element contains an unhandled extension element (still)

[stefanq]

I'm experiencing issue #7867 with Wix 5.0.2, but it is unclear to me how to actually resolve this: Reading the last bullet of this migration doc https://wixtoolset.org/docs/fivefour/oopbas/ made me additionally add WixToolset.BootstrapperApplications.wixext.
However, this is of no help, as when trying to build a minimalistic Bundle, I'm experiencing error WIX0200 "The BootstrapperApplication element contains an unhandled extension element 'WixStandardBootstrapperApplication'. Please ensure that the extension for elements in the 'http://wixtoolset.org/schemas/v4/wxs/bal' namespace has been provided".

Also, when adding the latter extension, I also notice the warning WIX6101: "Could not find expected package root folder wixext5. Ensure WixToolset.BootstrapperApplications.wixext/6.0.0-rc.1 is compatible with WiX v5."
The mentioning of 6.0.0-rc.1 in this context is misleading, since as said, I have wix 5.0.2 installed.
So, I had the idea to wipe wix 5.0.2 and install wix 6.0.0-rc.1 (including the WixToolset.BootstrapperApplications.wixext) instead. With this, building the bundle still fails with the same error WIX0200. But why?

MyBundle> wix extension list -g
WixToolset.Bal.wixext 6.0.0-rc.1 (damaged)
WixToolset.BootstrapperApplications.wixext 6.0.0-rc.1

[robmen]

What does your .wixproj look like? Particularly, the PackageReference elements.

[stefanq]

Hello Rob,

thanks for your quick replies!

Actually, I appreciate the way how a burn bundle is specified in terms of a .wsx file in the official documentation and also directly built using the wix build command, and I want to avoid the extra complexity due to a .wixproj, as we don't make any use MS VS in our company.
I'd also expect that a fresh installation of wix and using wix extension add afterward should result in a consistent tool setup.
I'll investigate this a bit further...

[robmen]

You'll find the .wixproj removes complexity. You already have to have dotnet installed because wix.exe depends on it, so with a .wixproj you just dotnet build the directory. That part has nothing to do with Visual Studio.

I've seen lots of people complaining about the complexity of the WiX Toolset. Some things are complex because the WiX Toolset scales to the largest software projects in the world. However, I'm trying very hard to get developers to stop starting in "hard mode" and then complaining when things are hard. Start with "easy mode", use a .wixproj and dotnet build.

[stefanq]

Thanks, in fact the .wxproj makes the build very comfortable!
That said, I'd like to mention a few stumbling blocks I encountered on my way to a valid configuration:

1. In the bundle template given on the burn bundles documentation page, the <MsiPackage> uses an Id attribute, whereas the documentation of the element correctly states it to be CacheId.
2. When I specify a IconSourceFile attribute for a <Bundle>, it has no effect in the UI of the generated bundle.exe. I'm not sure if this relates to issue Icon no longer displayed in the Burn bundle window title and Windows taskbar after upgrading to WiX 5.0.0 #8104 or Not able to set Custom icon on top left corner of installer #8540, but I found no solution for this problem.
3. While building a bundle works flawless with the 5.0.2. SDK, with 6.0.0-rc.1 I get an error NU1301, though: Fehler beim Abrufen von Informationen zu "WixToolset.BootstrapperApplications.wixext" aus der Remotequelle "https://nuget.pkg.github.com/wixtoolset/download/wixtoolset.bootstrapperapplications.wixext/index.json". Response status code does not indicate success: 401 (Unauthorized).
   However, I believe to remember that it once worked last week.

[robmen]

I'm glad to hear the .wixproj made things much more comfortable. That's the goal. To make it the easy path. Quick notes on your other points.

1. CacheId is an extremely advanced feature. If used incorrectly, it can really mess up your bundles' behaviors. So much so, that we've considered removing the attribute completely. How did you go from wanting Id to CacheId?
2. That sounds like Icon no longer displayed in the Burn bundle window title and Windows taskbar after upgrading to WiX 5.0.0 #8104. There is a workaround listed in the issue.
3. A 401 means you don't have access to the NuGet feed. That's a local configuration problem.

[stefanq]

1. Regarding CacheId, Early in development I had an error, probably due to an identifier lacking on an <MsiPackage> element. Since the documentation of that element only describes CacheId, and the description of Id in the documentation of <Package> seemed like a bad match, I went with CacheId, and it immediately worked. Quite a few good reasons for CacheId, but still incorrect, thanks for pointing this out.
2. Ok, it seems I also have to get familiar with the theming aspect.
3. I could resolve it by cleaning my Jenkins workspace, so I guess it maybe got inconsistent due to a lack of cleanups in conjunction with major configuration changes between subsequent builds.