Freigeben über

Der Designer ändert sich seit .NET Framework (Windows Forms .NET)

  • Artikel

Der Visual Designer für Windows Forms für .NET verfügt seit .NET Framework über einige Verbesserungen und Änderungen. Diese Änderungen wirken sich weitgehend auf benutzerdefinierte Steuerelementdesigner aus. In diesem Artikel werden die wichtigsten Unterschiede zu .NET Framework beschrieben.

Visual Studio ist eine .NET Framework-basierte Anwendung, und der visual Designer, den Sie für Windows Forms sehen, basiert auch auf .NET Framework. Bei einem .NET Framework-Projekt werden sowohl die Visual Studio-Umgebung als auch die windows Forms-App, die entwickelt wird, innerhalb desselben Prozesses ausgeführt: devenv.exe. Dies stellt ein Problem dar, wenn Sie mit einer Windows Forms .NET -App (nicht .NET Framework) arbeiten. Sowohl .NET- als auch .NET Framework-Code können nicht innerhalb desselben Prozesses funktionieren. Daher verwendet Windows Forms .NET einen anderen Designer, den "out-of-process"-Designer.

Out-of-Process-Designer

Der Out-of-Process-Designer ist ein Prozess, der als DesignToolsServer.exe bezeichnet wird und entlang des devenv.exe-Prozesses von Visual Studio ausgeführt wird. Der DesignToolsServer.exe-Prozess wird auf derselben Version und Plattform von .NET ausgeführt, für die Ihre App als Ziel eingerichtet wurde, z. B. .NET 9 und x64.

Im Visual Studio-Designer werden .NET Framework-Proxyobjekte für jede Komponente und jedes Steuerelement im Designer erstellt, die mit den realen .NET-Objekten aus Ihrem Projekt im DesignToolsServer.exe-Designer kommunizieren.

Steuerelement-Designer

Für .NET müssen Steuerelementdesigner mit der Microsoft.WinForms.Designer.SDK-API codiert werden, die für NuGet verfügbar ist. Diese Bibliothek ist eine Umgestaltung der .NET Framework-Designer für .NET. Alle Designertypen wurden in verschiedene Namespaces verschoben, aber die Typnamen sind meist identisch. Um Ihre .NET Framework-Designer für .NET zu aktualisieren, müssen Sie die Namespaces ein wenig anpassen.

  • Designerklassen und andere verwandte Typen, z. B. ControlDesigner und ComponentTray, wurden vom System.Windows.Forms.Design-Namespace in den Microsoft.DotNet.DesignTools.Designers-Namespace verschoben.
  • Aktionslistenbezogene Typen im System.ComponentModel.Design-Namespace wurden in den Microsoft.DotNet.DesignTools.Designers.Actions-Namespace verschoben.
  • Verhaltensbezogene Typen, z. B. Adorner und Ausrichtungslinien, im System.Windows.Forms.Design.Behavior-Namespace wurden in den Microsoft.DotNet.DesignTools.Designers.Behaviors-Namespace verschoben.

Benutzerdefinierte Typ-Editoren

Benutzerdefinierte Typ-Editoren sind komplizierter als die Steuerelementdesigner. Da der Visual Studio-Prozess .NET Framework-basiert ist, muss jede Benutzeroberfläche, die im Kontext von Visual Studio angezeigt wird, auch .NET Framework-basiert sein. Dieses Design stellt beispielsweise ein Problem dar, wenn Sie ein .NET-Steuerelement erstellen, das einen benutzerdefinierten Typ-Editor anzeigt, der durch Klicken auf das …button Eigenschaftenraster aufgerufen wird. Das Dialogfeld kann nicht im Kontext von Visual Studio angezeigt werden.

Der Out-of-Process-Designer behandelt die meisten Funktionen des Steuerelement-Designers, wie z. B. Adorner, integrierte Typ-Editoren und benutzerdefiniertes Zeichnen. Wenn Sie ein benutzerdefiniertes modales Dialogfeld anzeigen müssen, z. B. das Anzeigen eines neuen Typ-Editors, müssen Sie die Client-Server-Kommunikation des Proxyobjekts replizieren, die der Out-of-Process-Designer bereitstellt. Dadurch entsteht viel mehr Aufwand als im alten .NET Framework-System.

Wenn Ihre benutzerdefinierten Steuerelementeigenschaften Typ-Editoren verwenden, die von Windows Forms bereitgestellt werden, können Sie die EditorAttribute Eigenschaften mit dem entsprechenden .NET Framework-Editor markieren, den Visual Studio verwenden soll. Durch die Verwendung der integrierten Editoren vermeiden Sie die Anforderung, die vom Out-of-Process-Designer bereitgestellte Clientserverkommunikation des Proxyobjekts zu replizieren.

[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

Erstellen eines Typ-Editors

Um benutzerdefinierte Designer zu erstellen, die Typ-Editoren bereitstellen, benötigen Sie eine Vielzahl von Projekten, wie in der folgenden Liste beschrieben:

  • Control: Dieses Projekt ist Ihre benutzerdefinierte Steuerelementbibliothek, die den Code für Ihre Steuerelemente enthält. Dies ist die Bibliothek, auf die ein Benutzer verweist, wenn er Ihre Steuerelemente verwenden möchte.
  • Control.Client: Ein Windows Forms für .NET Framework-Projekt, das Ihre benutzerdefinierten Designer-UI-Dialogfelder enthält.
  • Control.Server: Ein Windows Forms für .NET-Projekt, das den benutzerdefinierten Designercode für Ihre Steuerelemente enthält.
  • Control.Protocol: Ein .NET-Standardprojekt, das die Kommunikationsklassen enthält, die sowohl von Control.Client- als auch von Control.Server-Projekten verwendet werden.
  • Control.Package: Ein NuGet-Paketprojekt, das alle anderen Projekte enthält. Dieses Paket ist so formatiert, dass visual Studio Windows Forms für .NET Tooling Host hosten und Ihre Steuerelementbibliothek und Designer verwenden kann.

Selbst wenn Ihr Typ-Editor von einem vorhandenen Editor abgeleitet wird, z. B. ColorEditor oder FileNameEditor, müssen Sie diese Clientserverkommunikation mit Proxyobjekten trotzdem erstellen, da Sie einen neuen UI-Klassentyp bereitgestellt haben, den Sie im Kontext von Visual Studio anzeigen möchten. Der Code zum Implementieren dieses Typ-Editors in Visual Studio ist jedoch viel einfacher.

Wichtig

Die Dokumentation, in der dieses Szenario ausführlich beschrieben wird, ist in Arbeit. Verwenden Sie bis zur Veröffentlichung dieser Dokumentation den folgenden Blogbeitrag und das folgende Beispiel, um Sie beim Erstellen, Veröffentlichen und Verwenden dieser Projektstruktur zu unterstützen: