Microsoft-ui-xaml: With Xaml Island, constantly getting Windows.UI.Xaml.Markup.XamlParseException: 'XAML parsing failed.'

[crutkas]

Using the latest or stable nuget, every xaml / code change I need to double launch to test since on first time launch, i get a Windows.UI.Xaml.Markup.XamlParseException: 'XAML parsing failed.'

Setting a break on the App Initialize does seem to fix the issue but it is unclear exactly why this is happening.

The base project from https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/host-custom-control-with-xaml-islands causes this as well.

https://github.com/microsoft/PowerToys/tree/dev/settingsV2 is our public branch we are working out of and it the WPF project is Settings.UI.Runner, UWP is Settings.UI

[ranjeshj]

@ocalvo @danzil This seems to be an issue with the way the projects are setup to build an islands scenario.

[crutkas]

Just a friendly note, PowerToys team is happy to help debug as we'll be a big user of WinUI 3.

[Austin-Lamb]

The "need to build twice" issue is known, but I can't remember where we're tracking it - @ocalvo and @marb2000 can you remind me where that issue is?

[crutkas]

The "need to build twice" issue is known, but I can't remember where we're tracking it - @ocalvo and @marb2000 can you remind me where that issue is?

Any chance this will be fixed for v3?

[ranjeshj]

@Austin-Lamb I don't think this is issue you mention. We have to build the uwp project, make it generate code and then build the wpf host project which includes the generated files. This is not that issue. This issue is that once that build completes, running the app causes a runtime exception saying 'parsing failed'. If you build the entire project again and run it, it runs fine.

[crutkas]

@ranjeshj, you don't even have to build, you just f5. per above, if i put a break at the init, it doesn't need the double.

[Austin-Lamb]

There's a bug somewhere in our targets files that causes folks to need to hit f5 twice pretty often, which sounds like what Clint is hitting.
We do plan to have better tooling for WinUI 3. @crutkas - is it ok if this is only fixed for WinUI 3?

[crutkas]

@austin-lamb we'll be doing a hard shift to 3 but it will cause some serious pain in the short term.

[ranjeshj]

@crutkas Just curious, have you tried using WinUI3 alpha that is currently available ?

[crutkas]

@ranjeshj, no. The guidance from @marb2000 was to use 2.x then migrate.

[Austin-Lamb]

The short term pain is basically unavoidable right now - so I'm going to close this one as the WinUI 3 tooling will be substantially different anyway.

@crutkas - thanks for living with the pain for the moment, I know it's frustrating and impacts productivity.

[crutkas]

this shouldn't be closed unless Winui 3 fixes this right now IMO.

[crutkas]

Can we xref this to the issue that will resolve it too?

[Austin-Lamb]

@crutkas - We have no GitHub issue for tooling for WinUI 3 - WinUI 3 project planning is too large to manage on GitHub so we're using internal processes for that at the moment.

I think your best option is to wait for the first drop of the tooling and try it, or you could reach out internally to see if we have a private drop you could give feedback on before it's ready for public release.

[crutkas]

@Austin-Lamb i'll work with @SavoySchuler for this.