Compartilhar via

As mudanças do designer desde o .NET Framework

O Visual Designer para Windows Forms para .NET teve algumas melhorias e alterações desde o .NET Framework. Essas alterações afetam amplamente os designers de controle personalizados. Este artigo descreve as principais diferenças do .NET Framework.

O Visual Studio é um aplicativo baseado no .NET Framework e, como tal, o Visual Designer que você vê para o Windows Forms também se baseia no .NET Framework. Com um projeto .NET Framework, o ambiente do Visual Studio e o aplicativo Windows Forms que está sendo projetado são executados no mesmo processo: devenv.exe. Isso representa um problema quando você está trabalhando com um aplicativo Windows Forms .NET (não .NET Framework). O código do .NET e do .NET Framework não pode funcionar no mesmo processo. Como resultado, o Windows Forms .NET usa um designer diferente, o designer "fora do processo".

Designer externo ao processo

O designer fora do processo é um processo chamado DesignToolsServer.exe, e é executado junto com o processo de devenv.exe do Visual Studio. O processo DesignToolsServer.exe é executado na mesma versão e plataforma do .NET para a qual seu aplicativo foi configurado, como o .NET 9 e x64.

No designer do Visual Studio, objetos proxy do .NET Framework são criados para cada componente e controle, estabelecendo comunicação com os objetos .NET reais do seu projeto no designer DesignToolsServer.exe.

Designers de controle

Para o .NET, os designers de controle precisam ser codificados com a Microsoft.WinForms.Designer.SDK API, disponível no NuGet. Essa biblioteca é uma refatoração dos designers do .NET Framework para .NET. Todos os tipos de designer foram movidos para namespaces diferentes, mas os nomes dos tipos são basicamente os mesmos. Para atualizar seus designers do .NET Framework para o .NET, você deve ajustar um pouco os namespaces.

  • Classes de designer e outros tipos relacionados, como ControlDesigner e ComponentTray, foram movidos do System.Windows.Forms.Design namespace para o Microsoft.DotNet.DesignTools.Designers namespace.
  • Os tipos relacionados à lista de ações no System.ComponentModel.Design namespace foram movidos para o Microsoft.DotNet.DesignTools.Designers.Actions namespace.
  • Tipos relacionados ao comportamento, como adornos e snaplines, no namespace System.Windows.Forms.Design.Behavior foram movidos para o namespace Microsoft.DotNet.DesignTools.Designers.Behaviors.

Editores de tipos personalizados

Os editores de tipos personalizados são mais complicados do que os designers de controle. Como o processo do Visual Studio é baseado no .NET Framework, qualquer interface do usuário mostrada no contexto do Visual Studio também deve ser baseada no .NET Framework. Esse design apresenta um problema, por exemplo, ao criar um controle .NET que mostra um editor de tipos personalizado invocado clicando no botão … na grade de propriedades. A caixa de diálogo não pode ser mostrada no contexto do Visual Studio.

O designer fora do processo lida com a maioria dos recursos do designer de controle, como adornos, editores de tipos internos e pintura personalizada. Sempre que você precisar mostrar uma caixa de diálogo modal personalizada, como a exibição de um novo editor de tipos, precisará replicar essa comunicação cliente-servidor de objeto proxy que o designer fora do processo oferece. Isso cria muito mais sobrecarga do que o antigo sistema .NET Framework.

Se suas propriedades de controle personalizadas estiverem usando editores de tipo fornecidos pelo Windows Forms, você poderá usar o EditorAttribute para marcar suas propriedades com o editor .NET Framework correspondente que você deseja que o Visual Studio use. Usando os editores integrados, você evita a necessidade de replicar a comunicação cliente-servidor do objeto proxy fornecida pelo designer externo ao processo.

[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

Criar um editor de tipos

Para criar designers personalizados que fornecem editores de tipos, você precisará de uma variedade de projetos, conforme descrito na lista a seguir:

  • Control: Este projeto é sua biblioteca de controle personalizada que contém o código para seus controles. Essa é a biblioteca que um usuário referenciaria quando quisesse usar seus controles.
  • Control.Client: um projeto do Windows Forms para .NET Framework que contém suas caixas de diálogo de interface do usuário do designer personalizado.
  • Control.Server: um projeto do Windows Forms para .NET que contém o código do designer personalizado para seus controles.
  • Control.Protocol: Um projeto .NET Standard que contém as classes de comunicação usadas pelos projetos Control.Client e Control.Server.
  • Control.Package: Um projeto de pacote NuGet que contém todos os outros projetos. Esse pacote é formatado de forma a permitir que as ferramentas do Visual Studio Windows Forms para .NET hospedem e usem sua biblioteca de controle e designers.

Mesmo se seu editor de tipos derivar de um editor existente, como ColorEditor ou FileNameEditor, você ainda terá que criar essa comunicação cliente-servidor de objeto proxy porque forneceu um novo tipo de classe de interface do usuário que quer exibir no contexto do Visual Studio. No entanto, o código para implementar esse editor de tipos no Visual Studio é muito mais simples.

Importante

A documentação que descreve esse cenário em detalhes está em andamento. Até que essa documentação seja publicada, use a seguinte postagem de blog e exemplo para orientá-lo na criação, publicação e uso dessa estrutura de projeto: