Compartir a través de

Cambios del diseñador desde .NET Framework (.NET de Windows Forms)

  • Artículo

El Diseñador visual para Windows Forms para .NET ha tenido algunas mejoras y cambios desde .NET Framework. Estos cambios afectan en gran medida a los diseñadores de controles personalizados. En este artículo se describen las diferencias clave de .NET Framework.

Visual Studio es una aplicación basada en .NET Framework y, como tal, el Diseñador visual que ve para Windows Forms también se basa en .NET Framework. Con un proyecto de .NET Framework, tanto el entorno de Visual Studio como la aplicación de Windows Forms que se está diseñando se ejecutan en el mismo proceso: devenv.exe. Esto supone un problema al trabajar con una aplicación de .NET (no .NET Framework) de Windows Forms. El código de .NET y .NET Framework no puede funcionar en el mismo proceso. Como resultado, el .NET de Windows Forms usa un diseñador diferente, el diseñador "fuera de proceso".

Diseñador fuera de proceso

El diseñador fuera de proceso es un proceso denominado DesignToolsServer.exe y se ejecuta a lo largo del proceso de devenv.exe de Visual Studio. El proceso de DesignToolsServer.exe se ejecuta en la misma versión y plataforma de .NET que la aplicación se ha configurado como destino, como .NET 7 y x64.

En el diseñador de Visual Studio, se crean objetos proxy de .NET Framework para cada componente y control en el diseñador, que se comunican con los objetos .NET reales del proyecto en el diseñador de DesignToolsServer.exe.

Diseñadores de controles

Para .NET, los diseñadores de controles deben codificarse con la API de Microsoft.WinForms.Designer.SDK, disponible en NuGet. Esta biblioteca es una refactorización de los diseñadores de .NET Framework para .NET. Todos los tipos de diseñador se han movido a diferentes espacios de nombres, pero los nombres de tipo son principalmente los mismos. Para actualizar los diseñadores de .NET Framework para .NET, debe ajustar los espacios de nombres un poco.

  • Las clases del diseñador y otros tipos relacionados, como ControlDesigner y ComponentTray, se han movido del espacio de nombres System.Windows.Forms.Design al espacio de nombres Microsoft.DotNet.DesignTools.Designers.
  • Los tipos relacionados con la lista de acciones del espacio de nombres System.ComponentModel.Design se han movido al espacio de nombres Microsoft.DotNet.DesignTools.Designers.Actions.
  • Los tipos relacionados con el comportamiento, como adornos y líneas de ajuste, en el espacio de nombres System.Windows.Forms.Design.Behavior se han movido al espacio de nombres Microsoft.DotNet.DesignTools.Designers.Behaviors.

Editores de tipos personalizados

Los editores de tipos personalizados son más complicados que los diseñadores de controles. Dado que el proceso de Visual Studio está basado en .NET Framework, cualquier interfaz de usuario que se muestre en el contexto de Visual Studio también debe estar basada en .NET Framework. Este diseño plantea un problema, por ejemplo, al crear un control .NET que muestre un editor de tipos personalizado invocado haciendo clic en el button … de la cuadrícula de propiedades. El cuadro de diálogo no se puede mostrar en el contexto de Visual Studio.

El diseñador fuera de proceso controla la mayoría de las características del diseñador de controles, como adornos, editores de tipos integrados y pintura personalizada. Cada vez que necesite mostrar un diálogo modal personalizado, como mostrar un nuevo editor de tipos, necesitará replicar esa comunicación cliente-servidor proxy-objeto que proporciona el diseñador fuera de proceso. Esto crea mucha más sobrecarga que el sistema de .NET Framework anterior.

Si las propiedades de control personalizadas usan los editores de tipos proporcionados por Windows Forms, puede usar el EditorAttribute para marcar las propiedades con el editor de .NET Framework correspondiente que quiere que use Visual Studio. Mediante el uso de los editores integrados, se evita el requisito de replicar la comunicación de cliente-servidor proxy-objeto proporcionada por el diseñador fuera de proceso.

[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

Creación de un editor de tipos

Para crear diseñadores personalizados que proporcionen editores de tipos, necesitará una variedad de proyectos, como se describe en la lista siguiente:

  • Control: este proyecto es la biblioteca de control personalizada que contiene el código de los controles. Esta es la biblioteca a la que un usuario haría referencia cuando quiera usar los controles.
  • Control.Client: un proyecto de Windows Forms para .NET Framework que contiene los cuadros de diálogo de interfaz de usuario del diseñador personalizado.
  • Control.Server: un proyecto de Windows Forms para .NET que contiene el código de diseñador personalizado para los controles.
  • Control.Protocol: un proyecto de .NET Standard que contiene las clases de comunicación que usan los proyectos Control.Client y Control.Server.
  • Control.Package: un proyecto de paquete NuGet que contiene todos los demás proyectos. Este paquete tiene el formato de una manera que permite a la herramienta Windows Forms de Visual Studio para .NET hospedar y usar la biblioteca de controles y los diseñadores.

Incluso si el editor de tipos se deriva de un editor existente, como ColorEditor o FileNameEditor, todavía tiene que crear esa comunicación cliente-servidor proxy-objeto porque ha proporcionado un nuevo tipo de clase de interfaz de usuario que desea mostrar en el contexto de Visual Studio. Sin embargo, el código para implementar ese editor de tipos en Visual Studio es mucho más sencillo.

Importante

La documentación que describe este escenario en detalle está en curso. Hasta que se publique esa documentación, use la siguiente entrada de blog y ejemplo para guiarle en la creación, publicación y uso de esta estructura de proyecto: