Alterações interruptivas para migração do .NET Framework para o .NET Core

  • Artigo

Se você estiver migrando um aplicativo do .NET Framework para as versões 1.0 a 3.1 do .NET Core, as alterações interruptivas listadas neste artigo poderão afetar você. As alterações interruptivas são agrupadas por categoria e, dentro dessas categorias, são agrupadas pela versão do .NET Core em que elas foram introduzidas.

Observação

Este artigo não é uma lista completa das alterações interruptivas entre o .NET Framework e o .NET Core. As alterações interruptivas mais importantes são adicionadas aqui conforme ficamos cientes da existência delas.

Bibliotecas principais do .NET

.NET 8

API IDispatchImplAttribute é removida

.NET Core 2.1

Alteração no valor padrão de UseShellExecute

ProcessStartInfo.UseShellExecute tem um valor padrão de false no .NET Core. No .NET Framework, o valor padrão é true.

Descrição das alterações

Process.Start permite iniciar um aplicativo diretamente, por exemplo, com um código como Process.Start("mspaint.exe"), que inicia o Paint. Ele também permite que você inicie indiretamente um aplicativo associado quando ProcessStartInfo.UseShellExecute está definido como true. No .NET Framework, o valor padrão de ProcessStartInfo.UseShellExecute é true, o que significa que um código como Process.Start("mytextfile.txt") iniciará o Bloco de notas se você associar arquivos .txt com esse editor. Para impedir a inicialização indireta de um aplicativo no .NET Framework, defina ProcessStartInfo.UseShellExecute explicitamente como false. No .NET Core, o valor padrão de ProcessStartInfo.UseShellExecute é false. Isso significa que, por padrão, os aplicativos associados não são iniciados quando você chama Process.Start.

As seguintes propriedades em System.Diagnostics.ProcessStartInfo só são funcionais quandoProcessStartInfo.UseShellExecute é true:

Essa alteração foi introduzida no .NET Core por motivos de desempenho. Normalmente, Process.Start é usado para iniciar um aplicativo diretamente. A inicialização direta um aplicativo não precisa envolver o shell do Windows e gerar um custo de desempenho associado. Para acelerar esse caso padrão, o .NET Core altera o valor padrão de ProcessStartInfo.UseShellExecutepara false. Você poderá aceitar o caminho mais lento se precisar.

Versão introduzida

2.1

Observação

Em versões anteriores do .NET Core, UseShellExecute não era implementado para o Windows.

Se o aplicativo depender do comportamento antigo, chame Process.Start(ProcessStartInfo) com UseShellExecute definido como true no objeto ProcessStartInfo.

Categoria

Bibliotecas principais do .NET

APIs afetadas

.NET Core 1.0

UnauthorizedAccessException gerada por FileSystemInfo.Attributes

No .NET Core, um UnauthorizedAccessException é gerado quando o chamador tenta definir um valor de atributo de arquivo, mas sem permissão de gravação.

Descrição das alterações

No .NET Framework, um ArgumentException é gerado quando o chamador tenta definir um valor de atributo de arquivo em FileSystemInfo.Attributes, mas sem permissão de gravação. Já no .NET Core, um UnauthorizedAccessException é gerado. (No .NET Core, um ArgumentException ainda será gerado se o chamador tentar definir um atributo de arquivo inválido).

Versão introduzida

1,0

Modifique as instruções catch para capturar um UnauthorizedAccessException, em vez de ArgumentException ou além dele, conforme o necessário.

Categoria

Bibliotecas principais do .NET

APIs afetadas

Não há suporte para o tratamento de exceções de estado corrompido

Não há suporte para o tratamento de exceções de estado de processo corrompido no .NET Core.

Descrição das alterações

Anteriormente, as exceções de estado de processo corrompido podiam ser capturadas e tratadas por manipuladores de exceção de código gerenciado, por exemplo, usando uma instrução try-catch em C#.

Do .NET Core 1.0 em diante, as exceções de estado de processo corrompido não podem ser tratadas pelo código gerenciado. O Common Language Runtime não fornece exceções de estado de processo corrompido para código gerenciado.

Versão introduzida

1,0

Evite a necessidade de lidar com exceções de estado de processo corrompido resolvendo as situações que as causam. Se for absolutamente necessário lidar com exceções de estado de processo corrompido, escreva o manipulador de exceção em código C ou C++.

Categoria

Bibliotecas principais do .NET

APIs afetadas

As propriedades do UriBuilder não acrescentam mais caracteres à esquerda

UriBuilder.Fragment não acrescenta mais um caractere # à esquerda e UriBuilder.Query não acrescenta mais um caractere ? à esquerda quando já existe um.

Descrição das alterações

No .NET Framework, as propriedades UriBuilder.Fragment e UriBuilder.Query sempre acrescentam um caractere # ou ?, respectivamente, ao valor que está sendo armazenado. Esse comportamento pode resultar em vários caracteres # ou ? no valor armazenado quando a cadeia de caracteres já contém um desses caracteres à esquerda. Por exemplo, o valor de UriBuilder.Fragment pode se tornar ##main.

Do .NET Core 1.0 em diante, essas propriedades não acrescentam mais os caracteres # ou ? ao valor armazenado quando já existe um no início da cadeia de caracteres.

Versão introduzida

1,0

Você não precisa mais remover explicitamente nenhum desses caracteres à esquerda ao definir os valores da propriedade. Isso é muito útil ao acrescentar valores, porque você não precisa mais remover o # ou ? à esquerda a cada acréscimo.

Por exemplo, o snippet de código a seguir mostra a diferença de comportamento entre o .NET Framework e .NET Core.

var builder = new UriBuilder();
builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);
  • No .NET Framework, a saída é ????one=1&two=2&three=3&four=4.
  • No .NET Core, a saída é ?one=1&two=2&three=3&four=4.

Categoria

Bibliotecas principais do .NET

APIs afetadas

Process.StartInfo gera uma InvalidOperationException para processos que você não iniciou

A leitura da propriedade Process.StartInfo em processos que o código não iniciou gera uma InvalidOperationException.

Descrição das alterações

No .NET Framework, o acesso à propriedade Process.StartInfo em processos que o código não iniciou retorna um objeto fictício ProcessStartInfo. O objeto fictício contém valores padrão para todas as propriedades, exceto EnvironmentVariables.

Do .NET Core 1.0 em diante, se você ler a propriedade Process.StartInfo de um processo que não iniciou (ou seja, chamando Process.Start), será gerada uma InvalidOperationException.

Versão introduzida

1,0

Não acesse a propriedade Process.StartInfo em processos que o código não iniciou. Por exemplo, não leia essa propriedade para processos retornados por Process.GetProcesses.

Categoria

Bibliotecas principais do .NET

APIs afetadas

Criptografia

.NET Core 2.1

O parâmetro booliano de SignedCms.ComputeSignature é respeitado

No .NET Core, o parâmetro booliano silent do método SignedCms.ComputeSignature(CmsSigner, Boolean) é respeitado. Um prompt de PIN não será mostrado se esse parâmetro estiver definido como true.

Descrição das alterações

No .NET Framework, o parâmetro silent do método SignedCms.ComputeSignature(CmsSigner, Boolean) é ignorado e um prompt de PIN sempre é mostrado quando o provedor exige. No .NET Core, o parâmetro silent é respeitado e, se definido como true, um prompt de PIN nunca é mostrado, mesmo que seja exigido pelo provedor.

O suporte a mensagens CMS/PKCS nº 7 foi introduzido no .NET Core na versão 2.1.

Versão introduzida

2.1

Para garantir que um prompt de PIN apareça se necessário, os aplicativos da área de trabalho devem chamar SignedCms.ComputeSignature(CmsSigner, Boolean) e definir o parâmetro booliano como false. O comportamento resultante é o mesmo que no .NET Framework, mesmo que o contexto silencioso esteja desabilitado.

Categoria

Criptografia

APIs afetadas

MSBuild

.NET Core 3.0

Alteração do nome do arquivo de manifesto do recurso

Do .NET Core 3.0 em diante, no caso padrão, o MSBuild gera um nome de arquivo de manifesto diferente para arquivos de recursos.

Versão introduzida

3.0

Descrição das alterações

Antes do .NET Core 3.0, se o metadado LogicalName, ManifestResourceName ou DependentUpon não fosse especificado para um item EmbeddedResource no arquivo de projeto, o MSBuild gerava um nome de arquivo de manifesto no padrão <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Se RootNamespace não estava definido no arquivo de projeto, ele era assumido como o nome do projeto. Por exemplo, o nome do manifesto gerado para um arquivo de recurso chamado Form1.resx no diretório raiz do projeto era MyProject.Form1.resources.

Do .NET Core 3.0 em diante, se um arquivo de recurso estiver no mesmo local que um arquivo de origem com o mesmo nome (por exemplo, Form1.resx e Form1.cs), o MSBuild usará as informações de tipo do arquivo de origem para gerar o nome do arquivo de manifesto no padrão <Namespace>.<ClassName>.resources. O namespace e o nome de classe são extraídos do primeiro tipo no arquivo de origem no mesmo local. Por exemplo, o nome do manifesto gerado para um arquivo de recurso chamado Form1.resx que está no mesmo local que um arquivo de origem chamado Form1.cs é MyNamespace.Form1.resources. É importante observar que a primeira parte do nome do arquivo é diferente das versões anteriores do .NET Core (MyNamespace em vez de MyProject).

Observação

Se o metadado LogicalName, ManifestResourceName ou DependentUpon estiver especificado em um item EmbeddedResource no arquivo de projeto, essa alteração não afetará esse arquivo de recurso.

Essa alteração interruptiva foi introduzida com a adição da propriedade EmbeddedResourceUseDependentUponConvention aos projetos do .NET Core. Por padrão, os arquivos de recursos não são listados explicitamente em um arquivo de projeto do .NET Core, portanto, eles não têm metadados DependentUpon para especificar como nomear o arquivo .resources gerado. Quando EmbeddedResourceUseDependentUponConvention é definido como true, que é o padrão, o MSBuild procura um arquivo de origem no mesmo local e extrai um namespace e um nome de classe desse arquivo. Se você definir EmbeddedResourceUseDependentUponConvention como false, o MSBuild vai gerar o nome do manifesto de acordo com o comportamento anterior, que combina RootNamespace e o caminho do arquivo relativo.

Na maioria dos casos, nenhuma ação é necessária por parte do desenvolvedor e o aplicativo deve continuar funcionando. Mas se essa alteração interromper o aplicativo, você poderá:

  • Alterar o código para esperar o novo nome do manifesto.

  • Recusar a nova convenção de nomenclatura definindo EmbeddedResourceUseDependentUponConvention como false no arquivo de projeto.

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Categoria

MSBuild

APIs afetadas

N/D

Rede

.NET Core 2.0

WebClient.CancelAsync nem sempre cancela imediatamente

A partir do .NET Core 2.0, a chamada a WebClient.CancelAsync() não cancela a solicitação imediatamente se a busca da resposta tiver sido iniciada.

Descrição das alterações

Anteriormente, a chamada a WebClient.CancelAsync() cancelava a solicitação imediatamente. A partir do .NET Core 2.0, a chamada a WebClient.CancelAsync() só cancela a solicitação imediatamente se a busca da resposta tiver sido iniciada. Se a busca da resposta tiver sido iniciada, a solicitação só será cancelada após a leitura de uma resposta completa.

Essa alteração foi implementada porque a API WebClient foi preterida em favor de HttpClient.

Versão introduzida

2,0

