Comparteix a través de

Cambios importantes en las bibliotecas básicas de .NET en .NET Core 1.0-3.0

  • Article

Las bibliotecas principales de .NET proporcionan los tipos primitivos y otros tipos generales que usa .NET Core.

En esta página se documentan los siguientes cambios importantes:

Cambio importante Versión introducida
El paso de GroupCollection a métodos de extensión que toman IEnumerable<T> requiere desambiguación .NET Core 3.0
Las API que notifican la versión ahora notifican la versión del producto y no la del archivo .NET Core 3.0
Las instancias personalizadas de EncoderFallbackBuffer no pueden retroceder de forma recursiva .NET Core 3.0
Cambios en el comportamientos de formato y análisis de punto flotante .NET Core 3.0
Las operaciones de análisis de punto flotante ya no producen un error ni una excepción OverflowException .NET Core 3.0
Se ha movido InvalidAsynchronousStateException a otro ensamblado .NET Core 3.0
Al reemplazar las secuencias de bytes UTF-8 con formato incorrecto se siguen las instrucciones de Unicode .NET Core 3.0
Se ha movido TypeDescriptionProviderAttribute a otro ensamblado .NET Core 3.0
ZipArchiveEntry ya no controla los archivos con tamaños de entrada incoherentes .NET Core 3.0
FieldInfo.SetValue produce una excepción en los campos estáticos de solo inicialización .NET Core 3.0
Las API de ruta de acceso no inician ninguna excepción para caracteres no válidos .NET Core 2.1
Se han agregado campos privados a tipos struct integrados .NET Core 2.1
Cambio del valor predeterminado de UseShellExecute .NET Core 2.1
Versiones de OpenSSL en macOS .NET Core 2.1
UnauthorizedAccessException producida por FileSystemInfo.Attributes .NET Core 1.0
No se admite el control de excepciones de estado de proceso dañado .NET Core 1.0
Las propiedades UriBuilder ya no anteponen caracteres iniciales .NET Core 1.0
Process.StartInfo produce una excepción InvalidOperationException para los procesos que no se iniciaron .NET Core 1.0

.NET Core 3.0

El paso de GroupCollection a métodos de extensión que toman IEnumerable<T> requiere desambiguación

Al llamar a un método de extensión que toma IEnumerable<T> en un elemento GroupCollection, se debe eliminar la ambigüedad del tipo mediante una conversión.

Descripción del cambio

A partir de .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementa IEnumerable<KeyValuePair<String,Group>>, además de los otros tipos que implementa, incluido IEnumerable<Group>. Esto produce ambigüedad al llamar a un método de extensión que toma un elemento IEnumerable<T>. Si llama a un método de extensión como este en una instancia de GroupCollection, por ejemplo, Enumerable.Count, verá el error del compilador siguiente:

CS1061: "GroupCollection" no contiene una definición para "Count" ni se encuentra ningún método de extensión accesible "Count" que acepte un primer argumento del tipo "GroupCollection" (¿falta una directiva de uso o una referencia de ensamblado?) .

En versiones anteriores de .NET, no había ambigüedad ni ningún error del compilador.

Versión introducida

3.0

Motivo del cambio

Se trató de un cambio importante involuntario. Dado que no es algo nuevo de ahora, no tenemos previsto revertirlo. Además, un cambio de este tipo sería importante en sí mismo.

En el caso de instancias de GroupCollection, elimine la ambigüedad de las llamadas a métodos de extensión que aceptan un elemento IEnumerable<T> con una conversión.

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

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

Categoría

Bibliotecas de Core .NET

API afectadas

Los métodos de extensión que aceptan un elemento IEnumerable<T> se ven afectados. Por ejemplo:

Las API que notifican la versión ahora notifican la versión del producto y no la del archivo

Muchas de las API que devuelven versiones en .NET Core ahora devuelven la versión del producto en lugar de la del archivo.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, métodos como Environment.Version y RuntimeInformation.FrameworkDescription, y el cuadro de diálogo de las propiedades del archivo para los ensamblados de .NET Core reflejan la versión del archivo. A partir de .NET Core 3.0, reflejan la versión del producto.

En la ilustración siguiente se muestra la diferencia en la información sobre la versión del ensamblado System.Runtime.dll para .NET Core 2.2 (a la izquierda) y .NET Core 3.0 (a la derecha), tal y como se muestra en los cuadros de diálogo de las propiedades del archivo de Windows Explorer.

Difference in product version information

Versión introducida

3.0

Ninguno. Este cambio debería hacer que la comprobación de la versión sea intuitiva en lugar de difícil de entender.

Categoría

Bibliotecas de Core .NET

API afectadas

No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer

No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer. La implementación de EncoderFallbackBuffer.GetNextChar() debe traducirse en una secuencia de caracteres que se pueda convertir a la codificación de destino. De lo contrario, se produce una excepción.

Descripción del cambio

Durante una operación de transcodificación de caracteres a bytes, el runtime detecta secuencias UTF-16 de formato incorrecto o no convertibles y proporciona esos caracteres al método EncoderFallbackBuffer.Fallback. El método Fallback determina los caracteres que han de sustituirse por los datos originales no convertibles y estos caracteres se drenan llamando a EncoderFallbackBuffer.GetNextChar en un bucle.

El runtime intenta luego transcodificar estos caracteres de sustitución en la codificación de destino. Si esta operación se realiza correctamente, el runtime continúa con la transcodificación desde donde se quedó en la cadena de entrada original.

Antes, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() pueden devolver secuencias de caracteres que no se pueden convertir en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, el runtime vuelve a invocar el método EncoderFallbackBuffer.Fallback con los caracteres de sustitución, esperando que el método EncoderFallbackBuffer.GetNextChar() devuelva una nueva secuencia de sustitución. Este proceso continúa hasta que el runtime ve finalmente una sustitución convertible de formato correcto o hasta que se alcanza un número máximo de repeticiones.

A partir de .NET Core 3.0, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() deben devolver secuencias de caracteres que se pueden convertir en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, se produce una ArgumentException. El runtime ya no realizará llamadas recursivas a la instancia de EncoderFallbackBuffer.

Este comportamiento solo se aplica cuando se cumplen las tres condiciones siguientes:

  • El runtime detecta una secuencia UTF-16 de formato incorrecto o una secuencia UTF-16 que no se puede convertir en la codificación de destino.
  • Se ha especificado un EncoderFallback personalizado.
  • El EncoderFallback personalizado intenta sustituir una nueva secuencia UTF-16 con formato incorrecto o no convertible.

Versión introducida

3.0

La mayoría de los desarrolladores no tienen que realizar ninguna acción.

Si una aplicación usa un objeto EncoderFallback personalizado con una clase EncoderFallbackBuffer, asegúrese de que la implementación de EncoderFallbackBuffer.Fallback rellena el búfer de reserva con datos UTF-16 de formato correcto que se puedan convertir directamente en la codificación de destino cuando el runtime invoque por primera vez el método Fallback.

Categoría

Bibliotecas de Core .NET

API afectadas

Cambios en los comportamientos de formato y análisis de los números de punto flotante

Los comportamientos de formato y análisis de los números de punto flotante (de los tipos Double y Single) ahora son compatibles con IEEE. Esto garantiza que el comportamiento de los tipos de punto flotante en .NET coincide con el de otros lenguajes compatibles con IEEE. Por ejemplo, double.Parse("SomeLiteral") siempre debe coincidir con lo que C# genera para double x = SomeLiteral.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, dar formato con Double.ToString y Single.ToString, y realizar análisis con Double.Parse, Double.TryParse, Single.Parse y Single.TryParse no es compatible con IEEE. Como resultado, no es posible garantizar que un valor realizará todo el proceso con una cadena de formato estándar o personalizado compatible. En algunas entradas, se puede producir un error al intentar analizar un valor con formato y, en otras, el valor analizado no es igual que el valor original.

