Modifiche che causano un'interruzione per la migrazione da .NET Framework a .NET Core

  • Articolo

Se si esegue la migrazione di un'app da .NET Framework a .NET Core versioni da 1.0 a 3.1, è possibile che si sia interessati dalle modifiche che causano un'interruzione elencate in questo articolo. Le modifiche che causano un'interruzione sono raggruppate per categoria e all'interno di tali categorie in base alla versione di .NET Core in cui sono state introdotte.

Nota

Questo articolo non è un elenco completo delle modifiche che causano un'interruzione tra .NET Framework e .NET Core. Le modifiche che causano un'interruzione più importanti vengono aggiunte qui man mano che vengono rese note.

Principali librerie .NET

.NET 8

L'API IDispatchImplAttribute viene rimossa

.NET Core 2.1

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

.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

Crittografia

.NET Core 2.1

Il parametro booleano di SignedCms.ComputeSignature viene rispettato

In .NET Core viene rispettato il parametro silent booleano del metodo SignedCms.ComputeSignature(CmsSigner, Boolean). Un prompt del PIN non viene visualizzato se questo parametro è impostato su true.

Descrizione delle modifiche

In .NET Framework il parametro silent del metodo SignedCms.ComputeSignature(CmsSigner, Boolean) viene ignorato e un prompt del PIN viene sempre visualizzato se richiesto dal provider. In .NET Core il parametro silent viene rispettato e, se impostato su true, non viene mai visualizzato un prompt del PIN, anche se richiesto dal provider.

Il supporto per i messaggi CMS/PKCS #7 è stato introdotto in .NET Core nella versione 2.1.

Versione di introduzione

2.1

Per assicurarsi che venga visualizzato un prompt del PIN, se necessario, le applicazioni desktop devono chiamare SignedCms.ComputeSignature(CmsSigner, Boolean) e impostare il parametro booleano su false. Il comportamento risultante è uguale a quello rilevato in .NET Framework, indipendentemente dal fatto che il contesto invisibile all'utente sia disabilitato in .NET Framework.

Category

Crittografia

API interessate

MSBuild

.NET Core 3.0

Modifica del nome file manifesto della risorsa

A partire da .NET Core 3.0, nel caso predefinito MSBuild genera un nome file manifesto diverso per i file di risorse.

Versione di introduzione

3,0

Descrizione delle modifiche

Prima di .NET Core 3.0, se non venivano specificati metadati per LogicalName, ManifestResourceName o DependentUpon per un elemento EmbeddedResource nel file di progetto, MSBuild generava un nome file manifesto nel modello <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Se RootNamespace non è definito nel file di progetto, per impostazione predefinita viene impostato sul nome del progetto. Ad esempio, il nome del manifesto generato per un file di risorse denominato Form1.resx nella directory del progetto radice era MyProject.Form1.resources.

A partire da .NET Core 3.0, se un file di risorse condivide il percorso con un file di origine con lo stesso nome, ad esempio, Form1.resx e Form1.cs, MSBuild usa le informazioni sul tipo dal file di origine per generare il nome file manifesto nel modello <Namespace>.<ClassName>.resources. Lo spazio dei nomi e il nome della classe vengono estratti dal primo tipo nel file di origine con percorso condiviso. Ad esempio, il nome del manifesto generato per un file di risorse denominato Form1.resx che condivide il percorso con un file di origine denominato Form1.cs è MyNamespace.Form1.resources. L'aspetto principale da notare è che la prima parte del nome file è diversa dalle versioni precedenti di .NET Core, ovvero MyNamespace anziché MyProject.

Nota

Se nel file di progetto sono stati specificati metadati per LogicalName, ManifestResourceName o DependentUpon in un elemento EmbeddedResource, questa modifica non influisce sul file di risorse.

Questa modifica che causa un'interruzione è stata introdotta con l'aggiunta della proprietà EmbeddedResourceUseDependentUponConvention ai progetti .NET Core. Per impostazione predefinita, i file di risorse non sono elencati in modo esplicito in un file di progetto di .NET Core, pertanto non hanno metadati DependentUpon per specificare come assegnare un nome al file con estensione resources generato. Quando EmbeddedResourceUseDependentUponConvention è impostato su true, ovvero l'impostazione predefinita, MSBuild cerca un file di origine con percorso condiviso ed estrae uno spazio dei nomi e un nome di classe da tale file. Se si imposta EmbeddedResourceUseDependentUponConvention su false, MSBuild genera il nome del manifesto in base al comportamento precedente, che combina RootNamespace e il percorso del file relativo.

