Le concepteur change depuis .NET Framework (Windows Forms .NET)

Le Concepteur visuel pour Windows Forms pour .NET a apporté des améliorations et des modifications depuis .NET Framework. Ces modifications affectent en grande partie les concepteurs de contrôles personnalisés. Cet article décrit les principales différences de .NET Framework.

Visual Studio est une application basée sur .NET Framework et, par conséquent, le Concepteur visuel que vous voyez pour Windows Formest également basé sur .NET Framework. Avec un projet .NET Framework, l’environnement Visual Studio et l’application Windows Formen cours de conception, s’exécutent dans le même processus : devenv.exe. Cela pose un problème lorsque vous utilisez une application .NET (et non .NET Framework) Windows Form. Le code .NET et .NET Framework ne peut pas fonctionner dans le même processus. Par conséquent, Windows Forms .NET utilise un autre concepteur, le concepteur « out-of-process ».

Concepteur hors processus

Le concepteur out-of-process est un processus appelé DesignToolsServer.exe et s’exécute le long du processus devenv.exe de Visual Studio. Le processus DesignToolsServer.exe s’exécute sur la même version et la même plateforme de .NET que votre application a été configurée pour cibler, comme .NET 7 et x64.

Dans le concepteur Visual Studio, les objets proxy .NET Framework sont créés pour chaque composant et contrôle sur le concepteur, qui communiquent avec les objets .NET réels de votre projet dans le concepteur DesignToolsServer.exe .

Concepteurs de contrôles

Pour .NET, les concepteurs de contrôles doivent être codés avec l’API Microsoft.WinForms.Designer.SDK , disponibles sur NuGet. Cette bibliothèque est une refactorisation des concepteurs .NET Framework pour .NET. Tous les types de concepteurs ont été déplacés vers des espaces de noms différents, mais les noms de types sont principalement identiques. Pour mettre à jour vos concepteurs .NET Framework pour .NET, vous devez ajuster les espaces de noms un peu.

• Les classes de concepteur et d’autres types associés, tels que ControlDesigner et ComponentTray, ont été déplacées de l’espace System.Windows.Forms.Design de noms vers l’espace Microsoft.DotNet.DesignTools.Designers de noms.
• Les types liés à la liste d’actions dans l’espace System.ComponentModel.Design de noms ont été déplacés vers l’espace Microsoft.DotNet.DesignTools.Designers.Actions de noms.
• Les types liés au comportement, tels que les ornements et les alignements, dans l’espace System.Windows.Forms.Design.Behavior de noms ont été déplacés vers l’espace Microsoft.DotNet.DesignTools.Designers.Behaviors de noms.

Éditeurs de types personnalisés

Les éditeurs de types personnalisés sont plus compliqués que les concepteurs de contrôles. Étant donné que le processus Visual Studio est basé sur .NET Framework, toute interface utilisateur affichée dans le contexte de Visual Studio doit également être basée sur .NET Framework. Cette conception pose un problème, par exemple, lorsque vous créez un contrôle .NET qui affiche un éditeur de type personnalisé appelé en cliquant sur le … bouton dans la grille de propriétés. La boîte de dialogue ne peut pas être affichée dans le contexte de Visual Studio.

Le concepteur hors processus gère la plupart des fonctionnalités du concepteur de contrôles, telles que les ornements, les éditeurs de types intégrés et la peinture personnalisée. Chaque fois que vous devez afficher une boîte de dialogue modale personnalisée, telle que l’affichage d’un nouvel éditeur de type, vous devez répliquer cette communication client-serveur client proxy que le concepteur hors processus fournit. Cela crée beaucoup plus de surcharge que l’ancien système .NET Framework.

Si vos propriétés de contrôle personnalisées utilisent des éditeurs de type fournis par Windows Forms, vous pouvez utiliser celle-ci EditorAttribute pour marquer vos propriétés avec l’éditeur .NET Framework correspondant que Visual Studio doit utiliser. En utilisant les éditeurs intégrés, vous évitez d’avoir à répliquer la communication client-serveur client proxy fournie par le concepteur hors processus.

[Editor("System.Windows.Forms.Design.FileNameEditor, System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",
        "System.Drawing.Design.UITypeEditor, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")]
public string? Filename { get; set; }

<Editor("System.Windows.Forms.Design.FileNameEditor, System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a", "System.Drawing.Design.UITypeEditor, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")>
Public Property Filename As String

Créer un éditeur de type

Pour créer des concepteurs personnalisés qui fournissent des éditeurs de type, vous aurez besoin d’un large éventail de projets, comme décrit dans la liste suivante :

• Control: ce projet est votre bibliothèque de contrôles personnalisée qui contient le code de vos contrôles. Il s’agit de la bibliothèque qu’un utilisateur référence lorsqu’il souhaite utiliser vos contrôles.
• Control.Client: un projet Windows Formpour .NET Framework qui contient vos boîtes de dialogue d’interface utilisateur de concepteur personnalisées.
• Control.Server: un projet Windows Formpour .NET qui contient le code du concepteur personnalisé pour vos contrôles.
• Control.Protocol: projet .NET Standard qui contient les classes de communication utilisées à la fois par les projets et Control.Server les Control.Client projets.
• Control.Package: projet de package NuGet qui contient tous les autres projets. Ce package est mis en forme de manière à permettre à Visual Studio Windows Forms pour l’hôte d’outils .NET et d’utiliser votre bibliothèque de contrôles et concepteurs.

Même si votre éditeur de type dérive d’un éditeur existant, par ColorEditor exemple, FileNameEditorvous devez toujours créer cette communication client-serveur client-objet proxy, car vous avez fourni un nouveau type de classe d’interface utilisateur que vous souhaitez afficher dans le contexte de Visual Studio. Toutefois, le code permettant d’implémenter cet éditeur de type dans Visual Studio est beaucoup plus simple.