A partir de .NET Core 3.0, las operaciones de análisis y formato de punto flotante son compatibles con IEEE 754.

En la tabla siguiente se muestran dos fragmentos de código y cómo cambia la salida entre .NET Core2.2 y .NET Core 3.1.

Fragmento de código Salida en .NET Core 2.2 Salida en .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 obtener más información, vea la entrada de blog Mejoras de formato y análisis de punto flotante en .NET Core 3.0.

Versión introducida

3.0

La sección Impacto potencial en el código existente de la entrada de blog Mejoras en el análisis y el formato de los puntos flotantes en .NET Core 3.0 sugiere algunos cambios que puede hacer en su código si desea mantener el comportamiento anterior.

  • Para algunas diferencias de formato, puede obtener un comportamiento equivalente al anterior especificando una cadena de formato diferente.
  • En el caso de las diferencias de análisis, no hay ningún mecanismo para volver al comportamiento anterior.

Categoría

Bibliotecas de Core .NET

API afectadas

Las operaciones de análisis de punto flotante ya no producen un error o lanzan una excepción OverflowException

Los métodos de análisis de punto flotante ya no lanzan una OverflowException o devuelven false cuando analizan una cadena cuyo valor numérico está fuera del rango del tipo de punto flotante Single o Double.

Descripción del cambio

En .NET Core 2.2 y versiones anteriores, los métodos Double.Parse y Single.Parse lanzan una OverflowException para los valores que se encuentran fuera del rango de su tipo respectivo. Los métodos Double.TryParse y Single.TryParse devuelven false para las representaciones de cadena de valores numéricos fuera del rango.

A partir de .NET Core 3.0, los métodos Double.Parse, Double.TryParse, Single.Parse y Single.TryParse ya no producen errores al analizar cadenas numéricas fuera del rango. En su lugar, los métodos de análisis de Double devuelven Double.PositiveInfinity para los valores que superan Double.MaxValue y Double.NegativeInfinity para los valores menores que Double.MinValue. Del mismo modo, los métodos de análisis de Single devuelven Single.PositiveInfinity para los valores que superan Single.MaxValue y Single.NegativeInfinity para los valores menores que Single.MinValue.

Este cambio se ha realizado para mejorar el cumplimiento de la norma IEEE 754:2008.

Versión introducida

3.0

Este cambio puede afectar al código de alguna de estas dos formas:

  • El código depende del controlador para que OverflowException se ejecute cuando se produce un desbordamiento. En este caso, debe quitar la instrucción catch y colocar cualquier código necesario en una instrucción If que compruebe si Double.IsInfinity o Single.IsInfinity es true.

  • El código presupone que los valores de punto flotante no son Infinity. En este caso, debe agregar el código necesario para comprobar los valores de punto flotante de PositiveInfinity y NegativeInfinity.

Categoría

Bibliotecas de Core .NET

API afectadas

Se ha movido InvalidAsynchronousStateException a otro ensamblado

La clase InvalidAsynchronousStateException se ha movido.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, la clase InvalidAsynchronousStateException se encuentra en el ensamblado System.ComponentModel.TypeConverter.

A partir de .NET Core 3.0, se encuentra en el ensamblado System.ComponentModel.Primitives.

Versión introducida

3.0

Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar InvalidAsynchronousStateException mediante la llamada a un método como Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, actualice el ensamblado al que se hace referencia en la llamada de método para reflejar la nueva ubicación del ensamblado del tipo.

Categoría

Bibliotecas de Core .NET

API afectadas

Ninguno.

Al reemplazar las secuencias de bytes UTF-8 con formato incorrecto se siguen las instrucciones de Unicode

Cuando la clase UTF8Encoding encuentra una secuencia de bytes UTF-8 con formato incorrecto durante una operación de transcodificación de byte a carácter, reemplaza esa secuencia por un carácter "�" (CARÁCTER DE REEMPLAZO DE U+FFFD) en la cadena de salida. .NET Core 3.0 se diferencia de las versiones anteriores de .NET Core y de .NET Framework en que sigue los procedimientos recomendados de Unicode para realizar este reemplazo durante la operación de transcodificación.

