O que há de novo no Windows Forms para .NET 9

Artigo
02/09/2025

Este artigo descreve o que há de novo no Windows Forms para .NET 9.

Formulários assíncronos

Importante

Este conjunto de recursos é experimental, exceto para Control.InvokeAsync.

Os aplicativos modernos exigem modelos de comunicação assíncronos. À medida que o Windows Forms cresceu no .NET, mais componentes exigem empacotamento para um método async para serem executados no thread da interface do usuário. Por exemplo, controles como WebView2, APIs nativas do Windows 10 e Windows 11 ou bibliotecas assíncronas modernas como Semantic Kernel. Outro cenário seria aquele em que se está a partilhar MVVM ViewModels construídos em torno de async com Windows Forms de outras plataformas de interface de utilizador, como WPF, WinUI ou .NET MAUI.

Segue-se uma lista de novos métodos adicionados para suportar cenários assíncronos:

System.Windows.Forms.Form.ShowAsync
Form.ShowDialogAsync
TaskDialog.ShowDialogAsync
Control.InvokeAsync (Esta API não é experimental.)

Esta API é protegida por trás de um erro do compilador porque é experimental. Para suprimir o erro e habilitar o acesso à API, adicione o seguinte PropertyGroup ao arquivo de projeto:

<PropertyGroup>
    <NoWarn>$(NoWarn);WFO5002</NoWarn>
</PropertyGroup>

Dica

Para obter mais informações sobre como suprimir essa regra, consulte Compiler Error WFO5002.

BinaryFormatter não é mais suportado

BinaryFormatter é considerado inseguro porque é vulnerável a ataques de desserialização, que podem levar a negação de serviço (DoS), divulgação de informações ou execução remota de código. Ele foi implementado antes que as vulnerabilidades de desserialização fossem bem compreendidas e seu design não segue as práticas recomendadas de segurança modernas.

A partir do .NET 9, sua implementação foi removida para evitar esses riscos de segurança. Quando se usa BinaryFormatter, é lançada a exceção PlatformNotSupportedException.

Os Windows Forms usavam BinaryFormatter em muitos cenários, como ao serializar dados para operações de área de transferência e arrastar e soltar e, mais importante, no Windows Forms Designer. Internamente, o Windows Forms continua a usar um subconjunto mais seguro de BinaryFormatter para lidar com casos de uso específicos com um conjunto conhecido de tipos.

O Windows Forms para .NET 9 é fornecido com analisadores que ajudam a identificar as vezes em que você participa, sem saber, da serialização binária.

Para obter mais informações sobre BinaryFormatter, consulte Guia de migração do Windows Forms para BinaryFormatter.

Modo escuro

Importante

Este conjunto de recursos é experimental.

O suporte preliminar para o modo escuro foi adicionado ao Windows Forms, com o objetivo de finalizar o suporte no .NET 10. Quando o modo de cor muda, os SystemColors são alterados para corresponder. O modo de cor para o aplicativo pode ser definido como um dos seguintes valores:

SystemColorMode.Classic—(padrão) Modo de luz, o mesmo que as versões anteriores do Windows Forms.
SystemColorMode.System—Respeite o modo claro ou escuro definido pelo Windows.
SystemColorMode.Dark—Use o modo escuro.

Para aplicar um modo de cor, chame Application.SetColorMode(SystemColorMode) no código de inicialização do programa:

namespace MyExampleProject;

static class Program
{
    /// <summary>
    ///  The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main()
    {
        // To customize application configuration such as set high DPI settings or default font,
        // see https://aka.ms/applicationconfiguration.
        ApplicationConfiguration.Initialize();
        Application.SetColorMode(SystemColorMode.Dark);
        Application.Run(new Form1());
    }    
}

Friend Module Program

    <STAThread()>
    Friend Sub Main(args As String())
        Application.SetHighDpiMode(HighDpiMode.SystemAware)
        Application.EnableVisualStyles()
        Application.SetCompatibleTextRenderingDefault(False)
        Application.SetColorMode(SystemColorMode.Dark)
        Application.Run(New Form1)
    End Sub

End Module

Esta API é protegida por trás de um erro do compilador porque é experimental. Para suprimir o erro e habilitar o acesso à API, adicione o seguinte PropertyGroup ao arquivo de projeto:

<PropertyGroup>
    <NoWarn>$(NoWarn);WFO5001</NoWarn>
</PropertyGroup>

Dica

Para obter mais informações sobre como suprimir essa regra, consulte Compiler Error WFO5001.

Aprimoramentos do FolderBrowserDialog

FolderBrowserDialog agora suporta a seleção de várias pastas, que são armazenadas na matriz SelectedPaths. Para habilitar várias pastas, defina Multiselect como true.

System.Desenhando novos recursos e aprimoramentos

A biblioteca System.Drawing teve muitas melhorias, incluindo encapsulamento de efeitos GDI+, suporte para ReadOnlySpane melhor geração de código de interoperabilidade.

System.Drawing suporta efeitos GDI+

A biblioteca System.Drawing do agora suporta efeitos de bitmap GDI+, como desfoque e matiz. Os efeitos estiveram sempre presentes no GDI+, mas não foram expostos através do System.Drawing até agora.

Os efeitos são aplicados a um Bitmap através da chamada do método Bitmap.ApplyEffect(Effect, Rectangle). Forneça o efeito e um Rectangle opcional para a área onde aplicar o efeito. Use Rectangle.Empty para processar a imagem inteira.

O namespace System.Drawing.Imaging.Effects contém os efeitos que você pode aplicar:

O System.Drawing dá suporte a Span

Muitos métodos que aceitavam matrizes foram aprimorados para também aceitar ReadOnlySpan. Por exemplo, métodos como GraphicsPath.AddLines(ReadOnlySpan<Point>), Graphics.DrawLines(Pen, ReadOnlySpan<Point>)e DrawPolygon(Pen, ReadOnlySpan<Point>), aceitam uma matriz ou ReadOnlySpan.

Usar CsWin32 para interoperabilidade

Todo o código de interoperabilidade foi substituído por CsWin32, um gerador de código-fonte C# P/Invoke.

Barra de Ferramentas

As melhorias a seguir foram adicionadas aos controles ToolStrip e ToolStripItem.

Uma nova propriedade foi adicionada ao ToolStripe ao AllowClickThrough.

Quando definido como true, o controle pode ser utilizado enquanto o formulário está sem foco.

Quando o .NET Core 3.1 foi lançado, todos os controles relacionados ao Menu, como MainMenu e MenuItem, foram removidos. ToolStrip e ToolStripMenuItem devem ser usados em vez disso. No entanto, ToolStripItem, a classe base para ToolStripMenuItem, não teve um substituto para o evento MenuItem.Select. Esse evento foi gerado quando o mouse ou teclado é usado para realçar o item.

O .NET 9 adicionou ToolStripItem.SelectedChanged, que pode ser usado para detetar quando um item de menu é realçado.

Partilhar via