Changements cassants pour la migration de .NET Framework vers .NET Core

  • Article
  • 25 minutes de lecture

Si vous migrez une application de .NET Framework vers .NET Core versions 1.0 à 3.1, les changements cassants répertoriés dans cet article peuvent vous affecter. Les modifications cassants sont regroupées par catégorie, et dans ces catégories, par la version de .NET Core dans laquelle elles ont été introduites.

Notes

Cet article n’est pas une liste complète des changements cassants entre le .NET Framework et .NET Core. Les changements cassants les plus importants sont ajoutés ici à mesure que nous en prenons connaissance.

Bibliothèques .NET Core

.NET Core 2.1

Modification de la valeur par défaut de UseShellExecute

ProcessStartInfo.UseShellExecute a la valeur false par défaut sur .NET Core. Sur .NET Framework, sa valeur par défaut est true.

Description de la modification

Process.Start vous permet de lancer une application directement, par exemple, avec du code tel Process.Start("mspaint.exe") que qui lance Paint. Il vous permet également de lancer indirectement une application associée si ProcessStartInfo.UseShellExecute est défini sur true. Sur .NET Framework, la valeur par défaut de ProcessStartInfo.UseShellExecute est true, ce qui signifie que le code tel que Process.Start("mytextfile.txt") lancerait le Bloc-notes, si vous avez associé .txt fichiers à cet éditeur. Pour empêcher le lancement indirect d’une application sur .NET Framework, vous devez définir ProcessStartInfo.UseShellExecute explicitement sur false. Sur .NET Core, la valeur par défaut de ProcessStartInfo.UseShellExecute est false. Cela signifie que, par défaut, les applications associées ne sont pas lancées lorsque vous appelez Process.Start.

Les propriétés suivantes sur System.Diagnostics.ProcessStartInfo ne sont fonctionnelles que lorsque ProcessStartInfo.UseShellExecute est true:

Cette modification a été introduite dans .NET Core pour des raisons de performances. En règle générale, Process.Start est utilisé pour lancer une application directement. Le lancement direct d’une application n’a pas besoin d’impliquer l’interpréteur de commandes Windows et entraîne le coût de performances associé. Pour accélérer ce cas par défaut, .NET Core modifie la valeur par défaut de ProcessStartInfo.UseShellExecute en false. Vous pouvez choisir le chemin lent si vous en avez besoin.

Version introduite

2.1

Notes

Dans les versions antérieures de .NET Core, UseShellExecute n’a pas été implémenté pour Windows.

Si votre application s’appuie sur l’ancien comportement, appelez Process.Start(ProcessStartInfo) avec UseShellExecute défini true sur sur l’objet ProcessStartInfo .

Category

Bibliothèques .NET Core

API affectées

.NET Core 1.0

UnauthorizedAccessException levée par FileSystemInfo.Attributes

Dans .NET Core, une UnauthorizedAccessException valeur est levée lorsque l’appelant tente de définir une valeur d’attribut de fichier, mais n’a pas d’autorisation d’écriture.

Description de la modification

Dans .NET Framework, une ArgumentException est levée lorsque l’appelant tente de définir une valeur d’attribut de fichier dans FileSystemInfo.Attributes , mais ne dispose pas de l’autorisation d’écriture. Dans .NET Core, un UnauthorizedAccessException est levée à la place. (Dans .NET Core, un ArgumentException est toujours levée si l’appelant tente de définir un attribut de fichier non valide.)

Version introduite

1.0

Modifiez les catch instructions pour intercepter un UnauthorizedAccessException au lieu ou en plus d’un ArgumentException, si nécessaire.

Category

Bibliothèques .NET Core

API affectées

La gestion des exceptions d’état endommagé n’est pas prise en charge

La gestion des exceptions d’état de processus endommagés dans .NET Core n’est pas prise en charge.

Description de la modification

Auparavant, les exceptions d’état de processus endommagés pouvaient être interceptées et gérées par des gestionnaires d’exceptions de code managé, par exemple à l’aide d’une instruction try-catch en C#.

À compter de .NET Core 1.0, les exceptions d’état de processus endommagés ne peuvent pas être gérées par du code managé. Le Common Language Runtime ne fournit pas d’exceptions d’état de processus endommagés au code managé.

Version introduite

1.0

