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

Article
05/01/2024

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 changements cassants sont regroupés par catégorie, puis par la version de .NET Core dans laquelle ils ont été introduits.

Notes

Cet article n’est pas une liste complète des changements cassants entre le .NET Framework et .NET Core. Les principaux changements cassants sont ajoutés ici au fur et à mesure.

Bibliothèques .NET Core

Modification de la valeur par défaut de UseShellExecute
API IDispatchImplAttribute est supprimée
UnauthorizedAccessException levé par FileSystemInfo.Attributes
La gestion des exceptions d’état de processus altéré n’est pas prise en charge
Les propriétés UriBuilder ne précèdent plus les caractères de début
Process.StartInfo lève une exception InvalidOperationException pour des processus que vous n’avez pas démarrés

.NET 8

API IDispatchImplAttribute est supprimée

.NET Core 2.1

Modification de la valeur par défaut de UseShellExecute

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

Description de la modification

Process.Start permet de lancer une application directement, par exemple avec du code comme Process.Start("mspaint.exe") qui lance l’application Paint. Cela 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 comme Process.Start("mytextfile.txt") lance le Bloc-notes si vous avez associé des fichiers .txt à cet éditeur. Pour empêcher indirectement le lancement d’une application sur .NET Framework, vous devez définir explicitement ProcessStartInfo.UseShellExecute 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 quand vous appelez Process.Start.

Les propriétés suivantes sur System.Diagnostics.ProcessStartInfo sont fonctionnelles uniquement quand ProcessStartInfo.UseShellExecute est défini sur 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 d’une application directement n’a pas besoin d’impliquer l’interpréteur de commandes Windows ni d’entraîner le coût de performances associé. Pour accélérer ce cas par défaut, .NET Core modifie la valeur par défaut en remplaçant ProcessStartInfo.UseShellExecute par false. Vous pouvez choisir le chemin plus lent si nécessaire.

Version introduite

2.1

Notes

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

Action recommandée

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

Category

Bibliothèques .NET Core

API affectées

.NET Core 1.0

UnauthorizedAccessException levé par FileSystemInfo.Attributes

Dans .NET Core, une exception UnauthorizedAccessException est levée quand l’appelant tente de définir une valeur d’attribut de fichier sans disposer de l’autorisation d’accès en écriture.

Description de la modification

Dans .NET Framework, une exception ArgumentException est levée quand l’appelant tente de définir une valeur d’attribut de fichier dans FileSystemInfo.Attributes sans disposer de l’autorisation d’accès en écriture. Dans .NET Core, une exception UnauthorizedAccessException est levée à la place. (Dans .NET Core, une exception ArgumentException est toujours levée si l’appelant tente de définir un attribut de fichier non valide.)

Version introduite

1.0

Action recommandée

Modifiez toutes les instructions catch pour intercepter une exception UnauthorizedAccessException au lieu de, ou en plus de ArgumentException, si nécessaire.

Category

Bibliothèques .NET Core

API affectées

FileSystemInfo.Attributes

La gestion des exceptions état altéré n’est pas prise en charge

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

Description de la modification

Auparavant, les exceptions d’état de processus altéré 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 altéré ne peuvent pas être gérées par du code managé. Le Common Language Runtime ne fournit pas d’exceptions d’état de processus altéré au code managé.

Version introduite

1.0

Action recommandée

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

Category

Bibliothèques .NET Core

API affectées

Les propriétés UriBuilder ne précèdent plus les caractères de début

UriBuilder.Fragment ne précède plus un caractère de début # et UriBuilder.Query ne précède plus un caractère de début ? le cas échéant.

Description de la modification

Dans .NET Framework, les propriétés UriBuilder.Fragment et UriBuilder.Query ajoutent toujours un # caractère ou ? respectivement à la valeur stockée. Ce comportement peut entraîner des caractères # ou ? multiples 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 n’ajoutent plus les caractères # ni ? à la valeur stockée si celle-ci est déjà présente au début de la chaîne.

Version introduite

1.0

Action recommandée

Il n’est plus nécessaire de supprimer explicitement l’un de ces caractères de début quand vous définissez les valeurs de propriété. Cela s’avère particulièrement utile quand vous ajoutez des valeurs, car il n’est plus nécessaire de supprimer le caractère de début # ni ? à chaque fois.

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 une exception InvalidOperationException pour des processus que vous n’avez pas démarrés

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

Description de la modification

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

À compter de .NET Core 1.0, si vous lisez la propriété Process.StartInfo d’un processus que vous n’avez pas démarré (c’est-à-dire en appelant Process.Start), une exception InvalidOperationException est levée.

Version introduite

1.0

Action recommandée

N’accédez pas à la propriété Process.StartInfo 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

System.Diagnostics.Process.StartInfo

Chiffrement

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

.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 méthode SignedCms.ComputeSignature(CmsSigner, Boolean) est respecté. Une invite à entrer un PIN ne s’affiche pas si ce paramètre est défini sur true.

Description de la modification

Dans .NET Framework, le paramètre silent de la méthode SignedCms.ComputeSignature(CmsSigner, Boolean) est ignoré et une invite à entrer un PIN s’affiche toujours si le fournisseur l’exige. Dans .NET Core, le paramètre silent est respecté et, s’il est défini sur true, une invite à entrer un PIN ne s’affiche jamais, même si le fournisseur l’exige.

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

Version introduite

2.1

Action recommandée

Pour vérifier qu’une invite à entrer un PIN 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 obtenu est le même que sur .NET Framework, que le contexte silencieux y soit désactivé ou non.

Category

Chiffrement

API affectées

SignedCms.ComputeSignature(CmsSigner, Boolean)

MSBuild

Modification du nom du fichier manifeste de ressource

.NET Core 3.0

Modification du nom du fichier manifeste de ressource

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

Version introduite

3.0

Description de la modification

Avant .NET Core 3.0, si aucune métadonnées LogicalName, ManifestResourceName ou DependentUpon avaient été spécifiées pour un élément EmbeddedResource dans le fichier projet, MSBuild générait un nom de fichier manifeste dans le modèle <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Si RootNamespace n’est pas défini dans le fichier projet, il est défini par défaut sur le nom du projet. Par exemple, le nom du manifeste généré pour un fichier de ressources nommé Form1.resx dans le répertoire du 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 des informations 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 classe sont extraits du premier type dans le fichier source colocalisé. Par exemple, le nom du 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 principale chose à 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 des métadonnées LogicalName, ManifestResourceName ou DependentUpon spécifiées sur un élément EmbeddedResource dans le fichier projet, ce changement n’affecte pas ce fichier de ressources.

Ce changement cassant a été introduit avec l’ajout de la propriété EmbeddedResourceUseDependentUponConvention aux projets .NET Core. Par défaut, les fichiers de ressources ne sont pas répertoriés explicitement dans un fichier projet .NET Core. Ils n’ont donc aucune métadonnées DependentUpon pour spécifier comment nommer le fichier .resources généré. Quand 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 à partir 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.

Action recommandée

Dans la plupart des cas, aucune action n’est requise de la part du développeur et votre application devrait continuer à fonctionner. Toutefois, si ce changement arrête votre application, vous pouvez :

Modifier votre code pour avoir un nouveau nom de manifeste.
Refuser la nouvelle convention d’affectation de noms 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

WebClient.CancelAsync n’annule pas toujours immédiatement

.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 la demande immédiatement si la récupération (fetch) de la réponse a commencé.

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 la demande immédiatement uniquement si la récupération (fetch) de la réponse n’a pas commencé. Si la récupération (fetch) de la réponse a commencé, la demande est annulée uniquement une fois que la réponse complète est lue.

Cette modification a été implémentée, car l’API WebClient est déconseillée au profit de HttpClient.

Version introduite

2.0

Action recommandée

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

Category

Mise en réseau

API affectées

System.Net.WebClient.CancelAsync()

Windows Forms

La prise en charge de Windows Forms 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 changements cassants répertoriés ici peuvent affecter votre application.

Contrôles supprimés
Événement CellFormatting non déclenché si l’info-bulle est affichée
Control.DefaultFont remplacé par Segoe UI 9 pt
Modernisation de FolderBrowserDialog
SerializableAttribute supprimé dans certains types Windows Forms
Commutateur de compatibilité AllowUpdateChildControlIndexForTabControls non pris en charge
Commutateur de compatibilité DomainUpDown.UseLegacyScrolling non pris en charge
Commutateur de compatibilité DoNotLoadLatestRichEditControl non pris en charge
Commutateur de compatibilité DoNotSupportSelectAllShortcutInMultilineTextBox non pris en charge
Commutateur de compatibilité DontSupportReentrantFilterMessage non pris en charge
Commutateur de compatibilité EnableVisualStyleValidation non pris en charge
Commutateur de compatibilité UseLegacyContextMenuStripSourceControlValue non pris en charge
Commutateur de compatibilité UseLegacyImages non pris en charge
À propos et les modèles SplashScreen sont rompus pour Visual Basic
Types dans l’espace de noms Microsoft.VisualBasic.ApplicationServices non disponibles
Types dans l’espace de noms Microsoft.VisualBasic.Devices non disponibles
Types dans l’espace de noms Microsoft.VisualBasic.MyServices non disponibles

.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, plusieurs contrôles Windows Forms ne sont plus disponibles. Des contrôles de remplacement qui présentent 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é supprimés auparavant des boîtes à outils du concepteur, mais il était toujours possible de les utiliser.

Les types suivants ne sont plus disponibles :

Version introduite

3.1

Action recommandée

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

Suppression du contrôle (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

DataGridView affiche désormais le texte et les info-bulles d’erreur quand l’utilisateur place le curseur sur une cellule ou 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, une DataGridView dont la propriété ShowCellToolTips était définie sur true affichait une info-bulle pour le texte et les erreurs d’une cellule quand l’utilisateur plaçait le curseur dessus. Les info-bulles ne s’affichaient pas quand une cellule était sélectionnée via le clavier (par exemple à l’aide de la touche de tabulation, de touches de raccourci ou de la navigation avec les flèches). Si l’utilisateur a modifié une cellule, puis, alors que DataGridView était encore en mode d’édition, placé le curseur sur une cellule dont la propriété ToolTipText n’était pas définie, un événement CellFormatting a été déclenché pour mettre en forme le texte de la cellule pour l’affichage dans la cellule.

Pour répondre aux normes d’accessibilité, à compter de .NET Core 3.1, une DataGridView dont la propriété ShowCellToolTips est définie sur true affiche les info-bulles pour le texte et les erreurs d’une cellule non seulement quand l’utilisateur place le curseur sur une cellule, mais également lorsqu’elle est sélectionnée via le clavier. En raison de cette modification, l’événement CellFormatting n’est pas déclenché quand l’utilisateur place le curseur sur les cellules dont la propriété ToolTipText n’est pas définie alors que DataGridView est en mode d’édition. L’événement n’est pas déclenché, car l’utilisateur place le curseur sur une cellule dont le contenu est affiché sous la forme d’une info-bulle au lieu d’être affiché dans la cellule.

Version introduite

3.1

Action recommandée

Refactorisez tout code qui dépend de l’événement CellFormatting alors que 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 propriété Control.DefaultFont était définie sur Microsoft Sans Serif 8.25 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 (police identique à SystemFonts.MessageBoxFont). En raison de ce changement, les formulaires et les contrôles sont agrandis d’environ 27 % 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 instructions relatives à l’expérience utilisateur (UX) Windows.

Version introduite

3.0

Action recommandée

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’un formulaire unique, définissez sa police par défaut sur Microsoft Sans Serif 8.25 pt. Par exemple :

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

Vous pouvez également modifier la police par défaut d’une application entière de l’une des manières suivantes :

En définissant la propriété MSBuild ApplicationDefaultFont sur « Microsoft Sans Serif, 8.25 pt ». Il s’agit de la technique préférée, car elle permet à Visual Studio d’utiliser les nouveaux paramètres dans le concepteur.
```
<PropertyGroup>
  <ApplicationDefaultFont>Microsoft Sans Serif, 8.25pt</ApplicationDefaultFont>
</PropertyGroup>
```

En appelant Application.SetDefaultFont(Font).

class Program
{
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.SetHighDpiMode(HighDpiMode.SystemAware);
        Application.SetDefaultFont(new Font(new FontFamily("Microsoft Sans Serif"), 8.25f));
        Application.Run(new Form1());
    }
}

Catégorie

Windows Forms

API affectées

Aucun.

Modernisation de FolderBrowserDialog

Le contrôle FolderBrowserDialog a été modifié dans les applications Windows Forms pour .NET Core.

Description de la modification

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

FolderBrowserDialogControl dans .NET Framework

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

FolderBrowserDialogControl dans .NET Core

Version introduite

3.0

Action recommandée

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

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

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

Category

Windows Forms

API affectées

FolderBrowserDialog

SerializableAttribute supprimé dans certains types Windows Forms

Le fichier SerializableAttribute a été supprimé dans certaines classes Windows Forms qui ne dispose d’aucun scénario de sérialisation binaire connu.

Description de la modification

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

System.InvariantComparer
System.ComponentModel.Design.ExceptionCollection
System.ComponentModel.Design.Serialization.CodeDomSerializerException
System.ComponentModel.Design.Serialization.CodeDomComponentSerializationService.CodeDomSerializationStore
System.Drawing.Design.ToolboxItem
System.Resources.ResXNullRef
System.Resources.ResXDataNode
System.Resources.ResXFileRef
System.Windows.Forms.Cursor
System.Windows.Forms.NativeMethods.MSOCRINFOSTRUCT
System.Windows.Forms.NativeMethods.MSG

Historiquement, ce mécanisme de sérialisation a rencontré 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 éventuellement pour les modifications de sérialisation de framework à framework. Le développement de ces types est donc plus difficile et sa maintenance peut être coûteuse. Ces types ne disposent d’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

Action recommandée

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

Category

Windows Forms

API affectées

None

Commutateur de compatibilité AllowUpdateChildControlIndexForTabControls non pris en charge

Le commutateur de compatibilité Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls est pris en charge dans Windows Forms sur .NET Framework 4.6 et versions ultérieures, mais il n’est pas pris en charge sur .NET Core ni .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 commutateur de compatibilité Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls permet à une application d’ignorer cette réorganisation quand ce comportement n’est pas souhaitable.

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

Version introduite

3.0

Action recommandée

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 commutateur de compatibilité Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling qui a été introduit dans .NET Framework 4.7.1 n’est pas pris en charge dans Windows Forms sur .NET Core ni .NET 5.0 et versions ultérieures.

Description de la modification

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

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

Version introduite

3.0

Action recommandée

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

Category

Windows Forms

None

Les modèles About et SplashScreen sont rompus

Les fichiers About.vb et SplashScreen.vb générés par Visual Studio contiennent des références aux types dans l’espace de noms My qui ne sont pas disponibles dans .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 support complet de Visual Basic My. Les modèles de formulaires À propos et SplashScreen dans les applications Visual Studio pour Visual Basic Windows Forms font référence aux propriétés du type My.Application.Info qui ne sont pas disponibles.

Action recommandée

Le support de Visual Basic My a été amélioré dans .NET 5, mettez à niveau votre projet vers .NET 5 ou version ultérieure.

-ou-

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

Conseil

Il s’agit d’exemples de code non optimisés. 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

Visual Basic Windows Forms

API affectées

None

Types dans l’espace de noms Microsoft.VisualBasic.ApplicationServices non disponibles

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

Version introduite

.NET Core 3.0

Description de la modification

Les types de l’espace de noms Microsoft.VisualBasic.ApplicationServices é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.

Action recommandée

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 Microsoft.VisualBasic.ApplicationServices et de leurs membres, vous pouvez peut-être utiliser un type ou un membre correspondant dans la bibliothèque de classes .NET. Par exemple, certains membres System.Environment et System.Security.Principal.WindowsIdentity fournissent des fonctionnalités équivalentes aux propriétés de la classe Microsoft.VisualBasic.ApplicationServices.User.

Category

Visual Basic

API affectées

Microsoft.VisualBasic.ApplicationServices

Types dans l’espace de noms Microsoft.VisualBasic.Devices non disponibles

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

Version introduite

.NET Core 3.0

Description de la modification

Les types de l’espace de noms Microsoft.VisualBasic.Devices é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.

Action recommandée

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 Microsoft.VisualBasic.Devices et de leurs membres, vous pouvez peut-être utiliser un type ou un membre correspondant dans la bibliothèque de classes .NET. Par exemple, des fonctionnalités équivalentes à la classe Microsoft.VisualBasic.Devices.Clock sont fournies par les types System.DateTime et System.Environment et les fonctionnalités équivalentes à la classe Microsoft.VisualBasic.Devices.Ports sont fournies par les types dans l’espace de noms System.IO.Ports.

Category

Visual Basic

API affectées

Microsoft.VisualBasic.Devices

Types dans l’espace de noms Microsoft.VisualBasic.MyServices non disponibles

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

Version introduite

.NET Core 3.0

Description de la modification

Les types de l’espace de noms Microsoft.VisualBasic.MyServices é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.

Action recommandée

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 des types Microsoft.VisualBasic.MyServices et de leurs membres, il existe des types et des membres correspondants dans la bibliothèque de classes .NET. Voici un mappage des types Microsoft.VisualBasic.MyServices à leurs types de bibliothèque de classes .NET équivalents :

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

Partager via

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

Bibliothèques .NET Core

.NET 8

.NET Core 2.1

Modification de la valeur par défaut de UseShellExecute

Description de la modification

Version introduite

Action recommandée

Category

API affectées

.NET Core 1.0

UnauthorizedAccessException levé par FileSystemInfo.Attributes

Description de la modification

Version introduite

Action recommandée

Category

API affectées

La gestion des exceptions état altéré n’est pas prise en charge

Description de la modification

Version introduite

Action recommandée

Category

API affectées

Les propriétés UriBuilder ne précèdent plus les caractères de début

Description de la modification

Version introduite

Action recommandée

Category

API affectées

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

Description de la modification

Version introduite

Action recommandée

Category

API affectées

Chiffrement

.NET Core 2.1

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

Description de la modification

Version introduite

Action recommandée

Category

API affectées

MSBuild

.NET Core 3.0

Modification du nom du fichier manifeste de ressource

Version introduite

Description de la modification

Action recommandée

Category

API affectées

Mise en réseau

.NET Core 2.0

WebClient.CancelAsync n’annule pas toujours immédiatement

Description de la modification

Version introduite

Action recommandée

Category

API affectées

Windows Forms

.NET Core 3.1

Contrôles supprimés

Description de la modification

Version introduite

Action recommandée

Category

API affectées

Événement CellFormatting non déclenché si l’info-bulle est affichée

Description de la modification

Version introduite

Action recommandée

Category

API affectées

.NET Core 3.0

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

Description de la modification

Version introduite

Action recommandée

Catégorie