Use a classe System.Net.Http.HttpClient em vez de System.Net.WebClient, que foi preterida.

Categoria

Rede

APIs afetadas

Windows Forms

O suporte ao Windows Forms foi adicionado ao .NET Core na versão 3.0. Se você estiver migrando um aplicativo do Windows Forms do .NET Framework para o .NET Core, as alterações interruptivas listadas neste artigo poderão afetar o aplicativo em questão.

.NET Core 3.1

Controles removidos

A partir do .NET Core 3.1, alguns controles do Windows Forms não estão mais disponíveis.

Descrição das alterações

A partir do .NET Core 3.1, vários controles do Windows Forms não estão mais disponíveis. Controles de substituição que têm design e suporte aprimorados foram introduzidos no .NET Framework 2.0. Os controles preteridos já foram removidos das caixas de ferramentas do designer, mas ainda estavam disponíveis para serem usados.

Os seguintes tipos não estão mais disponíveis:

Versão introduzida

3.1

Cada controle removido tem um controle de substituição recomendado. Consulte a tabela a seguir:

Controle removido (API) Substituição recomendada APIs associadas que foram removidas
ContextMenu ContextMenuStrip
DataGrid DataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Menu ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
MenuItem ToolStripMenuItem
ToolBar ToolStrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Categoria

Windows Forms

APIs afetadas

O evento CellFormatting não é gerado quando a dica de ferramenta é mostrada

Um DataGridView agora mostra as dicas de texto e de erro de uma célula quando focalizado por um mouse e quando selecionado por meio do teclado. Se uma dica de ferramenta for mostrada, o evento DataGridView.CellFormatting não será gerado.

Descrição das alterações

Antes do .NET Core 3.1, um DataGridView que tinha a propriedade ShowCellToolTips definida como true mostrava uma dica de ferramenta para o texto e os erros da célula quando ela era focalizada por um mouse. As dicas de ferramenta não eram mostradas quando uma célula era selecionada por meio do teclado (por exemplo, usando a tecla Tab, teclas de atalho ou a navegação com as setas). Se o usuário editava uma célula e, enquanto DataGridView ainda estava no modo de edição, passava sobre uma célula que não tinha a propriedade ToolTipText definida, um evento CellFormatting era gerado para formatar o texto da célula da exibição na célula.

Para atender aos padrões de acessibilidade, começando no .NET Core 3.1, um DataGridView que tem a propriedade ShowCellToolTips definida como true mostra as dicas de ferramentas do texto e os erros de uma célula não apenas quando a célula é focalizada, mas também quando ela é selecionada por meio do teclado. Como consequência dessa alteração, o evento CellFormattingnão é gerado quando células que não têm o conjunto de propriedades ToolTipText são focalizadas enquanto DataGridView está no modo de edição. O evento não é gerado porque o conteúdo da célula focalizada é mostrado como uma dica de ferramenta em vez de ser exibido na célula.

Versão introduzida

3.1

Refatorar códigos que dependem do evento CellFormatting enquanto DataGridView está no modo de edição.

Categoria

Windows Forms

APIs afetadas

Nenhum

.NET Core 3.0

A fonte de controle padrão foi alterada para Segoe UI 9 pt

Descrição das alterações

No .NET Framework, a propriedade Control.DefaultFont foi definida como Microsoft Sans Serif 8 pt. A imagem a seguir mostra uma janela que usa a fonte padrão.

Default control font in .NET Framework

Do .NET Core 3.0 em diante, a fonte padrão é definida como Segoe UI 9 pt (a mesma fonte que SystemFonts.MessageBoxFont). Como resultado dessa alteração, os formulários e os controles ficaram 27% maiores para considerar o tamanho maior da nova fonte padrão. Por exemplo:

Default control font in .NET Core

Essa alteração foi feita para se alinhar às diretrizes de UX (experiência do usuário) do Windows.

Versão introduzida

3.0

Devido à alteração no tamanho dos formulários e controles, verifique se o aplicativo é renderizado corretamente.