Évitez d’avoir à gérer les exceptions d’état de processus endommagés en traitant plutôt les situations qui y mènent. S’il est absolument nécessaire de gérer les exceptions d’état de processus endommagés, écrivez le gestionnaire d’exceptions en code C ou C++.

Category

Bibliothèques .NET Core

API affectées

Les propriétés UriBuilder ne sont plus ajoutées aux caractères de début

UriBuilder.Fragment n’ajoute plus un caractère de début # et UriBuilder.Query n’ajoute plus un caractère de début ? lorsqu’un caractère est déjà présent.

Description de la modification

Dans .NET Framework, les UriBuilder.Fragment propriétés et UriBuilder.Query ont toujours ajouté un # caractère ou ? , respectivement, à la valeur stockée. Ce comportement peut entraîner plusieurs #? ou caractères dans la valeur stockée si la chaîne contient déjà l’un de ces caractères de début. Par exemple, la valeur de UriBuilder.Fragment peut devenir ##main.

À compter de .NET Core 1.0, ces propriétés ne prédéfinis plus les # caractères ou ? à la valeur stockée s’ils sont déjà présents au début de la chaîne.

Version introduite

1.0

Vous n’avez plus besoin de supprimer explicitement ces caractères de début lors de la définition des valeurs de propriété. Cela est particulièrement utile lorsque vous ajoutez des valeurs, car vous n’avez plus besoin de supprimer le début # ou ? chaque fois que vous ajoutez.

Par exemple, l’extrait de code suivant montre la différence de comportement entre .NET Framework et .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);
  • Dans .NET Framework, la sortie est ????one=1&two=2&three=3&four=4.
  • Dans .NET Core, la sortie est ?one=1&two=2&three=3&four=4.

Category

Bibliothèques .NET Core

API affectées

Process.StartInfo lève InvalidOperationException pour les processus que vous n’avez pas démarrés

La lecture de la Process.StartInfo propriété pour les processus que votre code n’a pas démarré lève un InvalidOperationException.

Description de la modification

Dans .NET Framework, l’accès à la Process.StartInfo propriété pour les processus que votre code n’a pas démarré renvoie un objet factice ProcessStartInfo . L’objet factice contient des valeurs par défaut pour toutes ses propriétés à l’exception EnvironmentVariablesde .

À partir de .NET Core 1.0, si vous lisez la Process.StartInfo propriété d’un processus que vous n’avez pas démarré (autrement dit, en appelant Process.Start), une InvalidOperationException est levée.

Version introduite

1.0

N’accédez pas à la Process.StartInfo propriété pour les processus que votre code n’a pas démarrés. Par exemple, ne lisez pas cette propriété pour les processus retournés par Process.GetProcesses.

Category

Bibliothèques .NET Core

API affectées

Chiffrement

.NET Core 2.1

Le paramètre booléen de SignedCms.ComputeSignature est respecté

Dans .NET Core, le paramètre booléen silent de la SignedCms.ComputeSignature(CmsSigner, Boolean) méthode est respecté. Une invite de code confidentiel n’est pas affichée si ce paramètre a la valeur true.

Description de la modification

Dans .NET Framework, le silent paramètre de la SignedCms.ComputeSignature(CmsSigner, Boolean) méthode est ignoré et une invite de code confidentiel s’affiche toujours si nécessaire par le fournisseur. Dans .NET Core, le silent paramètre est respecté et, s’il est défini sur true, une invite de code confidentiel n’est jamais affichée, même si elle est requise par le fournisseur.

La prise en charge des messages CMS/PKCS #7 a été introduite dans .NET Core dans la version 2.1.

Version introduite

2.1

Pour vous assurer qu’une invite de code confidentiel s’affiche si nécessaire, les applications de bureau doivent appeler SignedCms.ComputeSignature(CmsSigner, Boolean) et définir le paramètre booléen sur false. Le comportement résultant est le même que sur .NET Framework, que le contexte silencieux y soit ou non désactivé.

Category

Chiffrement

API affectées

MSBuild

.NET Core 3.0

Changement de nom du fichier manifeste de ressource

À compter de .NET Core 3.0, dans le cas par défaut, MSBuild génère un nom de fichier manifeste différent pour les fichiers de ressources.

Version introduite

3.0

Description de la modification

