Really weird thing about .NET / NuGet / WinForms and compilation issues
-
I recently posted about my issues with a Nuget package. To recap: It's a Nuget package by Syncfusion which allows displaying and manipulation XLS files. I'm using it in WinForms where it consists of two controls: The actual Spreadsheet display (basically looking identical to Excel's row/column grid) and the SpreadsheetRibbon which emulates the Office Ribbon in look and feel.
On my desktop PC the application is doing everything it should: Displaying properly in the Designer, compiling and running.
However, on my Surface Book 3, this application does not run at all. Neither does it compile, nor does the preview work - but only for the Ribbon control. As soon as I try to drag the Ribbon control onto the designer view, I get an exception, basically stating that a required parameter is null. From the stack trace, it's something inside the control's code and thus firmly outside anything I could do. Compiling leads to the same exception and trying to run the compiled application (copied over from the desktop) also yields the same exception (viewable in the Event Viewer).
This, however, is not related to the source code I wrote. If I spin up a blank WinForms and then try to use the RIbbon control, I once again get the exception.I just installed VisualStudio in the same configuration as on my desktop and the Surface Book on a Surface Go 2 (took a long time due to how underpowered that thing is).
Guess what: No problems. The designer shows the proper preview and the application compiles (slowly. Veeeeery slowly).
Oh, and because I really wanted to get to the bottom of this: The Surface Book 3 is basically a virgin Windows 11 installation, I just wiped it clean and only installed VS (again in the exact config as the other two). Didn't help.
Anybody have a clue what else it might be?
-
Okay, just figured it out. Jesus Christ. So, I was going over it again and again what was different. I figured it must be something hardware related as the software configuration was as identical as I could make it be.
I first looked at what options there were on the Surface Book's UEFI. Disabling SMT (aka Hyperthreading) didn't do it (and why should it, my desktop has an i9-12900 in it...) and disabling the dGPU also didn't do anything... wait.... graphics.
Visual Studio was displaying a notification banner above the editor where it said something about the desktop being set to 200% scaling (because everything is tiny otherwise on a Book's display). And the stack trace of the application mentioned something about a bitmap and
System.DrawingSurely not...?Well, to make a long story short, setting the desktop scale factor to 100% yields both a working designer and a working app. Guess the guys at Syncfusion overlooked a scaling issue at this control.
-
@Rhywden said in Really weird thing about .NET / NuGet / WinForms and compilation issues:
Guess the guys at Syncfusion overlooked a scaling issue at this control.
Oops.
That's a nasty one to track down... Of course, it would have blown up immediately for me since none of my systems (well, ok, one - that I use only at dog shows) run at 100%. (Desktop is 2 4K monitors at 150% and the main laptop is 4K at 200% (or 250?, can't remember))
-
@dcon Well, I'm hopeful that they can fix this fast as all the other controls don't have this issue.
-
-
