Modifiche che causano un'interruzione alle librerie .NET Core 1.0-3.0

  • Articolo

Le librerie .NET principali forniscono le primitive e altri tipi generali usati da .NET Core.

Le seguenti modifiche che causano un’interruzione sono documentate in questa pagina:

Modifica Versione introdotta
Il passaggio di GroupCollection ai metodi di estensione che accettano IEnumerable<T> richiede la disambiguazione .NET Core 3.0
Le API che segnalano la versione ora segnalano la versione del prodotto e non quella del file .NET Core 3.0
Le istanze personalizzate di EncoderFallbackBuffer non possono eseguire il fallback in modo ricorsivo .NET Core 3.0
Modifiche del comportamento di formattazione e analisi a virgola mobile .NET Core 3.0
Le operazioni di analisi a virgola mobile non hanno più esito negativo né generano un'eccezione OverflowException .NET Core 3.0
La classe InvalidAsynchronousStateException è stata spostata in un altro assembly .NET Core 3.0
La sostituzione delle sequenze di byte UTF-8 in formato non corretto segue le linee guida Unicode .NET Core 3.0
La classe TypeDescriptionProviderAttribute è stata spostata in un altro assembly .NET Core 3.0
ZipArchiveEntry non gestisce più gli archivi con dimensioni delle voci incoerenti .NET Core 3.0
FieldInfo.SetValue genera un'eccezione per i campi statici di sola inizializzazione .NET Core 3.0
Le API di percorso non generano un'eccezione per i caratteri non validi .NET Core 2.1
Campi privati aggiunti ai tipi di struct predefiniti .NET Core 2.1
Modifica nel valore predefinito di UseShellExecute .NET Core 2.1
Versioni di OpenSSL in macOS .NET Core 2.1
UnauthorizedAccessException generata da FileSystemInfo.Attributes .NET Core 1.0
La gestione delle eccezioni con stato danneggiato del processo non è supportata .NET Core 1.0
Le proprietà UriBuilder non antepongono più caratteri iniziali .NET Core 1.0
Process.StartInfo genera InvalidOperationException per i processi non avviati dall'utente .NET Core 1.0

.NET Core 3.0

Il passaggio di GroupCollection ai metodi di estensione che accettano IEnumerable<T> richiede la disambiguazione

Quando si chiama un metodo di estensione che accetta IEnumerable<T> su un elemento GroupCollection, è necessario eliminare le ambiguità in merito al tipo usando un cast.

Descrizione delle modifiche

A partire da .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementa IEnumerable<KeyValuePair<String,Group>> oltre agli altri tipi implementati, tra cui IEnumerable<Group>. Questo crea ambiguità quando si chiama un metodo di estensione che accetta un elemento IEnumerable<T>. Se si chiama tale metodo di estensione su un'istanza di GroupCollection, ad esempio Enumerable.Count, verrà visualizzato l'errore del compilatore seguente:

CS1061: 'GroupCollection' non contiene una definizione di 'Count' e non è stato trovato alcun metodo di estensione accessibile 'Count' che accetta un primo argomento di tipo 'GroupCollection'. Probabilmente manca una direttiva using o un riferimento all'assembly.

Nelle versioni precedenti di .NET non c'erano ambiguità né si verificavano errori del compilatore.

Versione introdotta

3,0

Motivo della modifica

Si tratta di una modifica che causa un'interruzione involontaria. Perché la situazione è così già da qualche tempo, non abbiamo intenzione di ripristinare il comportamento precedente. Inoltre, la modifica stessa sarebbe causa di interruzioni.

Per le istanze GroupCollection, disambigua le chiamate ai metodi di estensione che accettano un oggetto IEnumerable<T> con un cast.

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

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

Category

Principali librerie .NET

API interessate

Qualsiasi metodo di estensione che accetta un elemento IEnumerable<T> è interessato. Ad esempio:

Le API che segnalano la versione ora segnalano la versione del prodotto e non quella del file

Molte API che restituiscono le versioni in .NET Core restituiscono ora la versione del prodotto anziché la versione del file.

Descrizione delle modifiche

In .NET Core 2.2 e versioni precedenti, i metodi come Environment.Version, RuntimeInformation.FrameworkDescription e la finestra di dialogo delle proprietà del file per gli assembly .NET Core riflettono la versione del file. A partire da .NET Core 3.0, riflettono la versione del prodotto.

La figura seguente illustra la differenza nelle informazioni sulla versione dell'assembly System.Runtime.dll per .NET Core 2.2 (a sinistra) e .NET Core 3.0 (a destra) così come visualizzate nella finestra di dialogo delle proprietà del file di Esplora risorse.

Difference in product version information

Versione introdotta

3,0

Nessuno. Questa modifica dovrebbe rendere più intuitivo il rilevamento della versione.

Category

Principali librerie .NET

API interessate

Le istanze personalizzate di EncoderFallbackBuffer non possono eseguire il fallback in modo ricorsivo

Le istanze personalizzate di EncoderFallbackBuffer non possono eseguire il fallback in modo ricorsivo. L'implementazione di EncoderFallbackBuffer.GetNextChar() deve produrre una sequenza di caratteri convertibile nella codifica di destinazione. In caso contrario, viene generata un'eccezione.

Descrizione delle modifiche

Durante un'operazione di transcodifica da carattere a byte, il runtime rileva le sequenze UTF-16 in formato non corretto o non convertibili e fornisce tali caratteri al metodo EncoderFallbackBuffer.Fallback. Il metodo Fallback determina quali caratteri vanno sostituiti per i dati originali non convertibili e questi caratteri vengono eliminati chiamando EncoderFallbackBuffer.GetNextChar in un ciclo.

Il runtime tenta quindi di transcodificare questi caratteri sostitutivi nella codifica di destinazione. Se l'operazione ha esito positivo, il runtime continua la transcodifica dal punto in cui è stata interrotta nella stringa di input originale.

Nelle versioni precedenti, le implementazioni personalizzate di EncoderFallbackBuffer.GetNextChar() possono restituire sequenze di caratteri non convertibili nella codifica di destinazione. Se non è possibile transcodificare i caratteri sostituiti nella codifica di destinazione, il runtime richiama nuovamente il metodo EncoderFallbackBuffer.Fallback con i caratteri di sostituzione, aspettandosi che il metodo EncoderFallbackBuffer.GetNextChar() restituisca una nuova sequenza di sostituzione. Questo processo continua fino a quando il runtime non ottiene una sostituzione in formato corretto e convertibile o finché non viene raggiunto il numero massimo di ricorsioni.

A partire da .NET Core 3.0, le implementazioni personalizzate di EncoderFallbackBuffer.GetNextChar() devono restituire sequenze di caratteri convertibili nella codifica di destinazione. Se i caratteri sostituiti non possono essere transcodificati nella codifica di destinazione, viene generata un'eccezione ArgumentException. Il runtime non effettuerà più chiamate ricorsive all'istanza di EncoderFallbackBuffer.

Questo comportamento si applica solo quando vengono soddisfatte tutte e tre le condizioni seguenti:

  • Il runtime rileva una sequenza UTF-16 in formato non corretto o che non può essere convertita nella codifica di destinazione.
  • È stato specificato un elemento EncoderFallback personalizzato.
  • L'istanza personalizzata di EncoderFallback prova a sostituire una nuova sequenza UTF-16 in formato non corretto o non convertibile.

Versione introdotta

3,0

La maggior parte degli sviluppatori non deve fare nulla.

Se un'applicazione usa un elemento EncoderFallback e una classe EncoderFallbackBuffer personalizzati, assicurati che l'implementazione di EncoderFallbackBuffer.Fallback popoli il buffer di fallback con dati UTF-16 in formato corretto e direttamente convertibili nella codifica di destinazione la prima volta che il runtime richiama il metodo Fallback.

Category

Principali librerie .NET

API interessate

Comportamento di formattazione e analisi a virgola mobile modificato

Il comportamento di analisi e formattazione a virgola mobile (in base ai tipi Double e Single) è ora conforme allo standard IEEE. Questo assicura che il comportamento dei tipi a virgola mobile in .NET corrisponda a quello di altri linguaggi conformi allo standard IEEE. Ad esempio, double.Parse("SomeLiteral") deve corrispondere sempre a quello che C# produce per double x = SomeLiteral.

Descrizione delle modifiche

In .NET Core 2.2 e versioni precedenti, la formattazione con Double.ToString e Single.ToString e l'analisi con Double.Parse, Double.TryParse, Single.Parse e Single.TryParse non sono conformi allo standard IEEE. Di conseguenza, è impossibile garantire che un valore esegua il round trip con qualunque stringa di formato standard o personalizzato compatibile. Per alcuni input il tentativo di analizzare un valore formattato può avere esito negativo, mentre per altri il valore analizzato non equivale al valore originale.

A partire da .NET Core 3.0, le operazioni di analisi e formattazione a virgola mobile sono compatibili con lo standard IEEE 754.

La tabella seguente mostra due frammenti di codice e il modo in cui l'output cambia tra .NET Core 2.2 e .NET Core 3.1.

Frammento di codice Output in .NET Core 2.2 Output in .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Per altre informazioni, fai riferimento al post di blog Floating-Point Parsing and Formatting improvements in .NET Core 3.0 (Miglioramenti dell'analisi e della formattazione a virgola mobile in .NET Core 3.0).

Versione introdotta

3,0

La sezione Potential impact to existing code (Potenziale impatto sul codice esistente) del post di blog Floating-point parsing and formatting improvements in .NET Core 3.0 (Miglioramenti dell'analisi e della formattazione a virgola mobile in .NET Core 3.0) suggerisce alcune modifiche che è possibile apportare al codice se si vuole mantenere il comportamento precedente.

  • Per alcune differenze nella formattazione, è possibile ottenere un comportamento equivalente al precedente specificando una stringa di formato diversa.
  • Per le differenze nell'analisi, non esiste alcun meccanismo per eseguire il fallback al comportamento precedente.

Category

Principali librerie .NET

API interessate

Le operazioni di analisi a virgola mobile non hanno più esito negativo né generano un'eccezione OverflowException

I metodi di analisi a virgola mobile non generano più un'eccezione OverflowException o restituiscono false quando analizzano una stringa il cui valore numerico non è compreso nell'intervallo del tipo a virgola mobile Single o Double.

Descrizione delle modifiche

In .NET Core 2.2 e versioni precedenti, i metodi Double.Parse e Single.Parse generano un'eccezione OverflowException per i valori che non rientrano nell'intervallo del rispettivo tipo. I metodi Double.TryParse e Single.TryParse restituiscono false per le rappresentazioni in forma di stringa di valori numerici non compresi nell'intervallo consentito.

A partire da .NET Core 3.0, i metodi Double.Parse, Double.TryParse, Single.Parse e Single.TryParse non hanno più esito negativo quando analizzano stringhe numeriche non comprese nell'intervallo consentito. I metodi di analisi Double restituiscono invece Double.PositiveInfinity per i valori che superano Double.MaxValue e Double.NegativeInfinity per i valori minori di Double.MinValue. Analogamente, i metodi di analisi Single restituiscono Single.PositiveInfinity per i valori che superano Single.MaxValue e Single.NegativeInfinity per i valori minori di Single.MinValue.

Questa modifica è stata apportata per migliorare la conformità con lo standard IEEE 754-2008.

Versione introdotta

3,0

Questa modifica può influire sul codice in uno dei due modi seguenti:

  • Il codice dipende dal gestore per l'esecuzione di OverflowException quando si verifica un overflow. In questo caso, è necessario rimuovere l'istruzione catch e inserire qualsiasi codice necessario in un'istruzione If che verifica se Double.IsInfinity o Single.IsInfinity è true.

  • Il codice presuppone che i valori a virgola mobile non siano Infinity. In questo caso, è necessario aggiungere il codice necessario per verificare la presenza di valori a virgola mobile PositiveInfinity e NegativeInfinity.

Category

Principali librerie .NET

API interessate

La classe InvalidAsynchronousStateException è stata spostata in un altro assembly

La classe InvalidAsynchronousStateException è stata spostata.

Descrizione delle modifiche

In .NET Core 2.2 e versioni precedenti, la classe InvalidAsynchronousStateException si trova nell'assembly System.ComponentModel.TypeConverter.

A partire da .NET Core 3.0, si trova nell'assembly System.ComponentModel.Primitives.

Versione introdotta

3,0

Questa modifica influisce solo sulle applicazioni che usano la reflection per caricare InvalidAsynchronousStateException chiamando un metodo come Assembly.GetType o un overload di Activator.CreateInstance che presuppone che il tipo si trovi in un assembly specifico. In tal caso, aggiorna l'assembly a cui viene fatto riferimento nella chiamata al metodo per riflettere il nuovo percorso dell'assembly del tipo.

Category

Principali librerie .NET

API interessate

Nessuno.

La sostituzione delle sequenze di byte UTF-8 in formato non corretto segue le linee guida Unicode

Quando la classe UTF8Encoding rileva una sequenza di byte UTF-8 in formato non corretto durante un'operazione di transcodifica da byte a carattere, sostituisce tale sequenza con un carattere "�" (carattere di sostituzione U+FFFD) nella stringa di output. .NET Core 3.0 differisce dalle versioni precedenti di .NET Core e .NET Framework in quanto segue la procedura consigliata di Unicode che prevede di eseguire questa sostituzione durante l'operazione di transcodifica.

Questa modifica è parte di un'iniziativa più ampia volta a migliorare la gestione di UTF-8 in .NET, che include i nuovi tipi System.Text.Unicode.Utf8 e System.Text.Rune. Al tipo UTF8Encoding è stato assegnato un meccanismo di gestione degli errori migliorato, in modo che produca un output coerente con i nuovi tipi introdotti.

Descrizione delle modifiche

A partire da .NET Core 3.0, durante la transcodifica dei byte in caratteri, la classe UTF8Encoding sostituisce i caratteri in base alle procedure consigliate per il formato Unicode. Il meccanismo di sostituzione usato è descritto nel documento The Unicode Standard, Version 12.0, Sec. 3.9 (PDF) nell'intestazione intitolata U+FFFD Substitution of Maximal Subparts.

Questo comportamento si applica solo quando la sequenza di byte di input contiene dati UTF-8 in formato non corretto. Inoltre, se l'istanza di UTF8Encoding è stata costruita con throwOnInvalidBytes: true, l'istanza di UTF8Encoding continuerà a generare eccezioni di input non valido anziché eseguire la sostituzione con il carattere U+FFFD. Per altre informazioni sul costruttore UTF8Encoding, fai riferimento a UTF8Encoding(Boolean, Boolean).

La tabella seguente illustra l'impatto di questa modifica con un input a 3 byte non valido:

Input a 3 byte in formato non corretto Output prima di .NET Core 3.0 Output a partire da .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (output di 2 caratteri) [ FFFD FFFD FFFD ] (output di 3 caratteri)

L'output di 3 caratteri è l'output preferito secondo la Tabella 3-9 del PDF sullo standard Unicode indicato in precedenza.

Versione introdotta

3,0

Non è necessaria alcuna azione da parte dello sviluppatore.

Category

Principali librerie .NET

API interessate

La classe TypeDescriptionProviderAttribute è stata spostata in un altro assembly

La classe TypeDescriptionProviderAttribute è stata spostata.

Descrizione delle modifiche

In .NET Core 2.2 e versioni precedenti la classe TypeDescriptionProviderAttribute si trova nell'assembly System.ComponentModel.TypeConverter.

A partire da .NET Core 3.0, si trova nell'assembly System.ObjectModel.

Versione introdotta

3,0

Questa modifica influisce solo sulle applicazioni che usano la reflection per caricare il tipo TypeDescriptionProviderAttribute chiamando un metodo come Assembly.GetType o un overload di Activator.CreateInstance che presuppone che il tipo si trovi in un assembly specifico. In tal caso, l'assembly a cui viene fatto riferimento nella chiamata al metodo va aggiornato in modo da riflettere il nuovo percorso dell'assembly del tipo.

Category

WinForms

API interessate

Nessuno.

ZipArchiveEntry non gestisce più gli archivi con dimensioni delle voci incoerenti

Gli archivi ZIP elencano nella directory centrale e nell'intestazione locale sia le dimensioni compresse che le dimensioni non compresse. I dati stessi delle voci indicano anche le dimensioni. In .NET Core 2.2 e versioni precedenti, la coerenza di questi valori non veniva mai verificata. A partire da .NET Core 3.0 viene invece verificata.

Descrizione delle modifiche

In .NET Core 2.2 e versioni precedenti, ZipArchiveEntry.Open() ha esito positivo anche se l'intestazione locale non concorda con l'intestazione centrale del file ZIP. I dati vengono decompressi finché non viene raggiunta la fine del flusso compresso, anche se la sua lunghezza supera le dimensioni del file non compresso indicate nell'intestazione locale o nella directory centrale.

A partire da .NET Core 3.0, il metodo ZipArchiveEntry.Open() verifica che le dimensioni compresse e non compresse di una voce indicate nell'intestazione locale e nell'intestazione centrale coincidano. In caso contrario, il metodo genera un'eccezione InvalidDataException se l'intestazione locale dell'archivio e/o il descrittore dei dati elencano dimensioni delle voci discordanti rispetto alla directory centrale del file ZIP. Durante la lettura di una voce, i dati decompressi vengono troncati in corrispondenza delle dimensioni del file non compresso citate nell'intestazione.

Questa modifica è stata apportata per garantire che un elemento ZipArchiveEntry rappresenti correttamente le dimensioni dei suoi dati e che venga letta solo la quantità di dati indicata.

Versione introdotta

3,0

Ricrea il pacchetto di qualsiasi archivio ZIP che presenti questi problemi.

Category

Principali librerie .NET

API interessate

FieldInfo.SetValue genera un'eccezione per i campi statici di sola inizializzazione

A partire da .NET Core 3.0, viene generata un'eccezione quando si prova a impostare un valore su un campo InitOnly statico chiamando System.Reflection.FieldInfo.SetValue.

Descrizione delle modifiche

In .NET Framework e nelle versioni di .NET Core precedenti alla 3.0 è possibile impostare il valore di un campo statico costante dopo l'inizializzazione (readonly in C#) chiamando System.Reflection.FieldInfo.SetValue. Tuttavia, impostare un campo di questo tipo in questo modo produceva un comportamento imprevedibile in base al framework di destinazione e alle impostazioni di ottimizzazione.

In .NET Core 3.0 e versioni successive, quando si chiama SetValue su un campo InitOnly statico viene generata un'eccezione System.FieldAccessException.

Suggerimento

Un campo InitOnly è un campo che può essere impostato solo nel momento in cui viene dichiarato o nel costruttore per la classe contenitore. In altre parole, è costante dopo l'inizializzazione.

Versione introdotta

3,0

Inizializza i campi InitOnly statici in un costruttore statico. Questo vale sia per i tipi dinamici, sia per quelli non dinamici.

In alternativa, è possibile rimuovere l'attributo FieldAttributes.InitOnly dal campo e quindi chiamare FieldInfo.SetValue.

Category

Principali librerie .NET

API interessate

.NET Core 2.1

Le API di percorso non generano un'eccezione per i caratteri non validi

Le API che coinvolgono percorsi di file non convalidano più i caratteri di percorso o generano ArgumentException se viene trovato un carattere non valido.

Descrizione delle modifiche

In .NET Framework e .NET Core 1.0 - 2.0 i metodi elencati nella sezione API interessate generano ArgumentException se l'argomento percorso contiene un carattere di percorso non valido. A partire da .NET Core 2.1, questi metodi non controllano più caratteri di percorso non validi né generano un'eccezione se viene trovato un carattere non valido.

Motivo della modifica

La convalida aggressiva dei caratteri di percorso blocca alcuni scenari multipiattaforma. Questa modifica è stata introdotta in modo che .NET non tenti di replicare o prevedere il risultato delle chiamate API del sistema operativo. Per altre informazioni, vedere il post di blog relativo all’anteprima di System.IO in .NET Core 2.1.

Versione introdotta

.NET Core 2.1

Se il codice si basa su queste API per verificare la presenza di caratteri non validi, è possibile aggiungere una chiamata a Path.GetInvalidPathChars.

API interessate

Vedi anche

Campi privati aggiunti ai tipi di struct predefiniti

I campi privati sono stati aggiunti a determinati tipi di struct negli assembly di riferimento. Di conseguenza, in C#, questi tipi di struct devono sempre essere creati in un'istanza usando il nuovo operatore o il valore letterale predefinito.

Descrizione delle modifiche

In .NET Core 2.0 e versioni precedenti alcuni tipi di struct forniti, ad esempio ConsoleKeyInfo, possono essere creati in istanze senza usare l'operatore new o il valore letterale predefinito in C#. Ciò è dovuto al fatto che gli assembly di riferimento usati dal compilatore C# non contengono i campi privati per gli struct. Tutti i campi privati per i tipi di struct .NET vengono aggiunti agli assembly di riferimento a partire da .NET Core 2.1.

Ad esempio, il codice C# seguente viene compilato in .NET Core 2.0, ma non in .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

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

In .NET Core 2.1 il codice precedente genera l'errore del compilatore seguente: CS0165 - Uso della variabile locale non assegnata 'key'

Versione introdotta

2.1

Crea un'istanza dei tipi di struct usando l'operatore new o il valore letterale predefinito.

Ad esempio:

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

Category

Principali librerie .NET

API interessate

Modifica nel valore predefinito di UseShellExecute

ProcessStartInfo.UseShellExecute ha un valore predefinito di false in .NET Core. In .NET Framework il valore predefinito è true.

Descrizione delle modifiche

Process.Start consente di avviare direttamente un'applicazione, ad esempio con codice come Process.Start("mspaint.exe") che avvia Paint. Consente anche di avviare indirettamente un'applicazione associata se la proprietà ProcessStartInfo.UseShellExecute è impostata su true. In .NET Framework il valore predefinito per ProcessStartInfo.UseShellExecute è true, ovvero codice come Process.Start("mytextfile.txt") avvia Blocco note, se sono stati associati file con estensione txt a tale editor. Per impedire l'avvio indiretto di un'app in .NET Framework, è necessario impostare in modo esplicito ProcessStartInfo.UseShellExecute su false. In .NET Core il valore predefinito per ProcessStartInfo.UseShellExecute è false. Ciò significa che, per impostazione predefinita, le applicazioni associate non vengono avviate quando si chiama Process.Start.

Le proprietà seguenti in System.Diagnostics.ProcessStartInfo funzionano solo quando ProcessStartInfo.UseShellExecute è true:

Questa modifica è stata introdotta in .NET Core per motivi di prestazioni. In genere, Process.Start viene usato per avviare direttamente un'applicazione. L'avvio diretto di un'app non deve necessariamente coinvolgere la shell di Windows e comportare il costo delle prestazioni associato. Per velocizzare questo caso predefinito, .NET Core modifica il valore predefinito di ProcessStartInfo.UseShellExecute in false. Se necessario, è possibile acconsentire esplicitamente al percorso più lento.

Versione introdotta

2.1

Nota

Nelle versioni precedenti di .NET Core UseShellExecute non è stato implementato per Windows.

Se l'app si basa sul comportamento precedente, chiama Process.Start(ProcessStartInfo) con UseShellExecute impostato su true nell'oggetto ProcessStartInfo.

Category

Principali librerie .NET

API interessate

Versioni di OpenSSL in macOS

I runtime di .NET Core 3.0 e versioni successive in macOS ora preferiscono le versioni openSSL 1.1.x alle versioni OpenSSL 1.0.x per i tipi AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSsl, RSAOpenSsl e SafeEvpPKeyHandle.

Il runtime di .NET Core 2.1 supporta ora le versioni OpenSSL 1.1.x, ma preferisce comunque le versioni di OpenSSL 1.0.x.

Descrizione delle modifiche

In precedenza, il runtime di .NET Core usava le versioni openSSL 1.0.x in macOS per i tipi che interagiscono con OpenSSL. La versione più recente di OpenSSL 1.0.x, OpenSSL 1.0.2, è ora non supportata. Per mantenere i tipi che usano OpenSSL nelle versioni supportate di OpenSSL, i runtime di .NET Core 3.0 e versioni successive ora usano le versioni più recenti di OpenSSL in macOS.

Con questa modifica, il comportamento per i runtime di .NET Core in macOS è il seguente:

  • I runtime di .NET Core 3.0 e versioni successive usano OpenSSL 1.1.x, se disponibile, ed eseguono il fallback a OpenSSL 1.0.x solo se non è disponibile alcuna versione 1.1.x.

    Per i chiamanti che usano i tipi di interoperabilità OpenSSL con P/Invoke personalizzati, segui le indicazioni riportate nelle note SafeEvpPKeyHandle.OpenSslVersion. L'app potrebbe arrestarsi in modo anomalo se non si controlla il valore OpenSslVersion.

  • Il runtime di .NET Core 2.1 usa OpenSSL 1.0.x, se disponibile, ed esegue il fallback a OpenSSL 1.1.x se non è disponibile alcuna versione 1.0.x.

    Il runtime 2.1 preferisce la versione precedente di OpenSSL perché la proprietà SafeEvpPKeyHandle.OpenSslVersion non esiste in .NET Core 2.1, pertanto la versione OpenSSL non può essere determinata in modo affidabile in fase di esecuzione.

Versione introdotta

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

Category

Principali librerie .NET

API interessate

.NET Core 1.0

UnauthorizedAccessException generata da FileSystemInfo.Attributes

In .NET Core viene generata una UnauthorizedAccessException quando il chiamante prova a impostare un valore di attributo di file ma non ha l'autorizzazione di scrittura.

Descrizione delle modifiche

In .NET Framework viene generata una ArgumentException quando il chiamante prova ai impostare un valore dell'attributo di file in FileSystemInfo.Attributes ma non ha l'autorizzazione di scrittura. In .NET Core viene invece generata una UnauthorizedAccessException. In .NET Core viene comunque generata una ArgumentException se il chiamante prova a impostare un attributo di file non valido.

Versione introdotta

1.0

Modifica qualsiasi istruzione catch per intercettare una UnauthorizedAccessException invece di o in aggiunta a ArgumentException, in base alle esigenze.

Category

Principali librerie .NET

API interessate

La gestione delle eccezioni con stato danneggiato non è supportata

La gestione delle eccezioni con stato danneggiato del processo in .NET Core non è supportata.

Descrizione delle modifiche

In precedenza le eccezioni con stato danneggiato del processo potevano essere rilevate e gestite dai gestori di eccezioni del codice gestito, ad esempio usando un'istruzione try-catch in C#.

A partire da .NET Core 1.0, le eccezioni con stato danneggiato del processo non possono essere gestite dal codice gestito. Common Language Runtime non recapita eccezioni con stato danneggiato del processo al codice gestito.

Versione introdotta

1.0

Evita la necessità di gestire eccezioni con stato danneggiato del processo risolvendo invece le situazioni che provocano tali eccezioni. Se è assolutamente necessario gestire eccezioni con stato danneggiato del processo, scrivi il gestore di eccezioni nel codice C o C++.

Category

Principali librerie .NET

API interessate

Le proprietà UriBuilder non antepongono più caratteri iniziali

UriBuilder.Fragment non antepone più un carattere # iniziale e UriBuilder.Query non antepone più un carattere ? iniziale quando ne è già presente uno.

Descrizione delle modifiche

In .NET Framework le proprietà UriBuilder.Fragment e UriBuilder.Query anteponevano sempre rispettivamente un carattere # o ? al valore archiviato. Questo comportamento può comportare più caratteri # o ? nel valore archiviato se la stringa contiene già uno di questi caratteri iniziali. Ad esempio, il valore di UriBuilder.Fragment potrebbe diventare ##main.

A partire da .NET Core 1.0, queste proprietà non antepongono più i caratteri # o ? al valore archiviato se ne è già presente uno all'inizio della stringa.

Versione introdotta

1.0

Non è più necessario rimuovere in modo esplicito uno di questi caratteri iniziali quando si impostano i valori delle proprietà. Ciò è particolarmente utile quando si aggiungono valori, perché non è più necessario rimuovere il carattere iniziale # o ? ogni volta che si esegue l'aggiunta.

Il frammento di codice seguente ad esempio mostra la differenza di comportamento tra .NET Framework e .NET Core.

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

Console.WriteLine(builder.Query);
  • In .NET Framework l'output è ????one=1&two=2&three=3&four=4.
  • In .NET Core l'output è ?one=1&two=2&three=3&four=4.

Category

Principali librerie .NET

API interessate

Process.StartInfo genera InvalidOperationException per i processi non avviati dall'utente

La lettura della proprietà Process.StartInfo per i processi che il codice non ha avviato genera una InvalidOperationException.

Descrizione delle modifiche

In .NET Framework l'accesso alla proprietà Process.StartInfo per i processi che il codice non ha avviato restituisce un oggetto ProcessStartInfo fittizio. L'oggetto fittizio contiene valori predefiniti per tutte le relative proprietà, ad eccezione di EnvironmentVariables.

A partire da .NET Core 1.0, se si legge la proprietà Process.StartInfo per un processo che non è stato avviato dall'utente, ovvero chiamando Process.Start, viene generata una InvalidOperationException.

Versione introdotta

1.0

Non accedere alla proprietà Process.StartInfo per i processi non avviati dal codice. Non leggere ad esempio questa proprietà per i processi restituiti da Process.GetProcesses.

Category

Principali librerie .NET

API interessate