Avant .NET Core 3.0, si aucune métadonnées , ManifestResourceNameou n’a LogicalNameété spécifiée pour un EmbeddedResource élément dans le fichier projet, MSBuild a généré un nom de fichier manifeste dans le modèle <RootNamespace>.<ResourceFilePathFromProjectRoot>.resourcesDependentUpon . Si RootNamespace n’est pas défini dans le fichier projet, le nom du projet est défini par défaut. Par exemple, le nom de manifeste généré pour un fichier de ressources nommé Form1.resx dans le répertoire de projet racine était MyProject.Form1.resources.

À compter de .NET Core 3.0, si un fichier de ressources est colocalisé avec un fichier source du même nom (par exemple, Form1.resx et Form1.cs), MSBuild utilise les informations de type du fichier source pour générer le nom du fichier manifeste dans le modèle <Namespace>.<ClassName>.resources. L’espace de noms et le nom de la classe sont extraits du premier type dans le fichier source colocalisé. Par exemple, le nom de manifeste généré pour un fichier de ressources nommé Form1.resx colocalisé avec un fichier source nommé Form1.cs est MyNamespace.Form1.resources. La chose clé à noter est que la première partie du nom de fichier est différente des versions antérieures de .NET Core (MyNamespace au lieu de MyProject).

Notes

Si vous avez LogicalNamedes métadonnées , ManifestResourceNameou DependentUpon spécifiées sur un EmbeddedResource élément dans le fichier projet, cette modification n’affecte pas ce fichier de ressources.

Cette modification cassant a été introduite avec l’ajout de la EmbeddedResourceUseDependentUponConvention propriété aux projets .NET Core. Par défaut, les fichiers de ressources ne sont pas explicitement répertoriés dans un fichier projet .NET Core. Ils n’ont donc aucune DependentUpon métadonnées pour spécifier le nom du fichier .resources généré. Lorsque EmbeddedResourceUseDependentUponConvention est défini sur true, qui est la valeur par défaut, MSBuild recherche un fichier source colocalisé et extrait un espace de noms et un nom de classe de ce fichier. Si vous définissez EmbeddedResourceUseDependentUponConvention sur false, MSBuild génère le nom du manifeste en fonction du comportement précédent, qui combine RootNamespace et le chemin du fichier relatif.

Dans la plupart des cas, aucune action n’est requise de la part du développeur, et votre application doit continuer à fonctionner. Toutefois, si cette modification interrompt votre application, vous pouvez :

  • Modifiez votre code pour attendre le nouveau nom de manifeste.

  • Désactivez la nouvelle convention de nommage en définissant EmbeddedResourceUseDependentUponConvention sur false dans votre fichier projet.

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

Category

MSBuild

API affectées

N/A

Mise en réseau

.NET Core 2.0

WebClient.CancelAsync n’annule pas toujours immédiatement

À compter de .NET Core 2.0, l’appel WebClient.CancelAsync() n’annule pas immédiatement la demande si la réponse a commencé à être récupérée.

Description de la modification

Auparavant, l’appel WebClient.CancelAsync() annulait immédiatement la demande. À compter de .NET Core 2.0, l’appel WebClient.CancelAsync() annule immédiatement la demande uniquement si la réponse n’a pas commencé à être extraite. Si la réponse a commencé à être récupérée, la demande est annulée uniquement après la lecture d’une réponse complète.

Cette modification a été implémentée car l’API WebClient est déconseillée en faveur de HttpClient.

Version introduite

2.0

Utilisez la System.Net.Http.HttpClient classe au lieu de System.Net.WebClient, qui est déconseillée.

Category

Mise en réseau

API affectées

Windows Forms

Windows Forms prise en charge a été ajoutée à .NET Core dans la version 3.0. Si vous migrez une application Windows Forms de .NET Framework vers .NET Core, les modifications cassants répertoriées ici peuvent affecter votre application.

.NET Core 3.1

Contrôles supprimés

À compter de .NET Core 3.1, certains contrôles Windows Forms ne sont plus disponibles.

Description de la modification

À compter de .NET Core 3.1, les différents contrôles Windows Forms ne sont plus disponibles. Les contrôles de remplacement qui ont une meilleure conception et une meilleure prise en charge ont été introduits dans .NET Framework 2.0. Les contrôles déconseillés ont été précédemment supprimés des boîtes à outils du concepteur, mais ils étaient toujours disponibles pour être utilisés.

Les types suivants ne sont plus disponibles :

Version introduite

3.1

