Updates to .NET Core Windows Forms designer in Visual Studio 16.5 Preview 1

Olia Gavrysh

December 5th, 201992 0

We are happy to announce the new preview version of the .NET Core Windows Forms designer, which is available with the Visual Studio 16.5 Preview 1.

The big news is that the designer is now part of Visual Studio! This means that installing the .NET Core Windows Forms designer from a separate VSIX is no longer needed!

To use the designer:

  • You must be using Visual Studio 16.5 Preview 1 or a later version.
  • You need to enable the designer in Visual Studio. Go to Tools > Options > Environment > Preview Features and select the Use the preview Windows Forms designer for .NET Core apps option.

If you haven’t enabled the Windows Forms designer, you might notice a yellow bar in the upper part of your Visual Studio Preview suggesting you to enable it:

Selecting the Enable link takes you to the same place in Tools > Options > Environment > Preview Features where you can enable the Windows Forms .NET Core designer preview.

What’s new

In this preview version of the designer, we’ve improved reliability and enhanced performance, fixed many bugs, and added the following features:

  • Designer Actions for available controls, such as making a TextBox multiline or adding items to a CheckedListBox.
  • Improved Undo/Redo actions to prevent hangs or incomplete undos.
  • Scrollbars now appear when the form is larger than the visible document window and on Forms with the AutoScroll property set to True and controls outside the visible area of the form.
  • Added GroupBox and Panel container control support.
  • Copy-paste is supported between container controls.
  • Limited Component Tray support.
  • Local resources support.
  • Timer control support.

Features currently under development

Support for the following features is currently on our backlog and being actively addressed:

  • Localization of your own Windows Forms applications.
  • Data-related scenarios including data binding and data-related controls.
  • Document Outline Window.
  • The remaining container controls.
  • MenuStrip and ToolStrip are expected in the next preview.
  • Third-party controls and UserControls.
  • Inherited Forms and UserControls.
  • Tab Order.
  • Tools > Options page for the designer.

Upgrade to .NET Core 3.1

We recommend that you upgrade your applications to .NET Core 3.1 before using the Windows Forms .NET Core designer. Visual Studio may not perform as expected if your project is targeting an earlier version of .NET Core.

In .NET Core 3.1 a few outdated Windows Forms controls (DataGrid, ToolBar, ContextMenu, Menu, MainMenu, MenuItem, and their child components) were removed. These controls were replaced with newer and more powerful ones in .NET Framework 2.0 in 2005 and haven’t been available by default in the designer Toolbox. Moving forward with .NET Core, we had to cut them out of the runtime as well in order to maintain support for areas like high DPI, accessibility, and reliability. For more information please see the announcement blog post.

Under the hood of the new Windows Forms Core designer (or why it takes us so much time)

We know that you’ve noticed: although the Windows Forms .NET Core designer Preview has basic functionalities, it is not mature enough for providing the full Windows Forms experience and we need a little more time to get there. In this chapter we wanted to give you a glimpse into how we are implementing the designer for .NET Core and explain some of the time frames.

The concept

Visual Studio is based on .NET Framework. The Windows Forms Core designer however should enable users to create a visual design for .NET Core apps. If you’ve tried to “mix” .NET Framework and .NET Core projects, you probably know what the challenge is here: .NET Core assemblies cannot be integrated into .NET Framework projects. Because of this (and some other reasons that we don’t want to overwhelm you with), we came up with the following internal concept: whenever the .NET Core designer is started (for example, by double-clicking on a form), a second designer process starts under the hood almost independently of Visual Studio. And that process takes over the .NET Core design part, or better to say – it’s responsible for instantiating the .NET Core based objects that are then rendered on the monitor by the .NET Core process and not the Visual Studio process.

For example, when you drag a Button from the Toolbox onto a form – this action is handled by Visual Studio (devenv.exe process which is .NET Framework). But, once you release the mouse button to drop the Button on the form, all further actions (instantiating a Button, rendering it at a specific location, and so on) are related to .NET Core. That means .NET Framework process can no longer handle it. Instead it calls to a .NET Core process which does the job and also creates the user interface code at runtime, which lives in the InitializeComponent method of a Form or a UserControl. This is the same way the XAML designer works for UWP and .NET Core.

