Partilhar via

Principais bibliotecas .NET que quebram alterações no .NET Core 1.0-3.0

  • Artigo

As principais bibliotecas .NET fornecem as primitivas e outros tipos gerais usados pelo .NET Core.

As seguintes alterações estão documentadas nesta página:

Quebrando a mudança Versão introduzida
Passar GroupCollection para métodos de extensão tomando IEnumerable<T> requer desambiguação .NET Core 3.0
APIs que relatam a versão agora relatam o produto e não a versão do arquivo .NET Core 3.0
As instâncias personalizadas de EncoderFallbackBuffer não podem retornar recursivamente .NET Core 3.0
Alterações de comportamento de formatação e análise de ponto flutuante .NET Core 3.0
As operações de análise de ponto flutuante não falham mais nem geram uma OverflowException .NET Core 3.0
InvalidAsynchronousStateException movido para outro assembly .NET Core 3.0
A substituição de sequências de bytes UTF-8 mal formadas segue as diretrizes do Unicode .NET Core 3.0
TypeDescriptionProviderAttribute movido para outro assembly .NET Core 3.0
ZipArchiveEntry não lida mais com arquivos com tamanhos de entrada inconsistentes .NET Core 3.0
FieldInfo.SetValue lança exceção para campos estáticos somente de inicialização .NET Core 3.0
As APIs de caminho não lançam uma exceção para caracteres inválidos .NET Core 2.1
Campos privados adicionados a tipos de estrutura incorporados .NET Core 2.1
Alteração no valor padrão de UseShellExecute .NET Core 2.1
Versões OpenSSL no macOS .NET Core 2.1
UnauthorizedAccessException lançado por FileSystemInfo.Attributes .NET Core 1.0
Não há suporte para a manipulação de exceções de estado de processo corrompido .NET Core 1.0
As propriedades do UriBuilder não precedem mais os caracteres à esquerda .NET Core 1.0
Process.StartInfo lança InvalidOperationException para processos que você não iniciou .NET Core 1.0

.NET Core 3.0

Passar GroupCollection para métodos de extensão tomando IEnumerable<T> requer desambiguação

Ao chamar um método de extensão que assume um IEnumerable<T>GroupCollection, você deve desambiguar o tipo usando um cast.

Alterar a descrição

A partir do .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementa além dos IEnumerable<KeyValuePair<String,Group>> outros tipos que implementa, incluindo IEnumerable<Group>. Isso resulta em ambiguidade ao chamar um método de extensão que usa um IEnumerable<T>arquivo . Se você chamar esse método de extensão em uma GroupCollection instância, por exemplo, Enumerable.Countverá o seguinte erro do compilador:

CS1061: 'GroupCollection' não contém uma definição para 'Count' e nenhum método de extensão acessível 'Count' aceitando um primeiro argumento do tipo 'GroupCollection' pode ser encontrado (você está faltando uma diretiva de uso ou uma referência de assembly?)

Em versões anteriores do .NET, não havia ambiguidade nem erro de compilador.

Versão introduzida

3.0

Razão para a alteração

Esta foi uma mudança de rutura não intencional. Como já é assim há algum tempo, não pretendemos revertê-lo. Além disso, essa mudança seria, por si só, uma rutura.

Por GroupCollection exemplo, desambiguar chamadas para métodos de extensão que aceitam um IEnumerable<T> com um elenco.

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

Categoria

Principais bibliotecas .NET

APIs afetadas

Qualquer método de extensão que aceite um IEnumerable<T> é afetado. Por exemplo:

APIs que relatam a versão agora relatam o produto e não a versão do arquivo

Muitas das APIs que retornam versões no .NET Core agora retornam a versão do produto em vez da versão do arquivo.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, métodos como Environment.Version, RuntimeInformation.FrameworkDescriptione a caixa de diálogo de propriedades de arquivo para assemblies do .NET Core refletem a versão do arquivo. A partir do .NET Core 3.0, eles refletem a versão do produto.

A figura a seguir ilustra a diferença nas informações de versão para o assembly System.Runtime.dll para .NET Core 2.2 (à esquerda) e .NET Core 3.0 (à direita), conforme exibido pela caixa de diálogo de propriedades do arquivo do Windows Explorer .

Difference in product version information

Versão introduzida

3.0

Nenhum. Essa alteração deve tornar a deteção de versão intuitiva em vez de obtusa.

Categoria

Principais bibliotecas .NET

APIs afetadas

As instâncias personalizadas de EncoderFallbackBuffer não podem retornar recursivamente

As instâncias personalizadas EncoderFallbackBuffer não podem retornar recursivamente. A implementação de deve resultar em uma sequência de caracteres que é conversível para a codificação de EncoderFallbackBuffer.GetNextChar() destino. Caso contrário, ocorrerá uma exceção.

Alterar a descrição

Durante uma operação de transcodificação caractere para byte, o tempo de execução deteta sequências UTF-16 mal formadas ou não conversíveis e fornece esses caracteres para o EncoderFallbackBuffer.Fallback método. O Fallback método determina quais caracteres devem ser substituídos pelos dados não conversíveis originais, e esses caracteres são drenados chamando EncoderFallbackBuffer.GetNextChar um loop.

Em seguida, o tempo de execução tenta transcodificar esses caracteres de substituição para a codificação de destino. Se essa operação for bem-sucedida, o tempo de execução continuará a transcodificação de onde parou na cadeia de caracteres de entrada original.

Anteriormente, implementações personalizadas de podem retornar sequências de caracteres que não são conversíveis para a codificação de EncoderFallbackBuffer.GetNextChar() destino. Se os caracteres substituídos não puderem ser transcodificados para a codificação de destino, o tempo de execução invocará o EncoderFallbackBuffer.Fallback método mais uma vez com os caracteres de substituição, esperando que o EncoderFallbackBuffer.GetNextChar() método retorne uma nova sequência de substituição. Esse processo continua até que o tempo de execução eventualmente veja uma substituição conversível bem formada, ou até que uma contagem máxima de recursão seja atingida.

A partir do .NET Core 3.0, implementações personalizadas de devem retornar sequências de caracteres que são conversíveis para a codificação de EncoderFallbackBuffer.GetNextChar() destino. Se os caracteres substituídos não puderem ser transcodificados para a codificação de destino, um ArgumentException será lançado. O tempo de execução não fará mais chamadas recursivas na EncoderFallbackBuffer instância.

Esse comportamento só se aplica quando todas as três das seguintes condições são atendidas:

  • O tempo de execução deteta uma sequência UTF-16 mal formada ou uma sequência UTF-16 que não pode ser convertida para a codificação de destino.
  • Um costume EncoderFallback foi especificado.
  • O costume EncoderFallback tenta substituir uma nova sequência UTF-16 mal formada ou não conversível.

Versão introduzida

3.0

A maioria dos desenvolvedores não precisa tomar nenhuma ação.

Se um aplicativo usa uma classe e EncoderFallbackBuffer personalizadaEncoderFallback, certifique-se de que a implementação de preenche o buffer de fallback com dados UTF-16 bem formados que são diretamente convertíveis para a codificação de destino quando o Fallback método é invocado EncoderFallbackBuffer.Fallback pela primeira vez pelo tempo de execução.

Categoria

Principais bibliotecas .NET

APIs afetadas

Formatação de ponto flutuante e comportamento de análise alterados

O comportamento de análise e formatação de ponto flutuante (pelos DoubleSingle e tipos) agora é compatível com IEEE. Isso garante que o comportamento dos tipos de ponto flutuante no .NET corresponda ao de outras linguagens compatíveis com IEEE. Por exemplo, double.Parse("SomeLiteral") deve sempre corresponder ao que o C# produz para double x = SomeLiteral.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, a formatação com e Single.ToStringe a análise com , Double.TryParse, Single.Parsee Single.TryParse não são compatíveis com Double.ToStringDouble.ParseIEEE. Como resultado, é impossível garantir que um valor será de ida e volta com qualquer cadeia de caracteres de formato padrão ou personalizado suportado. Para algumas entradas, a tentativa de analisar um valor formatado pode falhar e, para outras, o valor analisado não é igual ao valor original.

A partir do .NET Core 3.0, as operações de análise e formatação de ponto flutuante são compatíveis com IEEE 754.

A tabela a seguir mostra dois trechos de código e como a saída muda entre o .NET Core 2.2 e o .NET Core 3.1.

Trechos de código Saída no .NET Core 2.2 Saída no .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Para obter mais informações, consulte a postagem do blog Análise de ponto flutuante e melhorias de formatação no .NET Core 3.0 .

Versão introduzida

3.0

A seção Impacto potencial no código existente da postagem do blog Análise de ponto flutuante e formatação no .NET Core 3.0 sugere algumas alterações que você pode fazer no seu código se quiser manter o comportamento anterior.

  • Para algumas diferenças na formatação, você pode obter um comportamento equivalente ao comportamento anterior especificando uma cadeia de caracteres de formato diferente.
  • Para diferenças na análise, não há nenhum mecanismo para voltar ao comportamento anterior.

Categoria

Principais bibliotecas .NET

APIs afetadas

As operações de análise de ponto flutuante não falham mais nem geram uma OverflowException

Os métodos de análise de ponto flutuante não lançam mais um OverflowException ou retornam false quando analisam uma cadeia de caracteres cujo valor numérico está fora do intervalo do SingleDouble tipo ou ponto flutuante.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, os Double.Parse métodos e Single.Parse lançam um OverflowException para valores que estão fora do intervalo de seu respetivo tipo. Os Double.TryParse métodos e Single.TryParse retornam false para as representações de cadeia de caracteres de valores numéricos fora do intervalo.

A partir do .NET Core 3.0, os Double.Parsemétodos , Single.ParseDouble.TryParse, e não Single.TryParse falham mais ao analisar cadeias de caracteres numéricas fora do intervalo. Em vez disso, os Double métodos de análise retornam Double.PositiveInfinity para valores que excedem Double.MaxValue, e retornam Double.NegativeInfinity para valores que são menores que Double.MinValue. Da mesma forma, os Single métodos de análise retornam Single.PositiveInfinity para valores que excedem Single.MaxValue, e retornam Single.NegativeInfinity para valores que são menores que Single.MinValue.

Esta alteração foi feita para melhorar a conformidade com o IEEE 754:2008.

Versão introduzida

3.0

Essa alteração pode afetar seu código de duas maneiras:

  • Seu código depende do manipulador para ser OverflowException executado quando ocorre um estouro. Nesse caso, você deve remover a catch instrução e colocar qualquer código necessário em uma instrução que testa If se Double.IsInfinity ou Single.IsInfinity é true.

  • Seu código pressupõe que os valores de ponto flutuante não Infinitysão . Nesse caso, você deve adicionar o código necessário para verificar os valores de vírgula flutuante de PositiveInfinity e NegativeInfinity.

Categoria

Principais bibliotecas .NET

APIs afetadas

InvalidAsynchronousStateException movido para outro assembly

A InvalidAsynchronousStateException classe foi transferida.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, a InvalidAsynchronousStateException classe é encontrada no assembly System.ComponentModel.TypeConverter .

A partir do .NET Core 3.0, ele é encontrado no assembly System.ComponentModel.Primitives .

Versão introduzida

3.0

Essa alteração afeta apenas os aplicativos que usam reflexão para carregar o InvalidAsynchronousStateException chamando um método como Assembly.GetType ou uma sobrecarga de Activator.CreateInstance que pressupõe que o tipo está em um assembly específico. Se esse for o caso, atualize o assembly referenciado na chamada de método para refletir o novo local de assembly do tipo.

Categoria

Principais bibliotecas .NET

APIs afetadas

Nenhum.

A substituição de sequências de bytes UTF-8 mal formadas segue as diretrizes do Unicode

Quando a UTF8Encoding classe encontra uma sequência de bytes UTF-8 mal formada durante uma operação de transcodificação byte-para-caracteres, ela substitui essa sequência por um caractere ' ' (U+FFFD REPLACEMENT CHARACTER) na cadeia de caracteres de saída. O .NET Core 3.0 difere das versões anteriores do .NET Core e do .NET Framework seguindo a prática recomendada do Unicode para executar essa substituição durante a operação de transcodificação.

Isso faz parte de um esforço maior para melhorar a manipulação de UTF-8 em todo o .NET, inclusive pelos novos System.Text.Unicode.Utf8 e System.Text.Rune tipos. O UTF8Encoding tipo recebeu uma mecânica melhorada de tratamento de erros para que produza resultados consistentes com os tipos recém-introduzidos.

Alterar a descrição

A partir do .NET Core 3.0, ao transcodificar bytes em caracteres, a classe executa a UTF8Encoding substituição de caracteres com base nas práticas recomendadas do Unicode. O mecanismo de substituição utilizado é descrito pelo The Unicode Standard, Versão 12.0, Sec. 3.9 (PDF) no título intitulado U+FFFD Substitution of Maximal Subparts.

Esse comportamento só se aplica quando a sequência de bytes de entrada contém dados UTF-8 mal formados. Além disso, se a UTF8Encoding instância tiver sido construída com throwOnInvalidBytes: true, a UTF8Encoding instância continuará a lançar entradas inválidas em vez de executar a substituição U+FFFD. Para obter mais informações sobre o UTF8Encoding construtor, consulte UTF8Encoding(Boolean, Boolean).

A tabela a seguir ilustra o impacto dessa alteração com uma entrada inválida de 3 bytes:

Entrada de 3 bytes mal formada Saída antes do .NET Core 3.0 Saída começando com .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (saída de 2 caracteres) [ FFFD FFFD FFFD ] (saída de 3 caracteres)

A saída de 3 caracteres é a saída preferida, de acordo com a Tabela 3-9 do PDF padrão Unicode vinculado anteriormente.

Versão introduzida

3.0

Nenhuma ação é necessária por parte do desenvolvedor.

Categoria

Principais bibliotecas .NET

APIs afetadas

TypeDescriptionProviderAttribute movido para outro assembly

A TypeDescriptionProviderAttribute classe foi transferida.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, a TypeDescriptionProviderAttribute classe é encontrada no assembly System.ComponentModel.TypeConverter .

A partir do .NET Core 3.0, ele é encontrado no assembly System.ObjectModel .

Versão introduzida

3.0

Essa alteração afeta apenas os aplicativos que usam reflexão para carregar o TypeDescriptionProviderAttribute tipo chamando um método como Assembly.GetType ou uma sobrecarga de Activator.CreateInstance que pressupõe que o tipo está em um assembly específico. Se esse for o caso, o assembly referenciado na chamada de método deve ser atualizado para refletir o novo local de assembly do tipo.

Categoria

Windows Forms

APIs afetadas

Nenhum.

ZipArchiveEntry não lida mais com arquivos com tamanhos de entrada inconsistentes

Os arquivos zip listam o tamanho compactado e o tamanho não compactado no diretório central e no cabeçalho local. Os próprios dados de entrada também indicam o seu tamanho. No .NET Core 2.2 e versões anteriores, esses valores nunca foram verificados quanto à consistência. Começando com o .NET Core 3.0, eles agora são.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, ZipArchiveEntry.Open() é bem-sucedido mesmo se o cabeçalho local discordar do cabeçalho central do arquivo zip. Os dados são descompactados até que o final do fluxo compactado seja atingido, mesmo que seu comprimento exceda o tamanho do arquivo não compactado listado no diretório central/cabeçalho local.

A partir do .NET Core 3.0, o método verifica se o cabeçalho local e o cabeçalho central concordam com os ZipArchiveEntry.Open() tamanhos compactados e não compactados de uma entrada. Se isso não acontecer, o método lançará um InvalidDataException cabeçalho local do arquivo e/ou tamanhos de lista de descritores de dados que discordam do diretório central do arquivo zip. Ao ler uma entrada, os dados descompactados são truncados para o tamanho de arquivo não compactado listado no cabeçalho.

Essa alteração foi feita para garantir que um ZipArchiveEntry representa corretamente o tamanho de seus dados e que apenas essa quantidade de dados é lida.

Versão introduzida

3.0

Reempacote qualquer arquivo zip que exiba esses problemas.

Categoria

Principais bibliotecas .NET

APIs afetadas

FieldInfo.SetValue lança exceção para campos estáticos somente de inicialização

A partir do .NET Core 3.0, uma exceção é lançada quando você tenta definir um valor em um campo estático InitOnly chamando System.Reflection.FieldInfo.SetValue.

Alterar a descrição

No .NET Framework e em versões do .NET Core anteriores à 3.0, você pode definir o valor de um campo estático que é constante depois que ele é inicializado (somente leitura em C#) chamando System.Reflection.FieldInfo.SetValue. No entanto, definir esse campo dessa maneira resultou em um comportamento imprevisível com base na estrutura de destino e nas configurações de otimização.

No .NET Core 3.0 e versões posteriores, quando você chama SetValue um campo estático, InitOnly uma System.FieldAccessException exceção é lançada.

Gorjeta

Um InitOnly campo é aquele que só pode ser definido no momento em que é declarado ou no construtor para a classe que contém. Em outras palavras, é constante depois de inicializado.

Versão introduzida

3.0

Inicialize campos estáticos InitOnly em um construtor estático. Isto aplica-se a tipos dinâmicos e não dinâmicos.

Como alternativa, você pode remover o FieldAttributes.InitOnly atributo do campo e, em seguida, chamar FieldInfo.SetValue.

Categoria

Principais bibliotecas .NET

APIs afetadas

.NET Core 2.1

As APIs de caminho não lançam uma exceção para caracteres inválidos

As APIs que envolvem caminhos de arquivo não validam mais caracteres de caminho ou lançam um ArgumentException se um caractere inválido for encontrado.

Alterar a descrição

No .NET Framework e no .NET Core 1.0 - 2.0, os métodos listados na seção APIs afetadas lançam um ArgumentException argumento se o caminho contiver um caractere de caminho inválido. A partir do .NET Core 2.1, esses métodos não verificam mais se há caracteres de caminho inválidos ou lançam uma exceção se um caractere inválido for encontrado.

Razão para a alteração

A validação agressiva de caracteres de caminho bloqueia alguns cenários entre plataformas. Essa alteração foi introduzida para que o .NET não tente replicar ou prever o resultado de chamadas de API do sistema operacional. Para obter mais informações, consulte o System.IO na postagem do blog de espiada do .NET Core 2.1.

Versão introduzida

.NET Core 2.1

Se o seu código dependia dessas APIs para verificar se havia caracteres inválidos, você pode adicionar uma chamada ao Path.GetInvalidPathChars.

APIs afetadas

Consulte também

Campos privados adicionados a tipos de estrutura incorporados

Campos privados foram adicionados a certos tipos de struct em assemblies de referência. Como resultado, em C#, esses tipos struct sempre devem ser instanciados usando o novo operador ou literal padrão.

Alterar a descrição

No .NET Core 2.0 e versões anteriores, alguns tipos de struct fornecidos, por exemplo, ConsoleKeyInfo, podiam ser instanciados sem usar o new operador ou literal padrão em C#. Isso ocorreu porque os assemblies de referência usados pelo compilador C# não continham os campos privados para as structs. Todos os campos privados para tipos struct do .NET são adicionados aos assemblies de referência a partir do .NET Core 2.1.

Por exemplo, o seguinte código C# compila no .NET Core 2.0, mas não no .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

if (key.ToString() == "y")
{
    Console.WriteLine("Yes!");
}

No .NET Core 2.1, o código anterior resulta no seguinte erro de compilador: CS0165 - Uso da variável local não atribuída 'chave'

Versão introduzida

2.1

Instancie tipos struct usando o operador ou literal newpadrão.

Por exemplo:

ConsoleKeyInfo key = new ConsoleKeyInfo();    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

ConsoleKeyInfo key = default;    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

Categoria

Principais bibliotecas .NET

APIs afetadas

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.

Alterar a descrição

Process.Start permite iniciar um aplicativo diretamente, por exemplo, com um código como Process.Start("mspaint.exe") o que inicia o Paint. Ele também permite que você inicie indiretamente 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 um código como Process.Start("mytextfile.txt") o iniciaria o Bloco de Notas, se você tiver associado .txt arquivos a esse editor. Para evitar iniciar indiretamente um aplicativo no .NET Framework, você deve definir ProcessStartInfo.UseShellExecute explicitamente como false. No .NET Core, o valor padrão para ProcessStartInfo.UseShellExecute é false. Isso significa que, por padrão, os aplicativos associados não são iniciados quando você chama Process.Starto .

As seguintes propriedades em System.Diagnostics.ProcessStartInfo só são funcionais 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.

Versão introduzida

2.1

Nota

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

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

Categoria

Principais bibliotecas .NET

APIs afetadas

Versões OpenSSL no macOS

Os tempos de execução do .NET Core 3.0 e posteriores no macOS agora preferem as versões do OpenSSL 1.1.x às versões do OpenSSL 1.0.x para os AesCcmtipos , AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSslRSAOpenSsl, , e SafeEvpPKeyHandle .

O tempo de execução do .NET Core 2.1 agora suporta versões do OpenSSL 1.1.x, mas ainda prefere as versões do OpenSSL 1.0.x.

Alterar a descrição

Anteriormente, o tempo de execução do .NET Core usava versões do OpenSSL 1.0.x no macOS para tipos que interagem com o OpenSSL. A versão mais recente do OpenSSL 1.0.x, OpenSSL 1.0.2, está agora fora de suporte. Para manter os tipos que usam OpenSSL em versões suportadas do OpenSSL, os tempos de execução do .NET Core 3.0 e posteriores agora usam versões mais recentes do OpenSSL no macOS.

Com essa alteração, o comportamento para os tempos de execução do .NET Core no macOS é o seguinte:

  • Os tempos de execução do .NET Core 3.0 e versões posteriores usam o OpenSSL 1.1.x, se disponível, e voltam para o OpenSSL 1.0.x somente se não houver nenhuma versão 1.1.x disponível.

    Para chamadores que usam os tipos de interoperabilidade OpenSSL com P/Invokes personalizados, siga as SafeEvpPKeyHandle.OpenSslVersion orientações nas observações. Seu aplicativo pode falhar se você não verificar o OpenSslVersion valor.

  • O tempo de execução do .NET Core 2.1 usa o OpenSSL 1.0.x, se disponível, e retorna ao OpenSSL 1.1.x se não houver nenhuma versão 1.0.x disponível.

    O tempo de execução 2.1 prefere a versão anterior do OpenSSL porque a SafeEvpPKeyHandle.OpenSslVersion propriedade não existe no .NET Core 2.1, portanto, a versão do OpenSSL não pode ser determinada de forma confiável em tempo de execução.

Versão introduzida

  • .NET Core 2.1.16
  • .NET Core 3.0.3
  • .NET Core 3.1.2

Categoria

Principais bibliotecas .NET

APIs afetadas

.NET Core 1.0

UnauthorizedAccessException lançado por FileSystemInfo.Attributes

No .NET Core, um UnauthorizedAccessException é lançado quando o chamador tenta definir um valor de atributo de arquivo, mas não tem permissão de gravação.

Alterar a descrição

No .NET Framework, um ArgumentException é lançado 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 é lançado se o chamador tentar definir um atributo de arquivo inválido.)

Versão introduzida

1.0

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

Categoria

Principais bibliotecas .NET

APIs afetadas

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

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

Alterar a descriçã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 por código gerenciado. O common language runtime não fornece exceções de estado de processo corrompido para o código gerenciado.

Versão introduzida

1.0

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

Categoria

Principais bibliotecas .NET

APIs afetadas

As propriedades do UriBuilder não precedem mais os caracteres à esquerda

UriBuilder.Fragment não mais precede um personagem principal # e UriBuilder.Query não mais precede um personagem principal ? quando um já está presente.

Alterar a descrição

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

A partir do .NET Core 1.0, essas propriedades não precedem mais os # caracteres ou ? ao valor armazenado se um já estiver presente no início da cadeia de caracteres.

Versão introduzida

1.0

Não é mais necessário remover explicitamente nenhum desses caracteres principais ao definir os valores de propriedade. Isso é especialmente útil quando você está anexando valores, porque você não precisa mais remover a entrelinha # ou ? cada vez que acrescenta.

Por exemplo, o trecho 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

Principais bibliotecas .NET

APIs afetadas

Process.StartInfo lança InvalidOperationException para processos que você não iniciou

Ler a Process.StartInfo propriedade para processos que seu código não iniciou lança um InvalidOperationExceptionarquivo .

Alterar a descriçã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.

A partir do .NET Core 1.0, se você ler a Process.StartInfo propriedade de um processo que não iniciou (ou seja, chamando Process.Start), um InvalidOperationException será lançado.

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 esta propriedade para processos retornados por Process.GetProcesses.

Categoria

Principais bibliotecas .NET

APIs afetadas