Chaque contrôle supprimé a un contrôle de remplacement recommandé. Reportez-vous au tableau suivant :

Contrôle supprimé (API) Remplacement recommandé API associées supprimées
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

Windows Forms

API affectées

L’événement CellFormatting n’est pas déclenché si l’info-bulle s’affiche

Un DataGridView affiche maintenant le texte et les info-bulles d’erreur d’une cellule lorsqu’elle est pointée par une souris et lorsqu’elle est sélectionnée via le clavier. Si une info-bulle est affichée, l’événement DataGridView.CellFormatting n’est pas déclenché.

Description de la modification

Avant .NET Core 3.1, un DataGridView qui avait la ShowCellToolTips propriété définie true sur affichait une info-bulle pour le texte d’une cellule et des erreurs lorsque la cellule était pointée par une souris. Les info-bulles n’étaient pas affichées lorsqu’une cellule était sélectionnée via le clavier (par exemple, à l’aide de la touche Tab, des touches de raccourci ou de la navigation dans les flèches). Si l’utilisateur a modifié une cellule, puis, alors que le DataGridView était toujours en mode édition, a pointé sur une cellule qui n’avait pas la ToolTipText propriété définie, un CellFormatting événement a été déclenché pour mettre en forme le texte de la cellule pour l’afficher dans la cellule.

Pour répondre aux normes d’accessibilité, à compter de .NET Core 3.1, un DataGridView dont la ShowCellToolTips propriété est définie true pour afficher des info-bulles pour le texte d’une cellule et des erreurs, non seulement lorsque la cellule est pointée, mais également lorsqu’elle est sélectionnée via le clavier. En conséquence de cette modification, l’événement CellFormattingn’est pas déclenché lorsque des cellules qui n’ont pas la ToolTipText propriété définie sont pointées alors que est DataGridView en mode édition. L’événement n’est pas déclenché, car le contenu de la cellule pointée est affiché sous la forme d’une info-bulle au lieu d’être affiché dans la cellule.

Version introduite

3.1

Refactorisez tout code qui dépend de l’événement CellFormatting alors que le DataGridView est en mode édition.

Category

Windows Forms

API affectées

None

.NET Core 3.0

Police de contrôle par défaut remplacée par Segoe UI 9 pt

Description de la modification

Dans .NET Framework, la Control.DefaultFont propriété a été définie sur Microsoft Sans Serif 8 pt. L’image suivante montre une fenêtre qui utilise la police par défaut.

Police de contrôle par défaut dans .NET Framework

À compter de .NET Core 3.0, la police par défaut est définie sur Segoe UI 9 pt (la même police que SystemFonts.MessageBoxFont). À la suite de cette modification, les formulaires et les contrôles sont dimensionnés d’environ 27 % plus grands pour tenir compte de la plus grande taille de la nouvelle police par défaut. Par exemple :

Police de contrôle par défaut dans .NET Core

Cette modification a été apportée pour s’aligner sur les recommandations relatives à l’expérience utilisateur Windows.

Version introduite

3.0

En raison de la modification de la taille des formulaires et des contrôles, assurez-vous que votre application s’affiche correctement.

Pour conserver la police d’origine, définissez la police par défaut de votre formulaire sur Microsoft Sans Serif 8 pt. Par exemple :

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

Category

  • Windows Forms

API affectées

Aucun.

Modernisation de FolderBrowserDialog

Le FolderBrowserDialog contrôle a changé dans Windows Forms applications pour .NET Core.

Description de la modification

Dans le .NET Framework, Windows Forms utilise la boîte de dialogue suivante pour le FolderBrowserDialog contrôle :

FolderBrowserDialogControl dans le .NET Framework

Dans .NET Core 3.0, Windows Forms utilise un contrôle COM plus récent qui a été introduit dans Windows Vista :

FolderBrowserDialogControl dans .NET Core

Version introduite

3.0

La boîte de dialogue sera mise à niveau automatiquement.

Si vous souhaitez conserver le dialogue d’origine, définissez la FolderBrowserDialog.AutoUpgradeEnabled propriété false sur avant d’afficher le dialogue, comme illustré par le fragment de code suivant :

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

Category

Windows Forms

API affectées

SerializableAttribute supprimé de certains types Windows Forms

Le SerializableAttribute a été supprimé de certaines classes Windows Forms qui n’ont aucun scénario de sérialisation binaire connu.

