Touch events stop working in a WPF packaged app after using ApplicationData.Current

[asierpn]

Describe the bug

Touch events stop working in a WPF packaged app after using ApplicationData.Current

Steps to reproduce the bug

1. Debug the attached project WpfApp6.zip on a device with a touch screen

2. Tap the Test Touch button, the event is not fired

3. Comment this line of the App.xaml.cs

   var localSettings = ApplicationData.Current.LocalSettings;

4. Test again and now the Touch button works fine

Expected behavior

Touch events must work despite the use of the ApplicationData class.

Screenshots

No response

NuGet package version

Windows App SDK 1.6.3: 1.6.250108002

Packaging type

Packaged (MSIX)

Windows version

Windows 10 version 22H2 (19045, 2022 Update)

IDE

No response

Additional context

No response

[DrusTheAxe]

That's surprising as ApplicationData.Current is just a wrapper over existing Windows ApicationData APIs, none of which have any relation to Touch or other input or GUI systems or APIs

Your WPF app is packaged. What kind of packaged app - what's your manifested EntryPoint, RuntimeBehavior and TrustLevel (or whatever subset you declared) ?

[asierpn]

Yes, it doesn't make sense, but it happens.

There is nothing special about the app package, in the repro project I just created a new WPF app from scratch and packaged it, you can download it and try it out.

[yeelam-gordon]

@DrusTheAxe and @asierpn , I does repro this, no matter in constructor of App or MainWindow, it will cause the TouchEvent not working. It includes all the method I try to call: ApplicationData.GetForUser; ApplicationData.GetForPackageFamily; ApplicationData.GetDefault,

While, if I delay it to call it later, it doesn't have any problem (i.e. don't call it as part of the those initialization, no matter in other place or task.Run)

Given WPF app can use other to load the Appfolder or Setting information instead of depending on ApplicationData, and the Delay loading will be working, any objection to resolve this bug as not in plan?

[asierpn]

@DrusTheAxe I will try to do that, I access ApplicationData so early because I use the Preferences class to retrieve the user's application settings, then I will have to find another way to store and retrieve user settings.

[yeelam-gordon]

@DrusTheAxe I will try to do that, I access ApplicationData so early because I use the Preferences class to retrieve the user's application settings, then I will have to find another way to store and retrieve user settings.

Good to know your scenario. From my test before, if you delay just a little bit instead of in Contructor to access the ApplicationData, then there will be no problem.
In my test, like Task.Run or access it in other Event or Property has no problem on impacting Touch.

[ekalchev]

Maybe this is related dotnet/wpf#2393. Try the workaround

[DrusTheAxe]

Maybe this is related dotnet/wpf#2393. Try the workaround

Yes, that (or something like it) does sound possible. Using COM on a thread before COM is properly initialized for use on that thread can be a 'fun' source of problems.

Sorry, I'm not deeply versed in WPF and especially it's initialization flows to say more. I certainly see no reason why the Preferences API would matter (unless ApplicationData gets called w/o initializing COM).

[mominshaikhdevs]

I certainly see no reason why the Preferences API would matter (unless ApplicationData gets called w/o initializing COM).

yet, another MSIX bug. 😂

Using COM on a thread before COM is properly initialized for use on that thread can be a 'fun' source of problems.

[asierpn]

I'm away for a few weeks and can't test your wokarounds, but delaying the call to ApplicationData a bit doesn't seem to be a problem in our scenario and I'll try it first.

[riverar]

The problem here is you're using ApplicationData.Current.LocalSettings with a runFullTrust app. That API is not supported outside of AppContainer and will cause problems. Replace it with ApplicationDataManager.CreateForPackageFamily(...).LocalSettings.

Related: #2639

[asierpn]

I've tried by moving the initialization code inside a Task.Run and it's enough to get rid of the issue.

Thanks!

[mominshaikhdevs]

The problem here is you're using ApplicationData.Current.LocalSettings with a runFullTrust app. That API is not supported outside of AppContainer and will cause problems.

From my test before, if you delay just a little bit instead of in Contructor to access the ApplicationData, then there will be no problem. In my test, like Task.Run or access it in other Event or Property has no problem on impacting Touch.

this API has nothing to do with being run inside or outside LowIL/AppContainer, otherwise the API won't even function at all in MediumIL by delaying the call as others have noted above.

this has to be an issue in .NET 5 ≥, in how they handle per thread COM initializations(or RegFreeWinRT initializations), since this issue does not happen in .NET Framework.

[riverar]

@mominshaikhdevs Everything I said above comes directly from Windows engineering and is known correct. (And was verified to be the case in my app targeting .NET Framework 4.x as well.)