LaunchUriOrFileAction prevent application to pass Windows App Certification Kit

[kant2002]

Describe the bug
When WPF application packed as UWP application, and submitted to "Windows App Certification Kit" for validation, this package gives FAILED status for the application,

Error Found: The blocked executables test has detected the following errors:
File al2ka\Microsoft.Xaml.Behaviors.dll contains a reference to a "Launch Process" related API System.Diagnostics.Process.Start

even if I do not use behaviour LaunchUriOrFileAction which trigger the error

[pedrolamas]

Hi @kant2002, I believe that should not be happening and will investigate further and report back with my findings, but this seems to be yet another store app ingestion issue (though only Microsoft will be able to confirm that)

[kant2002]

Hi @pedrolamas . That was quite fast 😄 I do not directly use XamlBehaviorsWpf in my project, but rather import MahApps.Metro package which use ControlzEx which use XamlBehaviorsWpf, but still this is very simple project, and I do not use anything fancy. Just FYI.

[pedrolamas]

Ah, that does change things... Although you don't use it, I suspect that somehow it's getting output as a dependency from MahApps.Metro.

If that is the case, I recommend opening an issue directly with that repo, as there will be little to nothing we can do from this side.

[kant2002]

But I'm almost sure that issue will still appear, if I just create plain WPF + XamlBehaviorsWpf. Just presence of XamlBehaviorsWpf in the bin folder will trigger the issue, MahApps itself, does not trigger the issue itself. If you like, Do I need to create small application, add XamlBehaviorsWpf as dependency and validate that issue will be there in most simple case?

[kant2002]

If you can split this project on 2 packages, one, lets' call it Microsoft.Xaml.Behaviors.Core would contains just plumbing needed for writing basic behaviours, and Microsoft.Xaml.Behaviors which will use Microsoft.Xaml.Behaviors and contains all the packages, that allow for

• backward compatibility
• WPF only packages can be living inside the Microsoft.Xaml.Behaviors and others in Microsoft.Xaml.Behaviors.Core.
  Otherwise for just one behavior, I cannot migrate application from WPF inside UWP deployment model.

[runceel]

@kant2002
In my understanding, the error is an optional category, right?
You can ignore the error, if you don't use it.

All apps that is published to Microsoft Store have to be able to run on Windows 10 S mode.
Windows 10 S mode can't execute apps that are from outside of MS Store.
The error is for let you notice launching other apps directly in your app like 'Process.Start("Path to other exe file outside of MS store");`.

[kant2002]

@runceel support for long reply. No, as far as I'm aware it is not optional, at least message indicate that this is blocker, and I cannot find a way how to suppress that message.

[runceel]

@kant2002
I got a result as PASSED from Windows App Cert(WAC) test, even if the app depends Microsoft.Xaml.Behaviors.Wpf package.

• Create a WPF App(.NET Framework) project
• Create a Windows Application Package Project
• Add the WPF App to an Application node of the Windows Application Package Project.
• Change app icons, tile icon and logs from default icons(It's required
  to pass the test)
• Add Microsoft.Xaml.Behaviors.Wpf package to the WPF App project.
• Create a msix package
• Check the package using WAC
• The result is as below:
  

Package sanity test is still FAILED.

But the package can be submitted to Microsoft Store, because Package sanity test is under Results for optional tests category.

Do I misunderstand about this issue?

[kant2002]

Thanks. Indeed this is me who misunderstand the issue. I really not that familiar with publishing process. and any "red" things is worrysome for me. If this is optional, and do not prevent from submitting, I'm fine. Let me double-check, but I almost sure that problem somewhere between keyboard and monitor.

[brianlagunas]

Thank you for updating this issue. Due to this new information, we will close this. If this continues to be a problem or does indeed cause store publish failure, we may need to bring this to the Windows Store team for further investigation.