Was there a better way?

There was another approach we could take that would save us a lot of time. We could simply “map” the .NET Core objects, features, and so on to .NET Framework ones. But this approach has significant limitations. The new features, that are available only in .NET Core won’t be available in this “mapped” designer. And we already have quite a few Core-only functionalities such as: the new PlaceholderText property of the TextBox control, the new default font, that is used in Windows Forms .NET Core. And going forward we expect more innovations coming.

That’s why we turned down that idea, and proceeded with the described above “out-of-process approach” that handles new additions to .NET Core very well.

This is how it works

The Property Browser in Visual Studio is based on the .NET Framework. However, thanks to TypeDescriptors, we can create “proxy objects” as a communication link between the two processes at design time to access the actual .NET Core objects in the other (.NET Core) process via inter-process communication. That way, even though the UI is still in Visual Studio and thus is .NET Framework, users will see and edit every single aspect of the Windows Forms .NET Core objects’ functionality.

The downside of this approach is that it requires us to rewrite significant portions of the Framework Windows Forms designer. To do this correctly, with the performance and stability that you expect, we had to set out a significant amount of time. The XAML designer team already developed an out-of-process model for UWP XAML designer support when UWP implemented .NET Standard 2.0. They were able to share much of that architecture with WPF running against .NET Core. This gave a head-start for .NET Core WPF designer, and now it is released and ready for .NET Core developers. The Windows Forms team started working on the designer with the .NET Core 3.0 announcement. We expect to get to feature parity by May 2020, and complete the work by the end of 2020.

The Windows Forms team wants to say THANK YOU! to those who are already testing preview versions of the designer and reporting issues! We know the experience may not be stable and we appreciate your patience and your desire to help us! 🙂

How to report issues

Your feedback and help are important to us! Please report issues or feature requests via the Visual Studio Feedback channel. To do so, select the Send Feedback icon in Visual Studio top-right corner as shown in the following picture and specify that it is related to the “WinForms .NET Core” area.

Olia Gavrysh Senior Product Manager, .NET

Read next

92 comments