Para manter a fonte original, defina a fonte padrão do formulário como Microsoft Sans Serif 8 pt. Por exemplo:

public MyForm()
{
    InitializeComponent();
    Font = new Font(new FontFamily("Microsoft Sans Serif"), 8f);
}

Categoria

  • Windows Forms

APIs afetadas

Nenhum.

Modernização do FolderBrowserDialog

O controle FolderBrowserDialog foi alterado nos aplicativos do Windows Forms do .NET Core.

Descrição das alterações

No .NET Framework, o Windows Forms usa a seguinte caixa de diálogo para o controle FolderBrowserDialog:

The FolderBrowserDialogControl in the .NET Framework

No .NET Core 3.0, o Windows Forms usa um controle mais recente baseado em COM, que foi introduzido no Windows Vista:

The FolderBrowserDialogControl in the .NET Core

Versão introduzida

3.0

A caixa de diálogo será atualizada automaticamente.

Se você quiser manter a caixa de diálogo original, defina a propriedade FolderBrowserDialog.AutoUpgradeEnabled como false antes de mostrar a caixa de diálogo, como demonstra o seguinte fragmento de código:

var dialog = new FolderBrowserDialog();
dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();

Categoria

Windows Forms

APIs afetadas

SerializableAttribute removido de alguns tipos do Windows Forms

SerializableAttribute foi removido de algumas classes do Windows Forms que não têm cenários de serialização binária conhecidos.

Descrição das alterações

Os seguintes tipos recebem o SerializableAttribute no .NET Framework, mas o atributo foi removido no .NET Core:

Historicamente, esse mecanismo de serialização tem apresentado sérias preocupações de manutenção e segurança. A manutenção de SerializableAttribute significa que esses tipos precisam ser testados quanto a alterações de serialização de versão para versão e possíveis alterações de serialização de estrutura para estrutura. Isso dificulta a evolução desses tipos e pode custar caro. Esses tipos não têm cenários de serialização binária conhecidos, o que minimiza o impacto da remoção do atributo.

Para obter mais informações, confira Serialização binária.

Versão introduzida

3.0

Atualize os códigos que possam depender da marcação desses tipos como serializáveis.

Categoria

Windows Forms

APIs afetadas

  • Nenhum

Não há suporte para a opção de compatibilidade AllowUpdateChildControlIndexForTabControls

Há suporte para a opção de compatibilidade Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls no Windows Forms no .NET Framework 4.6 e nas versões posteriores, mas não no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

No .NET Framework 4.6 e nas versões posteriores, a seleção de uma guia reordena a respectiva coleção de controles. A opção de compatibilidade Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls permite que um aplicativo ignore essa reordenação quando esse comportamento não é desejado.

No .NET Core e no .NET 5.0 e posteriores, não há suporte para a opção Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

  • Nenhum

Não há suporte para a opção de compatibilidade DomainUpDown.UseLegacyScrolling

A opção de compatibilidade Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling, que foi introduzida no .NET Framework 4.7.1, não é compatível com o Windows Forms no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

Do .NET Framework 4.7.1 em diante, a opção de compatibilidade Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling permitia que os desenvolvedores recusassem as ações DomainUpDown.DownButton() e DomainUpDown.UpButton() independentes. A opção restaurou o comportamento herdado, no qual o DomainUpDown.UpButton() é ignorado quando o texto do contexto está presente, e o desenvolvedor precisa usar a ação DomainUpDown.DownButton() no controle antes da ação DomainUpDown.UpButton(). Para obter mais informações, confira Elemento <AppContextSwitchOverrides>.

No .NET Core e no .NET 5.0 e posteriores, não há suporte para a opção Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

Não há suporte para a opção de compatibilidade DoNotLoadLatestRichEditControl

A opção de compatibilidade Switch.System.Windows.Forms.UseLegacyImages, que foi introduzida no .NET Framework 4.7.1, não é compatível com o Windows Forms no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