Esto forma parte de un trabajo mayor para mejorar el control de UTF-8 en .NET, que los nuevos tipos System.Text.Unicode.Utf8 y System.Text.Rune incluyen. Se asignó una mecánica de control de errores mejorada al tipo UTF8Encoding para que genere una salida coherente con los tipos recién incorporados.

Descripción del cambio

A partir de .NET Core 3.0, al transcodificar bytes en caracteres, la clase UTF8Encoding realiza la sustitución de caracteres en función de los procedimientos recomendados de Unicode. El mecanismo de sustitución que se usa se describe en The Unicode Standard, Version 12.0, Sec. 3.9 (PDF) en el apartado titulado U+FFFD Substitution of Maximal Subparts.

Este comportamiento solo se aplica cuando la secuencia de bytes de entrada contiene datos UTF-8 con formato incorrecto. Además, si la instancia de UTF8Encoding se ha construido con throwOnInvalidBytes: true, la instancia de UTF8Encodingcontinuará produciéndose en una entrada no válida en lugar de realizar el reemplazo de U+FFFD. Para obtener más información sobre el constructor UTF8Encoding, vea UTF8Encoding(Boolean, Boolean).

En la siguiente tabla se muestra el impacto de este cambio con una entrada de 3 bytes no válida:

Entrada de 3 bytes con formato incorrecto Salida antes de .NET Core 3.0 Salida a partir de .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (salida de 2 caracteres) [ FFFD FFFD FFFD ] (salida de 3 caracteres)

La salida de 3 caracteres es la preferida, según la tabla 3-9 del PDF del estándar Unicode vinculado anteriormente.

Versión introducida

3.0

No se requiere ninguna acción por parte del desarrollador.

Categoría

Bibliotecas de Core .NET

API afectadas

Se ha movido TypeDescriptionProviderAttribute a otro ensamblado

La clase TypeDescriptionProviderAttribute se ha movido.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, la clase TypeDescriptionProviderAttribute se encuentra en el ensamblado System.ComponentModel.TypeConverter.

A partir de .NET Core 3.0, se encuentra en el ensamblado System.ObjectModel.

Versión introducida

3.0

Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar el tipo TypeDescriptionProviderAttribute mediante la llamada a un método como Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, el ensamblado al que se hace referencia en la llamada al método debe actualizarse para reflejar la nueva ubicación del ensamblado del tipo.

Categoría

Windows Forms

API afectadas

Ninguno.

ZipArchiveEntry ya no controla los archivos con tamaños de entrada incoherentes

Los archivos zip muestran tanto el tamaño comprimido como el tamaño no comprimido en el directorio central y en el encabezado local. Los propios datos de entrada también indican su tamaño. En .NET Core 2.2 y versiones anteriores, nunca se comprobó la coherencia de estos valores. A partir de .NET Core 3.0, ahora son.

Descripción del cambio

En .NET Core 2.2 y versiones anteriores, ZipArchiveEntry.Open() funciona correctamente aunque el encabezado local no concuerde con el encabezado central del archivo zip. Los datos se descomprimen hasta que se alcanza el final del flujo comprimido, aunque su longitud supere el tamaño de archivo sin comprimir que se muestra en el directorio central/encabezado local.

A partir de .NET Core 3.0, el método ZipArchiveEntry.Open() comprueba que el encabezado local y el encabezado central coinciden en el tamaño comprimido y no comprimido de una entrada. Si no coinciden, el método produce una InvalidDataException si el encabezado local del archivo o el tamaño de la lista de descriptores de datos que no están en desacuerdo con el directorio central del archivo zip. Al leer una entrada, los datos descomprimidos se truncan hasta el tamaño de archivo sin comprimir que se muestra en el encabezado.

Este cambio se realizó para asegurarse de que un ZipArchiveEntryrepresenta correctamente el tamaño de sus datos y que solo se lee esa cantidad de datos.

Versión introducida

3.0