Nella maggior parte dei casi non è necessaria alcuna azione da parte dello sviluppatore e l'app dovrebbe continuare a funzionare. Se tuttavia questa modifica causa interruzioni nell'app, è possibile:

  • Modificare il codice in modo da prevedere il nuovo nome del manifesto.

  • Rifiutare esplicitamente la nuova convenzione di denominazione impostando EmbeddedResourceUseDependentUponConvention su false nel file di progetto.

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Category

MSBuild

API interessate

N/D

Rete

.NET Core 2.0

WebClient.CancelAsync non sempre annulla immediatamente

A partire da .NET Core 2.0, la chiamata WebClient.CancelAsync() non annulla immediatamente la richiesta se la risposta ha iniziato a recuperare.

Descrizione delle modifiche

In precedenza, la chiamata WebClient.CancelAsync() annullava immediatamente la richiesta. A partire da .NET Core 2.0, la chiamata WebClient.CancelAsync() annulla immediatamente la richiesta solo se la risposta non ha avviato il recupero. Se la risposta ha iniziato a recuperare, la richiesta viene annullata solo dopo la lettura di una risposta completa.

Questa modifica è stata implementata perché l'API WebClient è deprecata a favore di HttpClient.

Versione introdotta

2.0

Usare la classe System.Net.Http.HttpClient anziché System.Net.WebClient, che è deprecata.

Category

Rete

API interessate

WinForms

Il supporto di Windows Forms è stato aggiunto a .NET Core nella versione 3.0. Se si esegue la migrazione di un'app Windows Forms da .NET Framework a .NET Core, le modifiche che causano un'interruzione elencate di seguito potrebbero influire sull'app.

.NET Core 3.1

Controlli rimossi

A partire da .NET Core 3.1, alcuni controlli di Windows Forms non sono più disponibili.

Descrizione delle modifiche

A partire da .NET Core 3.1, diversi controlli di Windows Forms non sono più disponibili. I controlli sostitutivi con progettazione e supporto migliori sono stati introdotti in .NET Framework 2.0. I controlli deprecati sono stati rimossi in precedenza dalle caselle degli strumenti della finestra di progettazione, ma erano ancora disponibili per l'uso.

I tipi seguenti non sono più disponibili:

Versione di introduzione

3.1

Ogni controllo rimosso ha un controllo sostitutivo consigliato. Fare riferimento alla tabella seguente:

Controllo rimosso (API) Sostituzione consigliata API associate che vengono rimosse
ContextMenu ContextMenuStrip
DataGrid DataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Menu ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
MenuItem ToolStripMenuItem
ToolBar ToolStrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Category

WinForms

API interessate

Evento CellFormatting non generato se viene visualizzata la descrizione comando

Una classe DataGridView mostra ora il testo e le descrizioni comando di errore di una cella quando si passa il mouse sopra la cella e in caso di selezione tramite la tastiera. Se viene visualizzata una descrizione comando, l'evento DataGridView.CellFormatting non viene generato.

Descrizione delle modifiche

Prima di .NET Core 3.1, una classe DataGridView con la proprietà ShowCellToolTips impostata su true mostrava una descrizione comando per il testo e gli errori di una cella quando si passava il mouse sopra la cella. Le descrizioni comando non venivano visualizzate quando una cella veniva selezionata tramite la tastiera, ad esempio usando il tasto TAB, i tasti di scelta rapida o lo spostamento con la freccia. Se l'utente modificava una cella e quindi, mentre la classe DataGridView era ancora in modalità di modifica, passava il mouse sopra una cella per cui non era stata impostata la proprietà ToolTipText, veniva generato un evento CellFormatting per formattare il testo della cella per la visualizzazione nella cella.

