{"id":44473,"date":"2023-02-23T10:15:00","date_gmt":"2023-02-23T18:15:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=44473"},"modified":"2023-02-27T10:22:54","modified_gmt":"2023-02-27T18:22:54","slug":"winforms-codegen-update","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/winforms-codegen-update\/","title":{"rendered":"Updated Modern Code Generation for WinForm’s InitializeComponent"},"content":{"rendered":"

When you create a WinForms Form or User Control with the WinForms Designer in\nVisual Studio, it does not have a special definition or file format like XML or\nHTML to represent the user interface. From the beginning, the only format\nWinForms has used is program code. A Form or User Control defined in a WinForms\nVisual Basic project gets saved into VB Code. In a C# project, that is C# code.\nThat code will be placed in a dedicated Designer file, which sits behind the\nactual Form code file and contains the code to control the UI.<\/p>\n

\"Screenshot<\/p>\n

When your Form or User Control needs to be opened again inside of the WinForms\nDesigner, that code is interpreted and – based on the resulting object graph –\nthe Form\/User Control gets recreated in the Designer. That is the reason we call\nthe process of saving a Form CodeDOM serialization<\/em>.\nCodeDOM<\/a>\nhere refers to an object model (the Code D<\/strong>ocument O<\/strong>bject M<\/strong>odel<\/em>)\nwhich allows the developer to define aspects of a program or part of a program\nby objects of certain types.<\/p>\n

\"Screenshot<\/p>\n

While CodeDOM is pretty flexible, can be extended comparatively easily and\nsupports more languages than Visual Basic or C#, generating a CodeDOM graph from\nan existing code file is a completely different beast. And although CodeDOM\nhas<\/em> the option to actually write a code file for particular languages through\nits existing Compiler\nimplementation<\/a>,\nthe style of that resulting code is the same it has been from the beginning of\n.NET Framework, which is in many cases no longer up to current coding standards.<\/p>\n

In WinForms, when you design a Form, everything which is relevant is generated\nin one method per Form or User Control. That method (amongst a bit of\ninfrastructure and initialization code in addition) is called\nInitializeComponent<\/code>.<\/p>\n

This method is called by a Form’s constructor unconditionally. In the C# case\nthat’s pretty obvious, where a new Form which you add to your project, always\nhas that constructor and the required call:<\/p>\n

    public partial class Form1 : Form\r\n    {\r\n        public Form2()\r\n        {\r\n            InitializeComponent();\r\n        }\r\n    }<\/code><\/pre>\n
In Visual Basic, if you don’t add a constructor Sub New<\/code> explicitly, the Visual\nBasic compiler inserts the call to InitializeComponent<\/code> automatically in the\nbackground. If you however add a constructor to the code file, the editor also\ninserts the call to InitializeComponent<\/code> in the VB code:<\/p>\n
Public Class Form1\r\n\r\n    Sub New()\r\n\r\n        ' This call is required by the designer.\r\n        InitializeComponent()\r\n\r\n        ' Add any initialization after the InitializeComponent() call.\r\n\r\n    End Sub\r\nEnd Class<\/code><\/pre>\n
\n
Note that in Visual Basic, the Inherits<\/code> statement, which lets your new Form\nclass inherit from the System.Windows.Forms.Form<\/code> base class, in contrast to C#\nis only part of the Designer code behind file. In VB it’s also sufficient for a\npartial class only to state the Partial<\/code>\nkeyword<\/a>\nin one of the partial class’ code files. That is the reason why a Visual Basic\nWinForms Form code file does not contain anything but the Form’s class\ndefinition by default.<\/p>\n<\/blockquote>\n
Up to recently, the WinForms Designer used the CodeModel\nInterface<\/a>\nto interpret source code of the different programming language to build the\nrequired internal CodeDOM graph for the Designer to hold a Form’s or a User\nControl’s definition. But we changed that.<\/p>\n
Enter Roslyn<\/h2>\n
WinForms introduced with Visual Studio 2022 version 17.5 a modernized way to\nread and generate the code for InitializeComponent<\/code> for the WinForms\nOut-of-Process\nDesigner<\/a>.\nIt does so by using the APIs of the .NET Compiler\nPlatform<\/a> – better know\nas the Roslyn SDK – for all related tasks. The Roslyn Compiler is a set of\nopen-source compilers and code analysis APIs for .NET languages. It allows\ndevelopers to write, analyze, and manipulate code in C# and Visual Basic .NET\nusing modern language features. It also provides a rich set of diagnostic and\ncode refactorings to improve code quality and developer productivity. It is the\ngold standard and the current best practice for code generation in C# and VB.\nAnd, since it’s the same tooling that is used for compilation and build purposes\ninside Visual Studio for any C# or Visual Basic project its code generation\nresult is completely in-line with current coding standards.<\/p>\n
Also, since the Roslyn compiler provides certain APIs to not know only about the\ncorrect syntax of a particular statement, command or method<\/a>, but also about the\nsemantics of a code block<\/a> already at WinForms design time, the WinForms designer\ncan point out potential problems with the code inside of InitializeComponent<\/code>\nfar earlier and more precisely than before. So, it not only knows when you’ve\nspelled ‘Buttne’ wrong – it would also know that a variable with a typo defined\ninside of InitializeComponent<\/code> would be an unknown symbol, and be able to point\nthat out.<\/p>\n
But there is a series of additional benefits:<\/p>\n