No .NET Framework 4.6.2 e nas versões anteriores, o controle RichTextBox criava uma instância do controle RichEdit do Win32 v3.0 e, para aplicativos direcionados ao .NET Framework 4.7.1, o controle RichTextBox criava uma instância do RichEdit v4.1 (no msftedit.dll). A opção de compatibilidade Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl foi introduzida para permitir que os aplicativos direcionados ao .NET Framework versão 4.7.1 e posteriores recusassem o novo controle RichEdit v4.1 e usassem o antigo controle RichEdit v3.

No .NET Core e no .NET 5.0 e versões posteriores, não há suporte para a opção Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl. Há suporte apenas para novas versões do controle RichTextBox.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

Não há suporte para a opção de compatibilidade DoNotSupportSelectAllShortcutInMultilineTextBox

A opção de compatibilidade Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox, que foi introduzida no .NET Framework 4.6.1, não é compatível com o Windows Forms no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

Do .NET Framework 4.6.1 em diante, a seleção da tecla de atalho Ctrl + A em um controle TextBox passou a selecionar o texto todo. No .NET Framework 4.6 e nas versões anteriores, a seleção da tecla de atalho Ctrl + A não conseguia selecionar o texto todo quando as propriedades Textbox.ShortcutsEnabled e TextBox.Multiline estavam definidas como true. A opção de compatibilidade Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox foi introduzida no .NET Framework 4.6.1 para manter o comportamento original. Para obter mais informações, consulte TextBox.ProcessCmdKey.

No .NET Core e no .NET 5.0 e versões posteriores, não há suporte para a opção Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

  • Nenhum

Não há suporte para a opção de compatibilidade DontSupportReentrantFilterMessage

A opção de compatibilidade Switch.System.Windows.Forms.DontSupportReentrantFilterMessage, que foi introduzida no .NET Framework 4.6.1, não é compatível com o Windows Forms no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

Do .NET Framework 4.6.1 em diante, a opção de compatibilidade Switch.System.Windows.Forms.DontSupportReentrantFilterMessage trata possíveis exceções de IndexOutOfRangeException quando a mensagem Application.FilterMessage é chamada com uma implementação personalizada de IMessageFilter.PreFilterMessage. Para saber mais, confira Mitigation: Custom IMessageFilter.PreFilterMessage Implementations (Mitigação: implementações personalizadas de IMessageFilter.PreFilterMessage).

No .NET Core e no .NET 5.0 e posteriores, não há suporte para a opção Switch.System.Windows.Forms.DontSupportReentrantFilterMessage.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

Não há suporte para a opção de compatibilidade EnableVisualStyleValidation

Não há suporte para a opção de compatibilidade Switch.System.Windows.Forms.EnableVisualStyleValidation no Windows Forms no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

No .NET Framework, a opção de compatibilidade Switch.System.Windows.Forms.EnableVisualStyleValidation permitia que um aplicativo recusasse a validação dos estilos visuais fornecidos em um formulário numérico.

No .NET Core e no .NET 5.0 e posteriores, não há suporte para a opção Switch.System.Windows.Forms.EnableVisualStyleValidation.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

  • Nenhum

Não há suporte para a opção de compatibilidade UseLegacyContextMenuStripSourceControlValue

A opção de compatibilidade Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue, que foi introduzida no .NET Framework 4.7.2, não é compatível com o Windows Forms no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

Do .NET Framework 4.7.2 em diante, a opção de compatibilidade Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue permite que o desenvolvedor recuse o novo comportamento da propriedade ContextMenuStrip.SourceControl, que agora retorna uma referência ao controle do código-fonte. O comportamento anterior da propriedade retornava null. Para obter mais informações, confira Elemento <AppContextSwitchOverrides>.

No .NET Core e no .NET 5.0 e posteriores, não há suporte para a opção Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

Não há suporte para a opção de compatibilidade UseLegacyImages

