Developer warning error with 125% DPI

[bernox89]

Environment

Visual Studio 2022

.NET version

.net 5/6/7

Did this work in a previous version of Visual Studio and/or previous .NET release?

No

Issue description

I'm aware of the Winforms interface design issue with high DPI, as well as visual studio warns you with that info on startup. But I want to give voice to the relevant Microsoft teams, that it has become really ugly and frustrating, not being able to use Winforms design with high DPI monitors, (not to mention the unnerving slowness compared to the net framerwork) in fact today who uses a notebook for development has been kicked out, very discriminating and disrespectful towards developers all over the world, who are using Winforms in 80% of cases to develop on Windows platform, it has become impossible to use visual studio in 100% mode, I am on the verge of giving up everything. I'm sorry to say, but I think Microsoft is not respecting us developers, stopping for a moment to do new things, and last for all the loose ends with Winforms. It has since net 3.0 that I wait for them to solve, and every holy November I am disappointed, I was hoping that everything would be solved with the net 7. Despite this, with the .net 8 we still don't talk about what to improve with DPI. Microsoft doesn't just think about MAUI, it also thinks about us at Winforms.

Steps to reproduce

Any new project

Diagnostics

No response

[RussKie]

Whilst I can empathise, coming with a random rant, generalisations and accusations isn't helpful at all. If you have specific problems please provide details, screenshots, logs, etc. - something that the team can investigate and possibly fix.

[bernox89]

Igor, I know you and I follow you to every November news about the yearly news to the new versions of .Net. Excuse my outburst, but I think it's very common to anyone in my position, and I think there are thousands of developers. I am disappointed when I see Microsoft moving fast on new projects, leaving very important and focal things unfinished like the well-known "years" DPI issues of Winforms. And I am even more disappointed and angry when I see, for example, Devexpress which is an external company that offers a solution to the problem by changing the rendering methodology by adopting DirectX, definitively solving the problem both in debugging and distribution. I don't think that the Devexpress engineers know any more than those of Microsoft, in fact I think the opposite, only that little importance has been given to the seriousness of the problem. In fact, Microsoft is as if indirectly forcing developers to buy from external companies to have a reasonable user experience with Winforms. Igor, you who are a good engineer see how you can help us. I volunteer for any trials, tests and/or solutions offered. Replying to your message, the reported problems occur in any new project or in any case in a project that has a couple of forms and objects. I use two PCs with Windows 11 (desktop with i5 12gen and 16gb of RAM, laptop with Ryzen 7 and 16gb of RAM) and VS 2022 updated up to today's date. Thanks for your attention.

[merriemcgaw]

I do understand your frustrations and I want to assure you that the WinForms engineers have been dealing with the same issues ourselves, and they're very much top of mind for us. We've been discussing internally workable solutions to the Laptop + HighDPI monitor setup that is so common. The entire architecture of the WinForms Designer was always designed to get the dpi of the current monitor and serialize based on that. Obviously, the single, consistent monitor across the enterprise is no longer the norm and developers need to have a consistent dpi in which they design their applications to maintain consistency in multi-monitor scenarios. We've had a couple of interesting proposals from team members on how to change our serialization logic to a consistent dpi setting regardless of the current monitor size, but it's quite challenging to do. Our first priority was to get the out-of-process designer for .NET apps working with as much parity as we're able to get. We've gotten quite far, supporting most of the scenarios we did in the .NET Framework application, and this feature is on the backlog.

I don't have a timeframe that I can promise we will deliver this feature in yet, but do know it's high on our priority list. @dreddy-work may reach out if you have applications that are not working properly in runtime. We've been doing a lot of work in .NET 8 to get to many of the systemic issues in the layout engine that prevented a good scaling experience. The Visual Studio designer side is a separate set of work currently in the investigation stages.

Thank you for raising this feedback, it does go a long way towards helping us prioritize the biggest pain points our developers are facing. There's nothing specifically actionable in this issue for the runtime (which is what this repo is for), so I am going to close the issue. If you want to continue the discussion, feel free to open a discussion topic.

[bernox89]

I look forward to it...Hopefully in .net 8. Thanks for the moment.

[merriemcgaw]

My pleasure. Note that this is more of a serialization issue in the VS Designer, so any improvements would be tied to the VS version a user is running. We'll keep the community posted, and expect a big blog announcement when we get there 🥳 .