La finestra di progettazione cambia da .NET Framework (Windows Form .NET)

Progettazione visiva per Windows Form per .NET ha apportato alcuni miglioramenti e modifiche a partire da .NET Framework. Queste modifiche influiscono in gran parte sulle finestre di progettazione dei controlli personalizzati. Questo articolo descrive le differenze principali di .NET Framework.

Visual Studio è un'applicazione basata su .NET Framework e, di conseguenza, Visual Designer visualizzata per Windows Form si basa anche su .NET Framework. Con un progetto .NET Framework, sia l'ambiente di Visual Studio che l'app Windows Form progettata, vengono eseguiti nello stesso processo: devenv.exe. Questo problema si verifica quando si usa un'app .NET (non .NET Framework) Windows Form. Il codice .NET e .NET Framework non può funzionare nello stesso processo. Di conseguenza, Windows Form .NET usa una finestra di progettazione diversa, la finestra di progettazione "out-of-process".

Progettazione out-of-process

La finestra di progettazione out-of-process è un processo denominato DesignToolsServer.exe e viene eseguito lungo il processo di devenv.exe di Visual Studio. Il processo di DesignToolsServer.exe viene eseguito nella stessa versione e piattaforma di .NET configurata per la destinazione dell'app, ad esempio .NET 9 e x64.

Nella finestra di progettazione di Visual Studio vengono creati oggetti proxy .NET Framework per ogni componente e controllo nella finestra di progettazione, che comunicano con gli oggetti .NET reali del progetto nella finestra di progettazione DesignToolsServer.exe .

Finestre di progettazione controlli

Per .NET, le finestre di progettazione dei controlli devono essere codificate con l'API Microsoft.WinForms.Designer.SDK , disponibili in NuGet. Questa libreria è un refactoring delle finestre di progettazione di .NET Framework per .NET. Tutti i tipi di progettazione sono stati spostati in spazi dei nomi diversi, ma i nomi dei tipi sono per lo più uguali. Per aggiornare le finestre di progettazione di .NET Framework per .NET, è necessario modificare leggermente gli spazi dei nomi.

• Le classi di progettazione e altri tipi correlati, ad esempio ControlDesigner e ComponentTray, sono state spostate dallo System.Windows.Forms.Design spazio dei nomi allo Microsoft.DotNet.DesignTools.Designers spazio dei nomi .
• I tipi correlati all'elenco System.ComponentModel.Design di azioni nello spazio dei nomi sono stati spostati nello spazio dei Microsoft.DotNet.DesignTools.Designers.Actions nomi .
• I tipi correlati al comportamento, ad esempio gli strumenti decorativi e le snapline, nello System.Windows.Forms.Design.Behavior spazio dei nomi sono stati spostati nello spazio dei Microsoft.DotNet.DesignTools.Designers.Behaviors nomi .

Editor di tipi personalizzati

Gli editor di tipi personalizzati sono più complessi rispetto alle finestre di progettazione dei controlli. Poiché il processo di Visual Studio è basato su .NET Framework, anche qualsiasi interfaccia utente visualizzata nel contesto di Visual Studio deve essere basata su .NET Framework. Questa progettazione pone un problema, ad esempio, quando si crea un controllo .NET che mostra un editor di tipi personalizzato richiamato facendo clic su …button nella griglia delle proprietà. La finestra di dialogo non può essere visualizzata nel contesto di Visual Studio.

La finestra di progettazione out-of-process gestisce la maggior parte delle funzionalità della finestra di progettazione dei controlli, ad esempio strumenti decorativi, editor di tipi predefiniti e disegno personalizzato. Ogni volta che è necessario visualizzare una finestra di dialogo modale personalizzata, ad esempio la visualizzazione di un nuovo editor di tipi, è necessario replicare la comunicazione client-server proxy-object fornita dalla finestra di progettazione out-of-process. Questo comporta un sovraccarico molto maggiore rispetto al vecchio sistema .NET Framework.

Se le proprietà del controllo personalizzato usano editor di tipi forniti da Windows Form, è possibile usare per EditorAttribute contrassegnare le proprietà con l'editor .NET Framework corrispondente che si vuole usare in Visual Studio. Usando gli editor predefiniti, è possibile evitare il requisito di replicare la comunicazione client-server proxy-object fornita dalla finestra di progettazione out-of-process.

[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

Creare un editor di tipi

Per creare finestre di progettazione personalizzate che forniscono editor di tipi, è necessario un'ampia gamma di progetti, come descritto nell'elenco seguente:

• Control: questo progetto è la libreria di controlli personalizzata che contiene il codice per i controlli. Si tratta della libreria a cui un utente fa riferimento quando vuole usare i controlli.
• Control.Client: Windows Form per il progetto .NET Framework che contiene le finestre di dialogo dell'interfaccia utente della finestra di progettazione personalizzata.
• Control.Server: Windows Form per il progetto .NET che contiene il codice della finestra di progettazione personalizzata per i controlli.
• Control.Protocol: progetto .NET Standard che contiene le classi di comunicazione usate sia dai progetti che Control.Client dai Control.Server progetti .
• Control.Package: progetto di pacchetto NuGet che contiene tutti gli altri progetti. Questo pacchetto viene formattato in modo da consentire a Visual Studio Windows Form per l'host degli strumenti .NET e di usare la libreria di controlli e le finestre di progettazione.

Anche se l'editor dei tipi deriva da un editor esistente, ad esempio ColorEditor o FileNameEditor, è comunque necessario creare la comunicazione client-server proxy-object perché è stato fornito un nuovo tipo di classe dell'interfaccia utente che si vuole visualizzare nel contesto di Visual Studio. Tuttavia, il codice per implementare tale editor di tipi in Visual Studio è molto più semplice.