Per soddisfare gli standard di accessibilità, a partire da .NET Core 3.1, una classe DataGridView con la proprietà ShowCellToolTips impostata su true mostra le descrizioni comando per il testo e gli errori di una cella non solo quando si passa il mouse sopra la cella , ma anche quando la cella viene selezionata tramite la tastiera. In seguito a questa modifica, l'evento CellFormattingnon viene generato quando si passa il mouse sopra le celle per cui non è stata impostata la proprietà ToolTipText mentre DataGridView è in modalità di modifica. L'evento non viene generato perché il contenuto della cella su cui si passa il mouse viene visualizzato come descrizione comando anziché essere visualizzato nella cella.

Versione di introduzione

3.1

Effettuare il refactoring di qualsiasi codice che dipende dall'evento CellFormatting mentre DataGridView è in modalità di modifica.

Category

WinForms

API interessate

None

.NET Core 3.0

Il tipo di carattere del controllo predefinito è stato modificato in Segoe UI 9 pt

Descrizione delle modifiche

In .NET Framework la proprietà Control.DefaultFont è stata impostata su Microsoft Sans Serif 8 pt. L'immagine seguente mostra una finestra che usa il tipo di carattere predefinito.

Default control font in .NET Framework

A partire da .NET Core 3.0, il tipo di carattere predefinito è impostato su Segoe UI 9 pt, ovvero lo stesso tipo di carattere di SystemFonts.MessageBoxFont. In seguito a questa modifica, le dimensioni di moduli e controlli sono circa il 27% più grandi per tenere conto delle dimensioni maggiori del nuovo tipo di carattere predefinito. Ad esempio:

Default control font in .NET Core

Questa modifica è stata apportata per allinearsi alle Linee guida dell'esperienza utente di Windows.

Versione di introduzione

3,0

A causa della modifica delle dimensioni dei moduli e dei controlli, assicurarsi che il rendering dell'applicazione venga eseguito correttamente.

Per mantenere il tipo di carattere originale, impostare il tipo di carattere predefinito del modulo su Microsoft Sans Serif 8 pt. Ad esempio:

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

Category

  • WinForms

API interessate

Nessuno.

Modernizzazione di FolderBrowserDialog

Il controllo FolderBrowserDialog è stato modificato nelle applicazioni Windows Forms per .NET Core.

Descrizione delle modifiche

Windows Forms in .NET Framework usa la finestra di dialogo seguente per il controllo FolderBrowserDialog:

The FolderBrowserDialogControl in the .NET Framework

Windows Forms in .NET Core 3.0 usa un controllo basato su COM più recente, introdotto in Windows Vista:

The FolderBrowserDialogControl in the .NET Core

Versione di introduzione

3,0

La finestra di dialogo verrà aggiornata automaticamente.

Se si vuole mantenere la finestra di dialogo originale, impostare la proprietà FolderBrowserDialog.AutoUpgradeEnabled su false prima di visualizzare la finestra di dialogo, come illustrato dal frammento di codice seguente:

var dialog = new FolderBrowserDialog();
dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();

Category

WinForms

API interessate

Classe SerializableAttribute rimossa da alcuni tipi di Windows Forms

La classeSerializableAttribute è stata rimossa da alcune classi di Windows Forms che non hanno scenari di serializzazione binaria noti.

Descrizione delle modifiche

I tipi seguenti sono decorati con la classe SerializableAttribute in .NET Framework, ma l'attributo è stato rimosso in .NET Core:

Storicamente questo meccanismo di serializzazione ha comportato gravi problemi di manutenzione e sicurezza. La gestione di SerializableAttribute sui tipi significa che questi tipi devono essere testati per le modifiche di serializzazione da versione a versione e potenzialmente per le modifiche alla serializzazione da framework a framework. Risulta quindi più difficile evolvere tali tipi e la gestione può essere costosa. Questi tipi non hanno scenari di serializzazione binaria noti e ciò riduce al minimo l'impatto della rimozione dell'attributo.

Per altre informazioni, vedere Serializzazione binaria.

Versione di introduzione

3,0

Aggiornare qualsiasi codice che può dipendere da questi tipi contrassegnati come serializzabili.

Category

WinForms

API interessate

  • None

Opzione di compatibilità AllowUpdateChildControlIndexForTabControls non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls è supportata in Windows Forms in .NET Framework 4.6 e versioni successive, ma non è supportata in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