A opção de compatibilidade Switch.System.Windows.Forms.UseLegacyImages, que foi introduzida no .NET Framework 4.8, não é compatível com o Windows Forms no .NET Core nem no .NET 5.0 e posteriores.

Descrição das alterações

Do .NET Framework 4.8, a opção de compatibilidade Switch.System.Windows.Forms.UseLegacyImages resolvia possíveis problemas de dimensionamento de imagem em cenários ClickOnce em ambientes de DPI alta. Quando definida como true, a opção permite que o usuário restaure o dimensionamento de imagem herdado em exibições de DPI alta cuja escala é definida como maior que 100%. Para obter mais informações, confira Notas sobre a versão do .NET Framework 4.8 no GitHub.

No .NET Core e no .NET 5.0 e posteriores, não há suporte para a opção Switch.System.Windows.Forms.UseLegacyImages.

Versão introduzida

3.0

Remova a opção. Não há suporte para a opção e nenhuma funcionalidade alternativa está disponível.

Categoria

Windows Forms

APIs afetadas

  • Nenhum

Os modelos About e SplashScreen são interrompidos

Os arquivos About.vb e SplashScreen.vb gerados pelo Visual Studio contêm referências a tipos no namespace My que não estão disponíveis no .NET Core 3.0 e 3.1.

Versão introduzida

3.0

Descrição das alterações

O .NET Core 3.0 e o 3.1 não têm suporte completo ao Visual Basic My. Os modelos de formulário About e SplashScreen nos aplicativos Visual Studio para Windows Forms do Visual Basic fazem referência a propriedades no tipo My.Application.Info que não estão disponíveis.

O suporte do Visual Basic My foi aprimorado no .NET 5. Atualize seu projeto para o .NET 5 ou versões posteriores.

-ou-

Corrija os erros do compilador nos tipos About e SplashScreen em seu aplicativo. Use a classe System.Reflection.Assembly para obter as informações fornecidas pelo tipo My.Application.Info. Uma porta reta de ambos os formulários está disponível aqui.

Dica

Este é um exemplo de código e não otimizado. A lista de atributos deve ser armazenada em cache para reduzir o tempo de carregamento do formulário.

Sobre

Imports System.Reflection

Public NotInheritable Class About

    Private Sub about_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ' Set the title of the form.
        Dim applicationTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(applicationTitle) Then
            applicationTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        Me.Text = String.Format("About {0}", applicationTitle)
        ' Initialize all of the text displayed on the About Box.
        ' TODO: Customize the application's assembly information in the "Application" pane of the project
        '    properties dialog (under the "Project" menu).
        Me.LabelProductName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyProductAttribute)()?.Product, "")
        Me.LabelVersion.Text = String.Format("Version {0}", Assembly.GetExecutingAssembly().GetName().Version)
        Me.LabelCopyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
        Me.LabelCompanyName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCompanyAttribute)()?.Company, "")
        Me.TextBoxDescription.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyDescriptionAttribute)()?.Description, "")
    End Sub

    Private Sub OKButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles OKButton.Click
        Me.Close()
    End Sub

End Class

SplashScreen

Imports System.Reflection

Public NotInheritable Class SplashScreen

    Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        'Set up the dialog text at runtime according to the application's assembly information.  

        'TODO: Customize the application's assembly information in the "Application" pane of the project
        '  properties dialog (under the "Project" menu).

        'Application title
        Dim appTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(appTitle) Then
            appTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        ApplicationTitle.Text = appTitle

        Dim versionValue = Assembly.GetExecutingAssembly().GetName().Version

        'Format the version information using the text set into the Version control at design time as the
        '  formatting string.  This allows for effective localization if desired.
        '  Build and revision information could be included by using the following code and changing the
        '  Version control's designtime text to "Version {0}.{1:00}.{2}.{3}" or something similar.  See
        '  String.Format() in Help for more information.
        '
        '    Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor, versionValue.Build, versionValue.Revision)

        Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor)

        'Copyright info
        Copyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
    End Sub