Description de la modification

Les types suivants sont décorés avec le SerializableAttribute dans .NET Framework, mais l’attribut a été supprimé dans .NET Core :

Historiquement, ce mécanisme de sérialisation a eu de graves problèmes de maintenance et de sécurité. La maintenance SerializableAttribute sur les types signifie que ces types doivent être testés pour les modifications de sérialisation de version à version et potentiellement les modifications de sérialisation d’infrastructure à infrastructure. Cela rend plus difficile l’évolution de ces types et peut être coûteux à maintenir. Ces types n’ont aucun scénario de sérialisation binaire connu, ce qui réduit l’impact de la suppression de l’attribut.

Pour plus d’informations, consultez Sérialisation binaire.

Version introduite

3.0

Mettez à jour tout code qui peut dépendre de ces types marqués comme sérialisables.

Category

Windows Forms

API affectées

  • None

Le commutateur de compatibilité AllowUpdateChildControlIndexForTabControls n’est pas pris en charge

Le Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls commutateur de compatibilité est pris en charge dans Windows Forms sur .NET Framework 4.6 et versions ultérieures, mais n’est pas pris en charge sur .NET Core ou .NET 5.0 et versions ultérieures.

Description de la modification

Dans .NET Framework 4.6 et versions ultérieures, la sélection d’un onglet réorganise sa collection de contrôles. Le Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls commutateur de compatibilité permet à une application d’ignorer cette réorganisation lorsque ce comportement n’est pas souhaitable.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls commutateur n’est pas pris en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

  • None

Commutateur de compatibilité DomainUpDown.UseLegacyScrolling non pris en charge

Le Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling commutateur de compatibilité, qui a été introduit dans .NET Framework 4.7.1, n’est pas pris en charge dans Windows Forms sur .NET Core ou .NET 5.0 et versions ultérieures.

Description de la modification

À compter de .NET Framework 4.7.1, le Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling commutateur de compatibilité a permis aux développeurs de refuser les actions et DomainUpDown.UpButton() indépendantesDomainUpDown.DownButton(). Le commutateur a restauré le comportement hérité, dans lequel est DomainUpDown.UpButton() ignoré si du texte contextuel est présent, et le développeur est tenu d’utiliser DomainUpDown.DownButton() l’action sur le contrôle avant l’action DomainUpDown.UpButton() . Pour plus d’informations, consultez <Élément AppContextSwitchOverrides>.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling commutateur n’est pas pris en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

Le commutateur de compatibilité DoNotLoadLatestRichEditControl n’est pas pris en charge

Le Switch.System.Windows.Forms.UseLegacyImages commutateur de compatibilité, qui a été introduit dans .NET Framework 4.7.1, n’est pas pris en charge dans Windows Forms sur .NET Core ou .NET 5.0 et versions ultérieures.

Description de la modification

Dans .NET Framework 4.6.2 et les versions antérieures, le RichTextBox contrôle instancie le contrôle Win32 RichEdit v3.0, et pour les applications qui ciblent .NET Framework 4.7.1, le RichTextBox contrôle instancie RichEdit v4.1 (dans msftedit.dll). Le Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl commutateur de compatibilité a été introduit pour permettre aux applications qui ciblent .NET Framework 4.7.1 et les versions ultérieures de refuser le nouveau contrôle RichEdit v4.1 et d’utiliser l’ancien contrôle RichEdit v3 à la place.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl commutateur n’est pas pris en charge. Seules les nouvelles versions du RichTextBox contrôle sont prises en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

Commutateur de compatibilité DoNotSupportSelectAllShortcutInMultilineTextBox non pris en charge

Le Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox commutateur de compatibilité, qui a été introduit dans .NET Framework 4.6.1, n’est pas pris en charge dans Windows Forms sur .NET Core et .NET 5.0 et versions ultérieures.

Description de la modification

À compter de .NET Framework 4.6.1, la sélection de la touche de raccourci Ctrl + A dans un TextBox contrôle a sélectionné tout le texte. Dans .NET Framework 4.6 et les versions antérieures, la sélection de la touche de raccourci Ctrl + A n’a pas pu sélectionner tout le texte si les propriétés Textbox.ShortcutsEnabled et TextBox.Multiline étaient toutes deux définies sur true. Le Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox commutateur de compatibilité a été introduit dans .NET Framework 4.6.1 pour conserver le comportement d’origine. Pour plus d'informations, consultez TextBox.ProcessCmdKey.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox commutateur n’est pas pris en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

  • None

Le commutateur de compatibilité DontSupportReentrantFilterMessage n’est pas pris en charge

Le Switch.System.Windows.Forms.DontSupportReentrantFilterMessage commutateur de compatibilité, qui a été introduit dans .NET Framework 4.6.1, n’est pas pris en charge dans Windows Forms sur .NET Core et .NET 5.0 et versions ultérieures.

Description de la modification

À compter de .NET Framework 4.6.1, le Switch.System.Windows.Forms.DontSupportReentrantFilterMessage commutateur de compatibilité traite les exceptions possibles IndexOutOfRangeException lorsque le Application.FilterMessage message est appelé avec une implémentation personnalisée IMessageFilter.PreFilterMessage . Pour plus d’informations, consultez Atténuation : implémentations IMessageFilter.PreFilterMessage personnalisées.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.DontSupportReentrantFilterMessage commutateur n’est pas pris en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

Le commutateur de compatibilité EnableVisualStyleValidation n’est pas pris en charge

Le Switch.System.Windows.Forms.EnableVisualStyleValidation commutateur de compatibilité n’est pas pris en charge dans Windows Forms sur .NET Core ou .NET 5.0 et versions ultérieures.

Description de la modification

Dans .NET Framework, le Switch.System.Windows.Forms.EnableVisualStyleValidation commutateur de compatibilité a permis à une application de refuser la validation des styles visuels fournis dans un formulaire numérique.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.EnableVisualStyleValidation commutateur n’est pas pris en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

  • None

Le commutateur de compatibilité UseLegacyContextMenuStripSourceControlValue n’est pas pris en charge

Le Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue commutateur de compatibilité, qui a été introduit dans .NET Framework 4.7.2, n’est pas pris en charge dans Windows Forms sur .NET Core ou .NET 5.0 et versions ultérieures.

Description de la modification

À compter de .NET Framework 4.7.2, le Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue commutateur de compatibilité permet au développeur de refuser le nouveau comportement de la ContextMenuStrip.SourceControl propriété, qui retourne désormais une référence au contrôle de code source. Le comportement précédent de la propriété consistait à retourner null. Pour plus d’informations, consultez <Élément AppContextSwitchOverrides>.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue commutateur n’est pas pris en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

Le commutateur de compatibilité UseLegacyImages n’est pas pris en charge

Le Switch.System.Windows.Forms.UseLegacyImages commutateur de compatibilité, qui a été introduit dans .NET Framework 4.8, n’est pas pris en charge dans Windows Forms sur .NET Core ou .NET 5.0 et versions ultérieures.

Description de la modification

À compter de .NET Framework 4.8, le Switch.System.Windows.Forms.UseLegacyImages commutateur de compatibilité a résolu les problèmes possibles de mise à l’échelle des images dans les scénarios ClickOnce dans les environnements à haute résolution. Lorsqu’il est défini sur true, le commutateur permet à l’utilisateur de restaurer la mise à l’échelle des images héritées sur des affichages à haute résolution dont l’échelle est définie sur plus de 100 %. Pour plus d’informations, consultez Notes de publication de .NET Framework 4.8 sur GitHub.

Dans .NET Core et .NET 5.0 et versions ultérieures, le Switch.System.Windows.Forms.UseLegacyImages commutateur n’est pas pris en charge.

Version introduite

3.0

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre fonctionnalité n’est disponible.

Category

Windows Forms

API affectées

  • None

À propos de et Les modèles SplashScreen sont rompus

Les About.vb fichiers et SplashScreen.vb générés par Visual Studio contiennent des références à des types dans l’espace My de noms qui ne sont pas disponibles .NET Core 3.0 et 3.1.

Version introduite

3.0

Description de la modification

.NET Core 3.0 et 3.1 ne contiennent pas de prise en charge complète de Visual Basic My . Les modèles de formulaire About et SplashScreen dans Visual Studio pour Visual Basic Windows Forms les propriétés des applications dans le My.Application.Info type qui ne sont pas disponibles.

La prise en charge de Visual Basic My a été améliorée dans .NET 5, mettez à niveau votre projet vers .NET 5 ou version ultérieure.

-ou-

