Compartilhar via

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

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

Observação

Este artigo não é uma lista completa de alterações significativas entre o .NET Framework e o .NET Core. As alterações significativas mais importantes são adicionadas aqui à medida que nos tornamos cientes 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, seu valor padrão é true.

Descrição da alteração

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

As propriedades em System.Diagnostics.ProcessStartInfo funcionam apenas quando ProcessStartInfo.UseShellExecute é true.

Essa alteração foi introduzida no .NET Core por motivos de desempenho. Normalmente, Process.Start é usado para iniciar um aplicativo diretamente. Iniciar um aplicativo diretamente não precisa envolver o shell do Windows e incorrer no custo de desempenho associado. Para tornar esse caso padrão mais rápido, o .NET Core altera o valor padrão de ProcessStartInfo.UseShellExecute para false. Você pode optar pelo caminho mais lento se precisar dele.

Versão introduzida

2.1

Observação

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

Se seu aplicativo depender do comportamento antigo, chame Process.Start(ProcessStartInfo) com UseShellExecute definido para 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 não tem permissão de gravação.

Descrição da alteração

No .NET Framework, um ArgumentException é gerado quando o chamador tenta definir um valor de atributo de arquivo em FileSystemInfo.Attributes, mas não tem permissão de gravação. No .NET Core, um UnauthorizedAccessException é lançado em vez disso. (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 da alteração

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

A partir do .NET Core 1.0, exceções de estado de processo corrompido não podem ser tratadas pelo código gerenciado. O common language runtime não oferece exceções de estado de processo corrompido ao 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 no 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 adiciona mais um caractere inicial # e UriBuilder.Query não adiciona mais um caractere inicial ? quando um já está presente.

Descrição da alteração

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 múltiplos caracteres # ou ? no valor armazenado se a cadeia de caracteres já contiver um desses caracteres iniciais. Por exemplo, o valor de UriBuilder.Fragment pode se tornar ##main.

A partir do .NET Core 1.0, essas propriedades não pré-anexam os caracteres # ou ? ao valor armazenado se já estiverem presentes no início da string.

Versão introduzida

1,0

Você não precisa mais remover explicitamente nenhum desses caracteres principais ao definir os valores da propriedade. Isso é especialmente útil quando você está acrescentando valores, porque você não precisa mais remover o caractere de início # ou ? cada vez que acrescenta.

Por exemplo, o snippet de código a seguir mostra a diferença de comportamento entre o .NET Framework e o .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 lança 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 da alteração

No .NET Framework, acessar a Process.StartInfo propriedade para processos que seu código não iniciou retorna um objeto fictício ProcessStartInfo . O objeto fictício contém valores padrão para todas as suas 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 Process.StartInfo propriedade para processos que seu 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

Parâmetro booliano de SignedCms.ComputeSignature é respeitado

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

Descrição da alteração

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

O suporte para 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 booleano como false. O comportamento resultante é o mesmo que no .NET Framework, independentemente de o contexto silencioso ser desabilitado lá.

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 da alteração

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ão aplicável

Rede

.NET Core 2.0

WebClient.CancelAsync nem sempre cancela imediatamente

A partir do .NET Core 2.0, a chamada WebClient.CancelAsync() não cancela imediatamente a solicitação se a resposta já começou a ser obtida.

Descrição da alteração

Anteriormente, a chamada 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 WebClient API foi preterida em favor de HttpClient.

Versão introduzida

2.0

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

Categoria

Rede

APIs afetadas

Windows Forms

O suporte do 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 significativas listadas aqui poderão afetar seu aplicativo.

.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 da alteração

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 melhor design e suporte foram introduzidos no .NET Framework 2.0. Os controles preteridos foram removidos anteriormente 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 são removidas
Menu de Contexto Menu de Contexto (ContextMenuStrip)
DataGrid DataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MenuPrincipal MenuStrip
Menu ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
MenuItem ToolStripMenuItem
Barra de Ferramentas ToolStrip Aparência da Barra de Ferramentas
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 da alteração

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 editou uma célula e, enquanto ainda DataGridView estava no modo de edição, passou o mouse sobre uma célula que não tinha a ToolTipText propriedade definida, um CellFormatting evento foi gerado para formatar o texto da célula para 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 CellFormatting nã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 qualquer código que dependa do evento CellFormatting enquanto DataGridView estiver no modo de edição.

Categoria

Windows Forms

APIs afetadas

Nenhum

.NET Core 3.0

Fonte de controle padrão alterada para Segoe UI 9 pt

Descrição da alteração

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

Fonte de controle padrão no .NET Framework

A partir do .NET Core 3.0, 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 controles são dimensionados cerca de 27% maiores para considerar o tamanho maior da nova fonte padrão. Por exemplo:

Fonte de controle padrão no .NET Core

Essa alteração foi feita para se alinhar às diretrizes de experiência do usuário (UX) 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 para um único formulário, defina sua fonte padrão como Microsoft Sans Serif 8.25 pt. Por exemplo:

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

Ou você pode alterar a fonte padrão de um aplicativo inteiro de qualquer uma das seguintes maneiras:

  • Definindo a ApplicationDefaultFont propriedade MSBuild como "Microsoft Sans Serif, 8.25pt". Essa é a técnica preferida porque permite que o Visual Studio use as novas configurações no designer.

    <PropertyGroup>
  <ApplicationDefaultFont>Microsoft Sans Serif, 8.25pt</ApplicationDefaultFont>
</PropertyGroup>

  • Chamando Application.SetDefaultFont(Font).

    class Program
{
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.SetHighDpiMode(HighDpiMode.SystemAware);
        Application.SetDefaultFont(new Font(new FontFamily("Microsoft Sans Serif"), 8.25f));
        Application.Run(new Form1());
    }
}