End Class

Categoria

Windows Forms do Visual Basic

APIs afetadas

Nenhum

Tipos no namespace Microsoft.VisualBasic.ApplicationServices não disponíveis

Os tipos no namespace Microsoft.VisualBasic.ApplicationServices não estão disponíveis.

Versão introduzida

.NET Core 3.0

Descrição das alterações

Os tipos no namespace Microsoft.VisualBasic.ApplicationServices estavam disponíveis no .NET Framework. Não estão disponíveis no .NET Core 3.0 – 3.1.

Os tipos foram removidos para evitar dependências de assembly desnecessárias ou alterações interruptivas nas versões subsequentes.

Esse namespace foi adicionado no .NET 5, atualize seu projeto para o .NET 5 ou versões posteriores.

-ou-

Se o código depender do uso dos tipos Microsoft.VisualBasic.ApplicationServices e respectivos membros, você poderá usar um tipo ou membro correspondente na biblioteca de classes do .NET. Por exemplo, alguns membros System.Environment e System.Security.Principal.WindowsIdentity fornecem funcionalidade equivalente às propriedades da classe Microsoft.VisualBasic.ApplicationServices.User.

Categoria

Visual Basic

APIs afetadas

Tipos no namespace Microsoft.VisualBasic.Devices não disponíveis

Os tipos no namespace Microsoft.VisualBasic.Devices não estão disponíveis.

Versão introduzida

.NET Core 3.0

Descrição das alterações

Os tipos no namespace Microsoft.VisualBasic.Devices estavam disponíveis no .NET Framework. Não estão disponíveis no .NET Core 3.0 – 3.1.

Os tipos foram removidos para evitar dependências de assembly desnecessárias ou alterações interruptivas nas versões subsequentes.

Esse namespace foi adicionado no .NET 5, atualize seu projeto para o .NET 5 ou versões posteriores.

-ou-

Se o código depender do uso dos tipos Microsoft.VisualBasic.Devices e respectivos membros, você poderá usar um tipo ou membro correspondente na biblioteca de classes do .NET. Por exemplo, a funcionalidade equivalente à classe Microsoft.VisualBasic.Devices.Clock é fornecida pelos tipos System.DateTime e System.Environment, e a funcionalidade equivalente à classe Microsoft.VisualBasic.Devices.Ports é fornecida por tipos no namespace System.IO.Ports.

Categoria

Visual Basic

APIs afetadas

Tipos no namespace Microsoft.VisualBasic.MyServices não disponíveis

Os tipos no namespace Microsoft.VisualBasic.MyServices não estão disponíveis.

Versão introduzida

.NET Core 3.0

Descrição das alterações

Os tipos no namespace Microsoft.VisualBasic.MyServices estavam disponíveis no .NET Framework. Não estão disponíveis no .NET Core 3.0 – 3.1.

Os tipos foram removidos para evitar dependências de assembly desnecessárias ou alterações interruptivas nas versões subsequentes.

Esse namespace foi adicionado no .NET 5, atualize seu projeto para o .NET 5 ou versões posteriores.

-ou-

Se o código depender do uso dos tipos Microsoft.VisualBasic.MyServices e respectivos membros, haverá tipos e membros correspondentes na biblioteca de classes do .NET. Veja a seguir um mapeamento dos tipos Microsoft.VisualBasic.MyServices para seus tipos equivalentes de biblioteca de classes do .NET:

Tipo Microsoft.VisualBasic.MyServices Tipo de biblioteca de classes .NET
ClipboardProxy System.Windows.Clipboard para aplicativos WPF, System.Windows.Forms.Clipboard para aplicativos do Windows Forms
FileSystemProxy Tipos no namespace System.IO
RegistryProxy Tipos relacionados ao registro no namespace Microsoft.Win32
SpecialDirectoriesProxy Environment.GetFolderPath

Categoria

Visual Basic

APIs afetadas

Confira também