Vuelva a empaquetar los archivos ZIP que presentan estos problemas.

Categoría

Bibliotecas de Core .NET

API afectadas

FieldInfo.SetValue produce una excepción en los campos estáticos de solo inicialización

A partir de .NET Core 3.0, se produce una excepción si intenta establecer un valor en un campo InitOnly estático al llamar a System.Reflection.FieldInfo.SetValue.

Descripción del cambio

En .NET Framework y en versiones de .NET Core anteriores a la 3.0, podía establecer el valor de un campo estático constante una vez inicializado (readonly en C#) mediante una llamada a System.Reflection.FieldInfo.SetValue. Con todo, al establecer este tipo de campo de esta manera, se producía un comportamiento imprevisible en función de la plataforma de destino y la configuración de optimización.

En .NET Core 3.0 y versiones posteriores, al llamar a SetValue en un campo InitOnly estático, se produce una excepción System.FieldAccessException.

Sugerencia

Un campo InitOnly es uno que solo se puede establecer en el momento en que se declara o en el constructor de la clase contenedora. En otras palabras, es constante después de inicializarse.

Versión introducida

3.0

Inicialice los campos InitOnly estáticos en un constructor estático. Esto se aplica a los tipos dinámicos y no dinámicos.

Como alternativa, puede quitar el atributo FieldAttributes.InitOnly del campo y después llamar a FieldInfo.SetValue.

Categoría

Bibliotecas de Core .NET

API afectadas

.NET Core 2.1

Las API de ruta de acceso no inician ninguna excepción para caracteres no válidos

Las API que implican rutas de acceso de archivo ya no validan los caracteres de ruta de acceso ni inician ninguna excepción ArgumentException si se encuentra un carácter no válido.

Descripción del cambio

En .NET Framework y .NET Core 1.0 y 2.0, los métodos enumerados en la sección API afectadas inician una excepción ArgumentException si el argumento de ruta de acceso contiene un carácter de ruta que no es válido. A partir de .NET Core 2.1, estos métodos ya no comprueban si hay caracteres de ruta de acceso no válidos ni inician una excepción si se encuentra un carácter no válido.

Motivo del cambio

La validación agresiva de caracteres de ruta de acceso bloquea algunos escenarios multiplataforma. Este cambio se introdujo para que .NET no intentara replicar ni predecir el resultado de las llamadas API del sistema operativo. Para obtener más información, vea la entrada de blog Vista rápida de System.IO en .NET Core 2.1.

Versión introducida

.NET Core 2.1

Si su código se basaba en estas API para comprobar si había caracteres no válidos, puede agregar una llamada a Path.GetInvalidPathChars.

API afectadas

Consulte también

Campos privados agregados a tipos struct integrados

Se han agregado campos privados a algunos tipos de struct en ensamblados de referencia. Como resultado, en C#, siempre se deben crear instancias de esos structs mediante el operador new o un literal predeterminado.

Descripción del cambio

En .NET Core 2.0 y versiones anteriores, se podría crear una instancia de algunos tipos de struct proporcionados, por ejemplo, ConsoleKeyInfo, sin usar el operador new ni un literal predeterminado en C#. Esto se debe a que los ensamblados de referencia que usa el compilador de C# no contenían los campos privados de los structs. Todos los campos privados de los tipos de struct .NET se agregan a los ensamblados de referencia a partir de .NET Core 2.1.

Por ejemplo, el siguiente código de C# se compila en .Net Core 2.0, pero no en .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

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

En .NET Core 2.1, el código anterior genera el siguiente error del compilador: CS0165 - Uso de la variable local no asignada "key"

Versión introducida

2.1

Cree instancias de tipos de struct mediante el operador new o el literal predeterminado.

Por ejemplo:

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!");

Categoría

Bibliotecas de Core .NET

API afectadas

Cambio del valor predeterminado de UseShellExecute

ProcessStartInfo.UseShellExecute tiene un valor predeterminado de false en .NET Core. En .NET Framework, su valor predeterminado es true.

Descripción del cambio

Process.Start permite iniciar una aplicación directamente, por ejemplo, con código como Process.Start("mspaint.exe") que inicia Paint. También permite iniciar indirectamente una aplicación asociada si ProcessStartInfo.UseShellExecute se establece en true. En .NET Framework, el valor predeterminado de ProcessStartInfo.UseShellExecute es true, lo que significa que código como Process.Start("mytextfile.txt") iniciaría el Bloc de notas, si ha asociado archivos .txt con ese editor. Para evitar el inicio indirecto de una aplicación en .NET Framework, debe establecer explícitamente ProcessStartInfo.UseShellExecute en false. En .NET Core, el valor predeterminado de ProcessStartInfo.UseShellExecute es false. Esto significa que, de forma predeterminada, las aplicaciones asociadas no se inician cuando se llama a Process.Start.

Las siguientes propiedades de System.Diagnostics.ProcessStartInfo solo funcionan cuando ProcessStartInfo.UseShellExecute es true:

Este cambio se introdujo en .NET Core por motivos de rendimiento. Normalmente, Process.Start se usa para iniciar una aplicación directamente. Iniciar una aplicación directamente no implica el uso del shell de Windows e incurrir en el costo de rendimiento asociado. Para que este caso predeterminado sea más rápido, .NET Core cambia el valor predeterminado de ProcessStartInfo.UseShellExecute por false. Puede optar por la ruta de acceso más lenta si lo necesita.

Versión introducida

2.1

Nota

En versiones anteriores de .NET Core, no se implementaba UseShellExecute para Windows.

Si la aplicación se basa en el comportamiento anterior, llame a Process.Start(ProcessStartInfo) con UseShellExecute establecido en true en el objeto ProcessStartInfo.

Categoría

Bibliotecas de Core .NET

API afectadas

Versiones de OpenSSL en macOS

Ahora, los runtime de .NET Core 3.0 y versiones posteriores en macOS prefieren las versiones de OpenSSL 1.1.x a las versiones de OpenSSL 1.0.x en los tipos AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSsl, RSAOpenSsl y SafeEvpPKeyHandle.

Ahora, el runtime de .NET Core 2.1 es compatible con las versiones de OpenSSL 1.1.x, pero siguen siendo preferibles las versiones de OpenSSL 1.0.x.

Descripción del cambio

Antes, el runtime de .NET Core usaba versiones de OpenSSL 1.0.x en macOS para en los tipos que interactúan con OpenSSL. La versión más reciente de OpenSSL 1.0.x, OpenSSL 1.0.2, ya no se admite. Para mantener los tipos que usan OpenSSL en versiones compatibles de OpenSSL, los runtime de .NET Core 3.0 y versiones posteriores usan ahora las versiones más recientes de OpenSSL en macOS.

Con este cambio, el comportamiento de los runtime de .NET Core en macOS es el siguiente:

  • Los runtime de .NET Core 3.0 y versiones posteriores usan OpenSSL 1.1.x (si está disponible) y revierten a OpenSSL 1.0.x solo si no hay disponible ninguna versión 1.1.x.

    En el caso de los autores de llamada que usen los tipos de interoperabilidad de OpenSSL con P/Invoke personalizados, siga las instrucciones de los comentarios sobre SafeEvpPKeyHandle.OpenSslVersion. La aplicación se puede bloquear si no se comprueba el valor de OpenSslVersion.

  • Los runtime de .NET Core 2.1 usan OpenSSL 1.0.x (si está disponible) y revierten a OpenSSL 1.1.x si no hay disponible ninguna versión 1.0.x.

    El runtime 2.1 prefiere la versión anterior de OpenSSL porque la propiedad SafeEvpPKeyHandle.OpenSslVersion no existe en .NET Core 2.1, por lo que la versión de OpenSSL no se puede determinar de forma confiable en tiempo de ejecución.

Versión introducida

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

Categoría

Bibliotecas de Core .NET

API afectadas

.NET Core 1.0

UnauthorizedAccessException producida por FileSystemInfo.Attributes

En .NET Core, se produce una UnauthorizedAccessException si el autor de la llamada intenta establecer un valor de atributo de archivo pero no tiene permiso de escritura.

Descripción del cambio

En .NET Framework, se produce una ArgumentException si el autor de la llamada intenta establecer un valor de atributo de archivo en FileSystemInfo.Attributes pero no tiene permiso de escritura. En .NET Core, se produce una UnauthorizedAccessException en su lugar. (En .NET Core, se sigue produciendo una ArgumentException si el autor de la llamada intenta establecer un atributo de archivo no válido).

Versión introducida

1.0

Modifique las instrucciones catch para capturar una UnauthorizedAccessException en lugar de una ArgumentException, o además de esta, según sea necesario.

Categoría

Bibliotecas de Core .NET

API afectadas

No se admite el control de excepciones de estado dañado

No se admite el control de excepciones de estado de proceso dañado en .NET Core.

Descripción del cambio

Anteriormente, las excepciones de estado de proceso dañado podían detectarse y controlarse mediante controladores de excepciones de código administrado, por ejemplo, al usar una instrucción try-catch en C#.

A partir de .NET Core 1.0, las excepciones de estado de proceso dañado no se pueden controlar mediante código administrado. Common Language Runtime no entrega las excepciones de estado de proceso dañado al código administrado.

Versión introducida

1.0

Para no tener que controlar las excepciones de estado de proceso dañado, aborde las situaciones que conducen a ellas. Si es absolutamente necesario controlar las excepciones de estado de proceso dañado, escriba el controlador de excepciones en código de C o C++.

Categoría

Bibliotecas de Core .NET

API afectadas

Las propiedades UriBuilder ya no anteponen caracteres iniciales

UriBuilder.Fragment ya no antepone un carácter # inicial y UriBuilder.Query ya no antepone un carácter ? inicial si ya existe uno.

Descripción del cambio

En .NET Framework, las propiedades UriBuilder.Fragment y UriBuilder.Query siempre anteponen un carácter # o ?, respectivamente, al valor que se va a almacenar. Este comportamiento puede producir varios caracteres # o ? en el valor almacenado si la cadena ya contiene uno de estos caracteres iniciales. Por ejemplo, el valor de UriBuilder.Fragment podría convertirse en ##main.

A partir de .NET Core 1.0, estas propiedades ya no anteponen los caracteres # o ? al valor almacenado si ya hay uno presente al principio de la cadena.

Versión introducida

1.0

Ya no es necesario quitar explícitamente ninguno de estos caracteres iniciales al establecer los valores de propiedad. Esto es especialmente útil cuando se anexan valores, puesto que ya no es necesario quitar los caracteres # iniciales o ? al anexar.

Por ejemplo, en el siguiente fragmento de código puede verse la diferencia de comportamiento entre .NET Framework y .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);
  • En .NET Framework, el resultado es ????one=1&two=2&three=3&four=4.
  • En .NET Core, el resultado es ?one=1&two=2&three=3&four=4.

Categoría

Bibliotecas de Core .NET

API afectadas

Process.StartInfo produce una excepción InvalidOperationException para los procesos que no se iniciaron

Al leer la propiedad Process.StartInfo de los procesos que el código no ha iniciado, se produce una excepción InvalidOperationException.

Descripción del cambio

En .NET Framework, el acceso a la propiedad Process.StartInfo para los procesos que el código no inició devuelve un objeto ProcessStartInfo ficticio. El objeto ficticio contiene los valores predeterminados de todas sus propiedades excepto EnvironmentVariables.

A partir de .NET Core 1,0, si lee la propiedad Process.StartInfo de un proceso que no se inició (es decir, mediante la llamada a Process.Start), se produce una excepción InvalidOperationException.

Versión introducida

1.0

No acceda a la propiedad Process.StartInfo de los procesos que el código no ha iniciado. Por ejemplo, no lea esta propiedad de los procesos devueltos por Process.GetProcesses.

Categoría

Bibliotecas de Core .NET

API afectadas