In .NET Framework 4.6 e versioni successive la selezione di una scheda riordina la raccolta di controlli. L'opzione di compatibilità Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls consente a un'applicazione di ignorare questo riordinamento quando questo comportamento è indesiderato.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls non è supportata.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

  • None

Opzione di compatibilità DomainUpDown.UseLegacyScrolling non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling, introdotta in .NET Framework 4.7.1, non è supportata in Windows Forms in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

A partire da .NET Framework 4.7.1, l'opzione di compatibilità Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling consente agli sviluppatori di rifiutare esplicitamente le azioni indipendenti DomainUpDown.DownButton() e DomainUpDown.UpButton(). L'opzione ha ripristinato il comportamento legacy, in cui il metodo DomainUpDown.UpButton() viene ignorato se il testo del contesto è presente e lo sviluppatore deve usare l'azione DomainUpDown.DownButton() sul controllo prima dell'azione DomainUpDown.UpButton(). Per altre informazioni, vedere Elemento <AppContextSwitchOverrides>.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling non è supportata.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

Opzione di compatibilità DoNotLoadLatestRichEditControl non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.UseLegacyImages, introdotta in .NET Framework 4.7.1, non è supportata in Windows Forms in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

In .NET Framework 4.6.2 e versioni precedenti il controllo RichTextBox crea un'istanza del controllo RichEdit Win32 v3.0 e per le applicazioni destinate a .NET Framework 4.7.1 il controllo RichTextBox crea un'istanza di RichEdit v4.1 (in msftedit.dll). L'opzione di compatibilità Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl è stata introdotta per consentire alle applicazioni destinate a .NET Framework 4.7.1 e versioni successive di rifiutare esplicitamente il nuovo controllo RichEdit v4.1 e usare invece il controllo RichEdit v3 precedente.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl non è supportata. Sono supportate solo le nuove versioni del controllo RichTextBox.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

Opzione di compatibilità DoNotSupportSelectAllShortcutInMultilineTextBox non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox, introdotta in .NET Framework 4.6.1, non è supportata in Windows Forms in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

A partire da .NET Framework 4.6.1, la selezione della combinazione di tasti CTRL + A in un controllo TextBox consente di selezionare tutto il testo. In .NET Framework 4.6 e versioni precedenti la selezione della combinazione di tasti CTRL + A non consentiva di selezionare tutto il testo se le proprietà Textbox.ShortcutsEnabled e TextBox.Multiline erano impostate su true. L'opzione di compatibilità Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox è stata introdotta in .NET Framework 4.6.1 per mantenere il comportamento originale. Per altre informazioni, vedere TextBox.ProcessCmdKey.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox non è supportata.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

  • None

Opzione di compatibilità DontSupportReentrantFilterMessage non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.DontSupportReentrantFilterMessage, introdotta in .NET Framework 4.6.1, non è supportata in Windows Forms in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

A partire da .NET Framework 4.6.1, l'opzione di compatibilità Switch.System.Windows.Forms.DontSupportReentrantFilterMessage risolve possibili eccezioni IndexOutOfRangeException quando viene chiamato il messaggio Application.FilterMessage con un'implementazione IMessageFilter.PreFilterMessage personalizzata. Per altre informazioni, vedere Mitigazione: Implementazioni IMessageFilter.PreFilterMessage personalizzate.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.DontSupportReentrantFilterMessage non è supportata.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

Opzione di compatibilità EnableVisualStyleValidation non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.EnableVisualStyleValidation non è supportata in Windows Forms in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

In .NET Framework l'opzione di compatibilità Switch.System.Windows.Forms.EnableVisualStyleValidation consentiva a un'applicazione di rifiutare esplicitamente la convalida degli stili di visualizzazione forniti in un formato numerico.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.EnableVisualStyleValidation non è supportata.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

  • None

Opzione di compatibilità UseLegacyContextMenuStripSourceControlValue non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue, introdotta in .NET Framework 4.7.2, non è supportata in Windows Forms in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

A partire da .NET Framework 4.7.2, l'opzione di compatibilità Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue consente allo sviluppatore di rifiutare esplicitamente il nuovo comportamento della proprietà ContextMenuStrip.SourceControl, che ora restituisce un riferimento al controllo del codice sorgente. Il comportamento precedente della proprietà consisteva nel restituire null. Per altre informazioni, vedere Elemento <AppContextSwitchOverrides>.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue non è supportata.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

Opzione di compatibilità UseLegacyImages non supportata

L'opzione di compatibilità Switch.System.Windows.Forms.UseLegacyImages, introdotta in .NET Framework 4.8, non è supportata in Windows Forms in .NET Core o .NET 5.0 e versioni successive.

Descrizione delle modifiche

A partire da .NET Framework 4.8, l'opzione di compatibilità Switch.System.Windows.Forms.UseLegacyImages ha risolto i possibili problemi di ridimensionamento delle immagini negli scenari ClickOnce in ambienti con valori DPI elevati. Se impostata su true, l'opzione consente all'utente di ripristinare il ridimensionamento delle immagini legacy su schermi DPI elevati la cui scala è impostata su maggiore del 100%. Per altre informazioni, vedere le Note sulla versione di .NET Framework 4.8 su GitHub.

In .NET Core e .NET 5.0 e versioni successive l'opzione Switch.System.Windows.Forms.UseLegacyImages non è supportata.

Versione di introduzione

3,0

Rimuovere l'opzione. L'opzione non è supportata e non è disponibile alcuna funzionalità alternativa.

Category

WinForms

API interessate

  • None

I modelli About e SplashScreen presentano interruzioni

I file About.vb e SplashScreen.vb generati da Visual Studio contengono riferimenti a tipi nello spazio dei nomi My che non sono disponibili .NET Core 3.0 e 3.1.

Versione di introduzione

3,0

Descrizione delle modifiche

.NET Core 3.0 e 3.1 non contengono il supporto My completo di Visual Basic. I modelli di modulo About e SplashScreen in Visual Studio per le app di Windows Forms per Visual Basic fanno riferimento a proprietà nel tipo My.Application.Info che non sono disponibili.

Il supporto My di Visual Basic è stato migliorato in .NET 5. Aggiornare il progetto a .NET 5 o versione successiva.

-o-

Correggere gli errori del compilatore nei tipi About e SplashScreen nell'app. Usare la classe System.Reflection.Assembly per ottenere le informazioni fornite dal tipo My.Application.Info. Qui è disponibile una semplice conversione di entrambi i moduli.

Suggerimento

Si tratta di codice di esempio e non ottimizzato. L'elenco degli attributi deve essere memorizzato nella cache per ridurre il tempo di caricamento dei moduli.

Informazioni su

Imports System.Reflection

Public NotInheritable Class About

    Private Sub about_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ' Set the title of the form.
        Dim applicationTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(applicationTitle) Then
            applicationTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        Me.Text = String.Format("About {0}", applicationTitle)
        ' Initialize all of the text displayed on the About Box.
        ' TODO: Customize the application's assembly information in the "Application" pane of the project
        '    properties dialog (under the "Project" menu).
        Me.LabelProductName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyProductAttribute)()?.Product, "")
        Me.LabelVersion.Text = String.Format("Version {0}", Assembly.GetExecutingAssembly().GetName().Version)
        Me.LabelCopyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
        Me.LabelCompanyName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCompanyAttribute)()?.Company, "")
        Me.TextBoxDescription.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyDescriptionAttribute)()?.Description, "")
    End Sub

    Private Sub OKButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles OKButton.Click
        Me.Close()
    End Sub

End Class

SplashScreen

Imports System.Reflection

Public NotInheritable Class SplashScreen

    Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        'Set up the dialog text at runtime according to the application's assembly information.  

        'TODO: Customize the application's assembly information in the "Application" pane of the project
        '  properties dialog (under the "Project" menu).

        'Application title
        Dim appTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(appTitle) Then
            appTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        ApplicationTitle.Text = appTitle

        Dim versionValue = Assembly.GetExecutingAssembly().GetName().Version

        'Format the version information using the text set into the Version control at design time as the
        '  formatting string.  This allows for effective localization if desired.
        '  Build and revision information could be included by using the following code and changing the
        '  Version control's designtime text to "Version {0}.{1:00}.{2}.{3}" or something similar.  See
        '  String.Format() in Help for more information.
        '
        '    Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor, versionValue.Build, versionValue.Revision)

        Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor)

        'Copyright info
        Copyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
    End Sub

End Class

Category

Windows Forms per Visual Basic

API interessate

None

Tipi nello spazio dei nomi Microsoft.VisualBasic.ApplicationServices non disponibili

I tipi nello spazio dei nomi Microsoft.VisualBasic.ApplicationServices non sono disponibili.

Versione di introduzione

.NET Core 3.0

Descrizione delle modifiche

I tipi nello spazio dei nomi Microsoft.VisualBasic.ApplicationServices erano disponibili in .NET Framework. Non sono disponibili in .NET Core 3.0 - 3.1.

I tipi sono stati rimossi per evitare dipendenze di assembly non necessarie o modifiche che causano un'interruzione nelle versioni successive.

Questo spazio dei nomi è stato aggiunto in .NET 5. Aggiornare il progetto a .NET 5 o versione successiva.

-o-

Se il codice dipende dall'uso dei tipi Microsoft.VisualBasic.ApplicationServices e dei relativi membri, è possibile usare un tipo o un membro corrispondente nella libreria di classi .NET. Alcuni membri System.Environment e System.Security.Principal.WindowsIdentity forniscono ad esempio funzionalità equivalenti alle proprietà della classe Microsoft.VisualBasic.ApplicationServices.User.

Category

Visual Basic

API interessate

Tipi nello spazio dei nomi Microsoft.VisualBasic.Devices non disponibili

I tipi nello spazio dei nomi Microsoft.VisualBasic.Devices non sono disponibili.

Versione di introduzione

.NET Core 3.0

Descrizione delle modifiche

I tipi nello spazio dei nomi Microsoft.VisualBasic.Devices erano disponibili in .NET Framework. Non sono disponibili in .NET Core 3.0 - 3.1.

I tipi sono stati rimossi per evitare dipendenze di assembly non necessarie o modifiche che causano un'interruzione nelle versioni successive.

Questo spazio dei nomi è stato aggiunto in .NET 5. Aggiornare il progetto a .NET 5 o versione successiva.

-o-

Se il codice dipende dall'uso dei tipi Microsoft.VisualBasic.Devices e dei relativi membri, è possibile usare un tipo o un membro corrispondente nella libreria di classi .NET. La funzionalità equivalente alla classe Microsoft.VisualBasic.Devices.Clock viene ad esempio fornita dai tipi System.DateTime e System.Environment, e la funzionalità equivalente alla classe Microsoft.VisualBasic.Devices.Ports viene fornita dai tipi nello spazio dei nomi System.IO.Ports.

Category

Visual Basic

API interessate

Tipi nello spazio dei nomi Microsoft.VisualBasic.MyServices non disponibili

I tipi nello spazio dei nomi Microsoft.VisualBasic.MyServices non sono disponibili.

Versione di introduzione

.NET Core 3.0

Descrizione delle modifiche

I tipi nello spazio dei nomi Microsoft.VisualBasic.MyServices erano disponibili in .NET Framework. Non sono disponibili in .NET Core 3.0 - 3.1.

I tipi sono stati rimossi per evitare dipendenze di assembly non necessarie o modifiche che causano un'interruzione nelle versioni successive.

Questo spazio dei nomi è stato aggiunto in .NET 5. Aggiornare il progetto a .NET 5 o versione successiva.

-o-

Se il codice dipende dall'uso dei tipi Microsoft.VisualBasic.MyServices e dei relativi membri, nella libreria di classi .NET sono presenti tipi e membri corrispondenti. Di seguito è riportato un mapping dei tipi di Microsoft.VisualBasic.MyServices ai tipi di libreria di classi .NET equivalenti:

Tipo di Microsoft.VisualBasic.MyServices Tipo di libreria di classi .NET
ClipboardProxy System.Windows.Clipboard per applicazioni WPF, System.Windows.Forms.Clipboard per le applicazioni Windows Forms
FileSystemProxy Tipi nello spazio dei nomi System.IO
RegistryProxy Tipi correlati al registro nello spazio dei nomi Microsoft.Win32
SpecialDirectoriesProxy Environment.GetFolderPath

Category

Visual Basic

API interessate

Vedi anche