Discussion is closed. Login to edit/delete existing comments.

  • Eugene Ivanoff 0

    I don’t have “Use experimental Symbol Search” as you have on screenshot.

  • Eugene Ivanoff 0

    Also, I don’t see “DataGridView” in Toolbox… 😕

    • Merrie McGawMicrosoft employee 0

      DataGridView and other data related scenarios (data binding, etc) will be released in an upcoming Preview. I don’t have a good timeline to share yet, but I want you to know that we are working on getting these key scenarios supported. We understand how important these are for our customers’ development, and that our data support is one of the things that keeps people coming to WinForms year after year.

      • Eugene Ivanoff 0

        Thanks for reply!

  • Daniel Smith 0

    Is there any documentation on what code changes 3rd party control suites will have to make? Is it just a case of targeting their libraries to .NET Standard 2.x?

    • Merrie McGawMicrosoft employee 0

      We will be working on creating documentation for our partners as part of our development efforts. Once we’ve got full UserControl support and third party control support implemented we’ll be working with our partners to create the documentation needed so that our partners can make their 3rd party control suites work. In some cases it may be easy, but in others there will be work on the part of the control developers, as is inevitable with a migration such as this.

      • David Beavon 0

        Thanks for your reply earlier Merrie. Wasn’t trying to be negative… Just recalling my own observations from the past. Maybe some of that doesn’t apply anymore now that .net core is here!

        I was interested to hear about TaskDialog. I use that fairly often and it always seems harder than it should be. As I recall, I think there is an app manifest to select the appropriate version of the commoncontrols dll. It would be nice if there weren’t so many steps involved…

        I’m curious…can you tell me if you see winforms running in a natively compiled arm32 or arm64 process some day? These types of apps seem fast enough with emulation, but I’m eager to know if winforms could ever run natively on the new “surface x” or similar. That would be something to look forward to!

        • Merrie McGawMicrosoft employee 0

          We’re doing our best to reduce the overhead and learn lessons from the past, that’s for certain. And .NET Core, being open source, has made a substantial shift in our thinking. We are much more closely attuned to the WinForms community, and that allows us to do things like work closely with our docs team, the control vendors, and the community to provide what they need from us.

          We should be wrapping up on the TaskDialog work soon in the runtime. Check out our GitHub Repo, there is an active pull request with our current thinking about the TaskDialog. It’s very exciting to take this, it’s the first substantial new functionality we’ve been able to bring into the WinForms runtime side in many years, and it’s a community driven feature!

          ARM64 is certainly on our radar for .NET Core. The clr/corefx already support ARM64, but there is some work that the WinForms and WPF teams will need to do in order to support ARM64. Stay tuned!

  • Dean Jackson 0

    There are several things that hinder WinForms from looking modern, and a big one for me is the TextBox not easily allowing padding (without doing custom rendering which I’ve done before). Will this be corrected in Core WinForms? Some other things are small radio buttons and checkboxes.

    If WinUI 3 eventually gets a nice designer for laying out controls, I’ll switch to that and the new “desktop” app model, and use the new “project template” they release. I like the idea of having a desktop application with Win 10 modern basic controls, but I would want a good designer instead of typing all XAML. I can type HTML all day long for ASP.Net apps, but for complex control layouts in WinForms, I’ve really appreciated the designer.

    • Merrie McGawMicrosoft employee 0

      That’s a great suggestion Dean, thank you for bringing it up. If it’s something that is important to you, we want to hear about it. File an issue on GitHub that we need a TextBox type of solution with padding, and larger CheckBoxes and RadioButtons. We can invite the community to tell us their thoughts and how important it is for everyone, and we can solicit ideas of the best way to approach the problem. These changes aren’t on our radar just yet, but I will be keeping an eye out for more requests of this nature and can work on getting this into the backlog.

  • Santhakumar Munuswamy 0

    I am using Visual Studio 2019 Community 16.5 Preview 1 and creating a window form app using .NET Core. After creating the app will not be able to view designer form and it is getting an error “The designer loader has not been initialized yet. You may only call this method after initialization. Please let me know how to fix it

    • João Antonio Santana 0

      Same here.

    • Денис Мохин 0

      Yes, same for me. I’m stuck now and I dont know, what to do.

  • Kyle 0

    I’m still on the latest stable version (as of 12/15/2019 which is 16.4.1) – Is there anyway to still download the VSIX Extension to use it in that environment?

    I don’t see anything come up when I search on the Visual Studio Marketplace. The VSIX download links in articles like Introducing .NET Core Windows Forms Designer Preview 1 just point to https://aka.ms/winforms-designer which currently redirects here.

    Or do I have to download a separate Preview release? I don’t see an upgrade path from 16.4.1 to 16.5-Preview 1, so presumably I’d need a second side by side install?

    Thanks

    • William Oniszko 0

      did you ever get an answer for this? im very frustrated right now.

  • James Bound 0

    I have Visual Studio 16.5 Preview 1 Core 3.1 all updated, and the toolbox don’t show the Panel or Groupbox in it as showed in your picture…
    Annoying…

    • Olia GavryshMicrosoft employee 0

      That is weird. Could you file an issue using Visual Studio feedback channel, that way we will be able to capture your environment settings and investigate it.

      • Ilgiz Salikhov 0

        Yes yes yes i have same problem…
        Visual Studio 16.5 Preview 1 Core 3.1 all updated, and the toolbox don’t show the Panel or Groupbox in it as showed in your picture…

  • Muhammad Fajrin 0

    Hi Microsoft Team,
    I ran basic WPF .Net Core 3 ( latest version ). When running .exe whether from debug or directly, the button have weird behavior like having hovering effect when hovering over the button ( color changes and the text itself is missing )
    . Is this expected? . I don’t think this is standard behavior anyway.

    Regards
    Fajrin

  • Jesus Rodrigo Acedo Vargas 0

    No version for us folks that don’t like / can’t install preview versions of Visual Studio? 🙁

Feedback usabilla icon