O designer muda desde o .NET Framework (Windows Forms .NET)
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 fora do processo
O designer fora do processo é um processo chamado DesignToolsServer.exe e é executado junto com o processo 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, os objetos proxy do .NET Framework são criados para cada componente e controle no designer, que se comunicam 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
eComponentTray
, foram movidos doSystem.Windows.Forms.Design
namespace para oMicrosoft.DotNet.DesignTools.Designers
namespace. - Os tipos relacionados à lista de ações no
System.ComponentModel.Design
namespace foram movidos para oMicrosoft.DotNet.DesignTools.Designers.Actions
namespace. - Tipos relacionados ao comportamento, como adornos e linhas de ajuste, no
System.Windows.Forms.Design.Behavior
namespace foram movidos para oMicrosoft.DotNet.DesignTools.Designers.Behaviors
namespace.
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, quando você está criando um controle .NET que mostra um editor de tipo personalizado invocado …
button clicando no 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 exibir um novo editor de tipos, será necessário replicar a comunicação cliente-servidor de objeto proxy que o designer fora do processo fornece. 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 internos, você evita a necessidade de replicar a comunicação cliente-servidor proxy-objeto fornecida pelo designer fora do 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 as caixas de diálogo da 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 pelosControl.Client
projetos eControl.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 que o editor de tipos derive de um editor existente, como ColorEditor ou FileNameEditor, você ainda precisa criar essa comunicação cliente-servidor de objeto proxy porque forneceu um novo tipo de classe de interface do usuário que deseja 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:
.NET Desktop feedback