Cursos
Módulo
Trabajo con archivos y directorios en una aplicación .NET - Training
Aprenda a usar .NET, C# y System.IO para trabajar con directorios, rutas de acceso, archivos y el sistema de archivos.
Este explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
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:
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.
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.
3.0
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);
Bibliotecas de Core .NET
Los métodos de extensión que aceptan un elemento IEnumerable<T> se ven afectados. Por ejemplo:
System.Linq.Enumerable
, por ejemplo, System.Linq.Enumerable.CountMuchas de las API que devuelven versiones en .NET Core ahora devuelven la versión del producto en lugar de la del archivo.
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.
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.
Bibliotecas de Core .NET
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.
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:
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.
Bibliotecas de Core .NET
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
.
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.
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.
Bibliotecas de Core .NET
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.
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.
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
.
Bibliotecas de Core .NET
La clase InvalidAsynchronousStateException se ha movido.
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.
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.
Bibliotecas de Core .NET
Ninguno.
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.
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 UTF8Encoding
continuará 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.
3.0
No se requiere ninguna acción por parte del desarrollador.
Bibliotecas de Core .NET
La clase TypeDescriptionProviderAttribute se ha movido.
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.
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.
Windows Forms
Ninguno.
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.
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.
3.0
Vuelva a empaquetar los archivos ZIP que presentan estos problemas.
Bibliotecas de Core .NET
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.
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.
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.
Bibliotecas de Core .NET
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.
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.
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.
.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.
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.
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"
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!");
Bibliotecas de Core .NET
ProcessStartInfo.UseShellExecute tiene un valor predeterminado de false
en .NET Core. En .NET Framework, su valor predeterminado es true
.
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.
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.
Bibliotecas de Core .NET
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.
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.
Desinstale la versión 1.0.2 de OpenSSL si ya no la necesita.
Instale OpenSSL 1.1.x si usa los tipos AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSsl, RSAOpenSsl o SafeEvpPKeyHandle.
Si usa los tipos de interoperabilidad de OpenSSL con P/Invoke personalizados, siga las instrucciones de los comentarios sobre SafeEvpPKeyHandle.OpenSslVersion.
Bibliotecas de Core .NET
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.
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).
1.0
Modifique las instrucciones catch
para capturar una UnauthorizedAccessException en lugar de una ArgumentException, o además de esta, según sea necesario.
Bibliotecas de Core .NET
No se admite el control de excepciones de estado de proceso dañado en .NET Core.
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.
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++.
Bibliotecas de Core .NET
UriBuilder.Fragment ya no antepone un carácter #
inicial y UriBuilder.Query ya no antepone un carácter ?
inicial si ya existe uno.
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.
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);
????one=1&two=2&three=3&four=4
.?one=1&two=2&three=3&four=4
.Bibliotecas de Core .NET
Al leer la propiedad Process.StartInfo de los procesos que el código no ha iniciado, se produce una excepción InvalidOperationException.
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.
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.
Bibliotecas de Core .NET
Comentarios de .NET
.NET es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Cursos
Módulo
Trabajo con archivos y directorios en una aplicación .NET - Training
Aprenda a usar .NET, C# y System.IO para trabajar con directorios, rutas de acceso, archivos y el sistema de archivos.