Microsoft ReportViewerControl stopped working after an update
IncubusRK opened this issue · comments
After upgrade from wine-6.17 with wine-mono-6.4.0 to wine-6.18 with wine-mono-6.4.0,
application that use Microsoft.Reporting.WinForms.ReportViewer throwing System.Drawing.Printing.InvalidPrinterException when try to call Microsoft.Reporting.WinForms.ReportViewer.GetPageSettings ().
System has installed and working printer (in wine-6.17 it's work fine).
Direct call
var ps = new System.Drawing.Printing.PrinterSettings();
ps.GetHdevmode();
works.
Native apps printing works too, for example "wine notepad"
Unfortunately I could not create a test app without using SQL server.
You may tell you the way to get around this problem.
Stack trace
System.Drawing.Printing.InvalidPrinterException: No printers are installed.
at System.Drawing.Printing.PrinterSettings.GetHdevmodeInternal (System.String printer) [0x00026] in <1a1595a6b46049cd9f9231ce49354991>:0
at System.Drawing.Printing.PrinterSettings.GetHdevmodeInternal () [0x00007] in <1a1595a6b46049cd9f9231ce49354991>:0
at System.Drawing.Printing.PrinterSettings.GetHdevmode () [0x00000] in <1a1595a6b46049cd9f9231ce49354991>:0
at System.Drawing.Printing.PageSettings.get_PaperSource () [0x00008] in <1a1595a6b46049cd9f9231ce49354991>:0
at Microsoft.Reporting.ReportViewerUtils.DeepClonePageSettings (System.Drawing.Printing.PageSettings pageSettings) [0x000a6] in <608d3c0ec3f84019a56f7c6420b69c90>:0
at Microsoft.Reporting.WinForms.ReportViewer.GetPageSettings () [0x00006] in <608d3c0ec3f84019a56f7c6420b69c90>:0
at (wrapper remoting-invoke-with-check) Microsoft.Reporting.WinForms.ReportViewer.GetPageSettings()
at UILibrary.Reports.FormMSReport.ShowPrintDialog ()
The place where exception occurs
https://github.com/mono/corefx/blob/9174bbeb7e1e4d3dc51f4f82243cbf4c62c61efa/src/System.Drawing.Common/src/System/Drawing/Printing/PrinterSettings.Windows.cs#L881
Probably changed behavior of SafeNativeMethods.DocumentProperties
Last update has changes in DocumentPropertiesW and DocumentPropertiesA
https://source.winehq.org/git/wine.git/commitdiff/8eddb793a6f287cdaa3d9952d07e752b7755a3ca
https://source.winehq.org/git/wine.git/commitdiff/68feb134af0538d7fc589c2ddb6403de9cea1055
Additional info printed on console
00fc:err:winspool:DocumentPropertiesW Could not load config module for L"PRINTER_NAME"
PS also created https://bugs.winehq.org/show_bug.cgi?id=51815
Looking at Jacek's reply on the bug, it's possible that Mono's implementation of System.Printing was more forgiving and accepted a non-existent printer name.
It seems the error message is misleading and will report "no printers installed" no matter what error DocumentPropertiesW returns.
A quick test on WIndows shows that DocumentPropertiesW does expect a valid name. "PDF" doesn't work, but "Microsoft Print to PDF" does.
Perhaps the application is getting an invalid printer name from somewhere else. Does the name that shows in the DocumentPropertiesW message match a printer that shows up in wine notepad's printer settings dialog?
A quick test on WIndows shows that DocumentPropertiesW does expect a valid name. "PDF" doesn't work, but "Microsoft Print to PDF" does.
Perhaps the application is getting an invalid printer name from somewhere else. Does the name that shows in the DocumentPropertiesW message match a printer that shows up in wine notepad's printer settings dialog?
I did not pay attention to hardcoded value. Printer with name PDF exist on my test PC. I upload fixed test case to https://bugs.winehq.org/show_bug.cgi?id=51815 and debug logs
This has shown up as a test failure on my dev machine. CI probably didn't catch it because it wouldn't have any printers set up.
Curiously, the x86_64.MonoTests.System.Drawing.Printing.PageSettingsTest:CloneTest fails for me but the x86 test passes.
From information that I added to the Winehq bug, it seems clear to me that wine-mono is not at fault, and this is a major problem with Wine. Thanks for the report, I'm glad you got my attention on this, but I am going to close it now in favor of the Winehq bug.