Categoria

  • Windows Forms

APIs afetadas

Nenhum.

Modernização do FolderBrowserDialog

O componente de controle FolderBrowserDialog foi modificado nos aplicativos Windows Forms para .NET Core.

Descrição da alteração

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

O controle de diálogo de navegação de pastas no .NET Framework

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

O FolderBrowserDialogControl no .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 FolderBrowserDialog.AutoUpgradeEnabled propriedade para false antes de mostrar a caixa de diálogo, conforme ilustrado pelo 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

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

Descrição da alteração

Os seguintes tipos são decorados com o SerializableAttribute no .NET Framework, mas o atributo foi removido no .NET Core.

Historicamente, esse mecanismo de serialização tem tido sérias preocupações de manutenção e segurança. Manter SerializableAttribute em tipos significa que esses tipos devem ser testados para alterações de serialização de versão para versão e, potencialmente, de plataforma para plataforma. Isso dificulta a evolução desses tipos e pode ser caro de manter. Esses tipos não têm cenários conhecidos de serialização binária, o que minimiza o impacto da remoção do atributo.

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

Versão introduzida

3.0

Atualize qualquer código que possa depender desses tipos serem marcados 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 da alteração

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

No .NET Core, bem como no .NET 5.0 e versões posteriores, a opção Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls não é suportada.

Versão introduzida

3.0

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

Categoria

Windows Forms

APIs afetadas

  • Nenhum

O switch de compatibilidade DomainUpDown.UseLegacyScrolling não é suportado

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 da alteração

A partir do .NET Framework 4.7.1, a opção de compatibilidade Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling permitiu aos desenvolvedores optar por não usar ações independentes DomainUpDown.DownButton() e DomainUpDown.UpButton(). A opção restaurou o comportamento herdado, no qual o DomainUpDown.UpButton() é ignorado se o texto de contexto está presente e o desenvolvedor é obrigado a usar a ação DomainUpDown.DownButton() no controle antes da ação DomainUpDown.UpButton(). Para obter mais informações, consulte <o elemento AppContextSwitchOverrides>.

No .NET Core, bem como no .NET 5.0 e versões posteriores, a opção Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling não é suportada.

Versão introduzida

3.0

Remova o interruptor. 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 da alteração

No .NET Framework 4.6.2 e nas versões anteriores, o RichTextBox controle cria uma instância do controle Win32 RichEdit v3.0 e, para aplicativos destinados ao .NET Framework 4.7.1, o RichTextBox controle cria uma instância do RichEdit v4.1 (em msftedit.dll). A Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl opção de compatibilidade foi introduzida para permitir que os aplicativos destinados ao .NET Framework 4.7.1 e versões posteriores escolham não usar o novo controle RichEdit v4.1 e utilizem 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 RichTextBox controle.

Versão introduzida

3.0

Remova o interruptor. 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 da alteração

A partir do .NET Framework 4.6.1, a seleção da tecla de atalho Ctrl + A em um TextBox controle selecionou todo o texto. No .NET Framework 4.6 e nas versões anteriores, a seleção da tecla de atalho Ctrl + A não conseguiu selecionar todo o texto se o Textbox.ShortcutsEnabled e TextBox.Multiline as propriedades foram definidas como true. A Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox opção de compatibilidade 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 o interruptor. 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 da alteração

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 obter mais informações, consulte Mitigação: Implementações personalizadas de IMessageFilter.PreFilterMessage.

No .NET Core, bem como no .NET 5.0 e versões posteriores, a opção Switch.System.Windows.Forms.DontSupportReentrantFilterMessage não é suportada.

Versão introduzida

3.0

Remova o interruptor. 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 da alteração

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

No .NET Core, bem como no .NET 5.0 e versões posteriores, a opção Switch.System.Windows.Forms.EnableVisualStyleValidation não é suportada.

Versão introduzida

3.0

Remova o interruptor. 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 da alteração

A partir do .NET Framework 4.7.2, a opção Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue de compatibilidade permite que o desenvolvedor opte por não usar o novo comportamento da ContextMenuStrip.SourceControl propriedade, que agora retorna uma referência ao controle do código-fonte. O comportamento anterior da propriedade retornava null. Para obter mais informações, consulte <o elemento AppContextSwitchOverrides>.

No .NET Core, bem como no .NET 5.0 e versões posteriores, a opção Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue não é suportada.

Versão introduzida

3.0

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

Categoria

Windows Forms

APIs afetadas

Alternador de compatibilidade UseLegacyImages não é suportado

A opção de compatibilidade Switch.System.Windows.Forms.UseLegacyImages, introduzida no .NET Framework 4.8, não é suportada nos Windows Forms em .NET Core ou .NET 5.0 e posterior.

Descrição da alteração

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, consulte as Notas de Lançamento do .NET Framework 4.8 no GitHub.

No .NET Core, bem como no .NET 5.0 e versões posteriores, a opção Switch.System.Windows.Forms.UseLegacyImages não é suportada.

Versão introduzida

3.0

Remova o interruptor. 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 About.vb arquivos e os SplashScreen.vb arquivos gerados pelo Visual Studio contêm referências a tipos no My namespace que não estão disponíveis no .NET Core 3.0 e 3.1.

Versão introduzida

3.0

Descrição da alteração

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

O suporte ao Visual Basic My foi aprimorado no .NET 5, atualize seu projeto para o .NET 5 ou posterior.

- ou -

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

Dica

Este é um código de exemplo 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

Visual Basic Windows Forms

APIs afetadas

Nenhum

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

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

Versão introduzida

.NET Core 3.0

Descrição da alteração

Os tipos no Microsoft.VisualBasic.ApplicationServices namespace estavam disponíveis no .NET Framework. Eles 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 ao .NET 5, atualize seu projeto para o .NET 5 ou posterior.

- ou -

Se o código depender do uso de Microsoft.VisualBasic.ApplicationServices tipos e seus membros, você poderá usar um tipo ou membro correspondente na biblioteca de classes do .NET. Por exemplo, alguns membros de System.Environment e de 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 Microsoft.VisualBasic.Devices namespace não estão disponíveis.

Versão introduzida

.NET Core 3.0

Descrição da alteração

Os tipos no Microsoft.VisualBasic.Devices namespace estavam disponíveis no .NET Framework. Eles 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 ao .NET 5, atualize seu projeto para o .NET 5 ou posterior.

- ou -

Se o código depender do uso de Microsoft.VisualBasic.Devices tipos e seus 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

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

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

Versão introduzida

.NET Core 3.0

Descrição da alteração

Os tipos no Microsoft.VisualBasic.MyServices namespace estavam disponíveis no .NET Framework. Eles 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 ao .NET 5, atualize seu projeto para o .NET 5 ou posterior.

- ou -

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

Tipo Microsoft.VisualBasic.MyServices Tipo de biblioteca de classes do .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

Consulte também

  • Last updated on