The default Print UI dialogue is not shown on the Windows platform when the EntryPoint is set as "Windows.PartialTrustApplication" in Package.appxmanifest.

[deepika134]

Describe the bug

The default Print UI dialogue is not shown on the Windows platform when the EntryPoint is set as "Windows.PartialTrustApplication" in Package.appxmanifest.

Steps to reproduce the bug

1. Run the attached sample on a machine with a Windows platform.
2. Click the button to execute the associated functionality to open the default print dialogue of the Windows platform.
3. Observe that the application does not show the Print preview dialogue.

App1.zip

Expected behavior

When the EntryPoint is set as "$targetentrypoint$" in Package.appxmanifest, it displays the default Print UI dialogue correctly in the Windows platform. However, when the EntryPoint is changed to "Windows.PartialTrustApplication" in Package.appxmanifest, the print dialogue is not shown. The print dialogue should be displayed properly.

Screenshots

No response

NuGet package version

None

Windows version

Windows 10

Additional context

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Open similar issues:

• Exception thrown by ShowPrintUIForWindowAsync method on Windows Server 2019. (#9558), similarity score: 0.74

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[DarranRowe]

Just to be sure, are you using PrintManager?

If so, I wonder if this is a variation of the pickers problem. There is a long running problem where certain UI elements in the UWP namespaces will not accept a HWND if the application is running in an AppContainer. Does IPrintManagerInterop::GetForWindow succeed? (PrintManagerInterop for C#) This should give an instance of PrintManager in applications running outside of an AppContainer and likely just throw with an access denied error when the application is running in the AppContainer.

[deepika134]

@DarranRowe ,

Yes , I am using the PrintManager .

**Does IPrintManagerInterop::GetForWindow succeed?** Yes it works , when set the EntryPoint is set as "$targetentrypoint$" in Package.appxmanifest, it displays the default Print UI dialogue properly in the Windows platform. we are facing the issue , when the EntryPoint is changed to "Windows.PartialTrustApplication" in Package.appxmanifest, the print dialogue is not shown.

[deepika134]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Open similar issues:

• Exception thrown by ShowPrintUIForWindowAsync method on Windows Server 2019. (#9558), similarity score: 0.74

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

The issue mentioned is different from the issue now being reported.

[DarranRowe]

@deepika134

This would be better reported in the Feedback Hub. There are two reasons for this.

1. Everything relevant here is a Windows component. Anything under the Windows root namespace is built in to Windows. PrintManager's fully qualified name is Windows.Graphics.Printing.PrintManager. Also, application packaging is also a feature provided by Windows.
2. If you were to use PrintManager in a desktop application using any other UI framework/library, then the exact same thing would happen if you package the application. You can test this yourself.

I won't lie though, Microsoft has been really unresponsive on these issues. I wrote the report for the file pickers in the Feedback Hub over a year ago, and nothing has really changed. This issue has been known for longer.

[codendone]

Possibly the same issue as #3293.

[deepika134]

@codendone - Both are not the same issue.

[DaveAurionix]

PrintManager in a partial-trust UWP app was working. PrintManager in a partial-trust WinUI 3 app is not due to this error. This is the last issue stopping me porting a UWP app to WinUI 3 🥲.

I'm not sure it is a Windows issue and should be reported through Feedback Hub I only say that because partial-trust UWP apps work fine. It appears to be something new with apps that use the Windows App SDK. Investigation should maybe start with the Windows App SDK.