Corrigez les erreurs du compilateur dans les types About et SplashScreen de votre application. Utilisez la System.Reflection.Assembly classe pour obtenir les informations fournies par le My.Application.Info type . Un port droit des deux formulaires est disponible ici.

Conseil

Il s’agit d’un exemple de code qui n’est pas optimisé. La liste des attributs doit être mise en cache pour réduire le temps de chargement du formulaire.

À propos de

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 Visual Basic

API affectées

None

Types dans Microsoft. Espace de noms VisualBasic.ApplicationServices non disponible

Les types dans l’espace de Microsoft.VisualBasic.ApplicationServices noms ne sont pas disponibles.

Version introduite

.NET Core 3.0

Description de la modification

Les types dans l’espace de Microsoft.VisualBasic.ApplicationServices noms étaient disponibles dans .NET Framework. Ils ne sont pas disponibles dans .NET Core 3.0 - 3.1.

Les types ont été supprimés pour éviter les dépendances d’assembly inutiles ou les changements cassants dans les versions suivantes.

Cet espace de noms a été ajouté dans .NET 5, mettez à niveau votre projet vers .NET 5 ou version ultérieure.

-ou-

Si votre code dépend de l’utilisation de types et de Microsoft.VisualBasic.ApplicationServices leurs membres, vous pouvez peut-être utiliser un type ou un membre correspondant dans la bibliothèque de classes .NET. Par exemple, certains System.Environment membres et System.Security.Principal.WindowsIdentity fournissent des fonctionnalités équivalentes aux propriétés de la Microsoft.VisualBasic.ApplicationServices.User classe .

Category

Visual Basic

API affectées

Types dans Microsoft. Espace de noms VisualBasic.Devices non disponible

Les types dans l’espace de Microsoft.VisualBasic.Devices noms ne sont pas disponibles.

Version introduite

.NET Core 3.0

Description de la modification

Les types dans l’espace de Microsoft.VisualBasic.Devices noms étaient disponibles dans .NET Framework. Ils ne sont pas disponibles dans .NET Core 3.0 - 3.1.

Les types ont été supprimés pour éviter les dépendances d’assembly inutiles ou les changements cassants dans les versions suivantes.

Cet espace de noms a été ajouté dans .NET 5, mettez à niveau votre projet vers .NET 5 ou version ultérieure.

-ou-

Si votre code dépend de l’utilisation de types et de Microsoft.VisualBasic.Devices leurs membres, vous pouvez peut-être utiliser un type ou un membre correspondant dans la bibliothèque de classes .NET. Par exemple, les fonctionnalités équivalentes à la Microsoft.VisualBasic.Devices.Clock classe sont fournies par les System.DateTime types et System.Environment , et les fonctionnalités équivalentes à la Microsoft.VisualBasic.Devices.Ports classe sont fournies par les types dans l’espace System.IO.Ports de noms .

Category

Visual Basic

API affectées

Types dans Microsoft. Espace de noms VisualBasic.MyServices non disponible

Les types dans l’espace de Microsoft.VisualBasic.MyServices noms ne sont pas disponibles.

Version introduite

.NET Core 3.0

Description de la modification

Les types dans l’espace de Microsoft.VisualBasic.MyServices noms étaient disponibles dans .NET Framework. Ils ne sont pas disponibles dans .NET Core 3.0 - 3.1.

Les types ont été supprimés pour éviter les dépendances d’assembly inutiles ou les changements cassants dans les versions suivantes.

Cet espace de noms a été ajouté dans .NET 5, mettez à niveau votre projet vers .NET 5 ou version ultérieure.

-ou-

Si votre code dépend de l’utilisation de Microsoft. Les types VisualBasic.MyServices et leurs membres, il existe des types et des membres correspondants dans la bibliothèque de classes .NET. Voici un mappage de Microsoft. Les types VisualBasic.MyServices à leurs types de bibliothèque de classes .NET équivalents :

Microsoft. Type VisualBasic.MyServices Type de bibliothèque de classes .NET
ClipboardProxy System.Windows.Clipboardpour les applications WPF, System.Windows.Forms.Clipboard pour les applications Windows Forms
FileSystemProxy Types dans l’espace de System.IO noms
RegistryProxy Types liés au Registre dans l’espace de Microsoft.Win32 noms
SpecialDirectoriesProxy Environment.GetFolderPath

Category

Visual Basic

API affectées

Voir aussi