AutoCAD et Revit 2025 et 2026 passent à .NET 10 : ce qui peut casser un complément écrit pour .NET 8

mercredi 4 novembre 2026

Microsoft arrête le support de .NET 8 et de .NET 9 le 10 novembre 2026. Or AutoCAD, Revit, Inventor et Civil 3D 2025 et 2026 tournent sur .NET 8. Autodesk a donc fait une chose qu'il ne faisait pas jusqu'ici : changer de runtime en cours de cycle, par une simple mise à jour, sans changer de version de produit. Autodesk la qualifie lui-même de « breaking update ».

Selon Autodesk, l'API ne change pas, seul le runtime passe de .NET 8 à .NET 10, et les compléments existants continuent de fonctionner, sauf s'ils butent sur un changement cassant de .NET 10. Côté Revit, le constat est le même : « la plupart des compléments continuent de fonctionner », avec une réserve pour ceux qui embarquent du code natif ou des bibliothèques tierces.

Le « sauf » mérite qu'on s'y arrête. Un complément compilé pour .NET 8 qui tourne désormais sur .NET 10 traverse deux séries de changements cassants : ceux de .NET 9 et ceux de .NET 10. Nous les avons passées en revue et n'avons gardé que ceux qui touchent plausiblement un complément de bureau. Les documents d'Autodesk et de Microsoft sur lesquels s'appuie cet article sont rassemblés à la fin, dans la section « Sources ».

Quelles mises à jour sont concernées

Produit	Ligne 2026	Ligne 2025
AutoCAD, ses verticaux, Civil 3D, Advance Steel	2026.1.2	2025.1.4
Revit	2026.5	2025.5
Inventor	2026.4	2025.5
Vault	2026.4	Sans objet

Autodesk prévoyait la ligne 2026 pour la première semaine d'août 2026 et la ligne 2025 pour la deuxième semaine de septembre 2026. Autodesk recommande d'installer ensemble les mises à jour de tous les produits d'une même année, parce qu'ils partagent des composants (RealDWG, Revit Core Engine, SDK Vault, objets Civil 3D, Plant 3D et Advance Steel).

Certains éditeurs de compléments conseillent d'attendre. Transoft, par exemple, recommande à ses utilisateurs d'AutoCAD et de Civil 3D 2025 et 2026 de rester sur leur version actuelle sans appliquer la mise à jour, tant que la validation de ses produits n'est pas terminée.

Les versions 2027, elles, sont déjà livrées en .NET 10 (voir AutoCAD 2027 est sorti).

Ce qui casse à l'exécution, sans recompiler

Ces changements touchent votre complément tel qu'il est installé : la DLL compilée pour .NET 8 n'a pas bougé, mais elle tourne désormais sur le runtime .NET 10 de l'hôte.

BinaryFormatter lève une exception, quel que soit le réglage

Symptôme. La commande qui sauvegarde ou relit des réglages, un presse-papiers maison ou un cache échoue. Nous avons appelé BinaryFormatter.Serialize depuis une bibliothèque compilée en net8, dans un processus .NET 10 :

System.PlatformNotSupportedException: BinaryFormatter serialization and deserialization have been removed. See https://aka.ms/binaryformatter for more information.

Cause. Depuis .NET 9, l'implémentation de BinaryFormatter fournie avec .NET lève une exception à chaque usage, « même avec les réglages qui l'autorisaient auparavant », et ces réglages ont disparu. La classe existe toujours, ce qui explique que le code compile et se charge : c'est son exécution qui échoue. Le cas est sournois sous Revit : le fichier RevitAPI.runtimeconfig.json de Revit 2025.5 déclare toujours "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": true. Sous .NET 8, ce réglage autorisait BinaryFormatter. Sous .NET 10, il n'a plus d'effet : nous avons obtenu l'exception ci-dessus avec ce même réglage à true.

Correction. Choisir un autre format de sérialisation et migrer le code. Si vos utilisateurs ont des fichiers déjà écrits dans ce format, prévoyez leur reprise : c'est souvent la partie la plus longue. Microsoft cite un paquet NuGet séparé qui fournit encore BinaryFormatter, mais il n'est pas pris en charge.

Conversions de réels en entiers : NaN donne 0, les valeurs hors limites sont saturées

Symptôme. Un calcul géométrique donne un résultat différent d'avant, sans aucune erreur : une coordonnée, un nombre de répétitions ou un index calculé à partir d'un double change de valeur.

Cause. Depuis .NET 9, sur x86 et x64, les conversions non vérifiées (hors contexte checked) d'un réel vers int, uint, long ou ulong sont saturantes : pour int, une valeur supérieure à int.MaxValue donne int.MaxValue, une valeur inférieure à int.MinValue donne int.MinValue, et NaN donne 0. Nous l'avons constaté pour un (int) sur un double : NaN donnait int.MinValue sous .NET 8 et donne 0 sous .NET 10. Un code qui convertissait un NaN ou une valeur hors limites sans le savoir obtient désormais un autre nombre. Les conversions dans les limites ne changent pas : 12,9 donne toujours 12.

Correction. Tester double.IsNaN et les bornes avant la conversion, et ne plus compter sur la valeur produite par une conversion hors limites. Ce changement ne concerne que la conversion directe : checked, Convert.ToInt32 ou CInt en VB.NET obéissent à d'autres règles.

WPF : un DynamicResource du mauvais type fait échouer la fenêtre

Symptôme. Une palette ou une boîte de dialogue WPF qui s'ouvrait avant ne s'ouvre plus. D'après Microsoft, l'erreur ressemble à System.Windows.Markup.XamlParseException: Set property 'System.Windows.ResourceDictionary.Source' threw an exception.

Cause. Une ressource de mauvais type référencée par {DynamicResource}, par exemple un SolidColorBrush à la place d'une Color. Microsoft signale qu'un DynamicResource mal typé peut désormais faire échouer le chargement du dictionnaire ou de la fenêtre, là où WPF se rabattait auparavant sur la valeur par défaut. Certains parcours échouaient déjà sous .NET 8 : l'effet dépend du contexte dans lequel la ressource est résolue.

Correction. Utiliser le bon type de ressource avec chaque DynamicResource, et ouvrir chaque fenêtre et chaque palette du complément dans un produit mis à jour.

System.Drawing : ExternalException au lieu d'OutOfMemoryException

Symptôme. Une opération sur une image (aperçu, vignette, logo de cartouche) qui échouait proprement, grâce à un catch (OutOfMemoryException), provoque maintenant une erreur non gérée.

Cause. Depuis .NET 10, quand GDI+ renvoie le statut Status.OutOfMemory, Bitmap, Graphics, Image et Icon lèvent une ExternalException au lieu d'une OutOfMemoryException. Un catch (OutOfMemoryException) ne l'intercepte plus. Toutes les erreurs d'image ne passent pas par ce chemin : des octets d'image invalides lèvent une ArgumentException, sous .NET 8 comme sous .NET 10.

Correction. Intercepter aussi ExternalException autour de ces appels.

XmlSerializer écrit les propriétés marquées [Obsolete]

Symptôme. Le fichier de réglages XML du complément contient des éléments qui n'y étaient pas. Ou bien, si une propriété porte [Obsolete] avec IsError à true, la création du sérialiseur échoue sur une InvalidOperationException (« There was an error reflecting type… »), dont l'exception interne indique Cannot serialize member '…' because it is marked with ObsoleteAttribute and IsError is set to true.

Cause. Jusqu'à .NET 9, XmlSerializer ignorait les propriétés marquées [Obsolete], comme si elles portaient [XmlIgnore]. Depuis .NET 10, il les sérialise, sauf si IsError vaut true.

Correction. Ajouter [XmlIgnore] aux propriétés obsolètes qui ne doivent pas être écrites. Microsoft propose aussi le commutateur AppContext.SetSwitch("Switch.System.Xml.IgnoreObsoleteMembers", true). Dans un complément, gardez à l'esprit qu'un commutateur AppContext vaut pour tout le processus, donc aussi pour les autres compléments chargés dans AutoCAD ou dans Revit.

DLL natives : DllImportSearchPath.AssemblyDirectory ne cherche plus ailleurs

Symptôme. DllNotFoundException au premier appel d'une fonction native, alors que la DLL est bien installée sur le poste, mais pas dans le dossier du complément.

Cause. Quand DllImportSearchPath.AssemblyDirectory est le seul drapeau indiqué, le runtime cherchait d'abord dans le dossier de l'assembly, puis suivait la recherche normale de Windows. Depuis .NET 10, avec ce drapeau seul, il ne cherche plus que dans le dossier de l'assembly. Cela vaut aussi pour NativeLibrary.Load et NativeLibrary.TryLoad. Un DllImport ordinaire, sans DllImportSearchPath, n'est pas concerné.

Correction. Livrer votre DLL native à côté du complément, ou ne pas spécifier de DllImportSearchPath si vous avez besoin de la recherche complète. Ne copiez pas pour autant les DLL système de Windows dans le dossier du complément.

Cryptographie et certificats

Ces changements touchent surtout le code de licence et de signature :

Depuis .NET 10, quand les paramètres de l'algorithme de clé sont absents, X509Certificate.GetKeyAlgorithmParameters() (un tableau d'octets), X509Certificate.GetKeyAlgorithmParametersString() (une chaîne) et PublicKey.EncodedParameters (un AsnEncodedData) peuvent renvoyer null au lieu d'une valeur vide. Le symptôme est une NullReferenceException dans le code qui lisait ces valeurs sans vérification. Il faut traiter le cas null.
Depuis .NET 9, pour un PFX importé sous Windows sans PersistKeySet ni EphemeralKeySet, la durée de vie de la clé privée suit l'instance directement chargée. Disposer un clone ne détruit plus prématurément la clé de l'original. Un code qui comptait sur cette suppression doit disposer l'original.

Pour la globalisation, la section consacrée de la liste des changements cassants de .NET 10 ne recense qu'un changement, propre à Linux.

Object Enabler en C++/CLI : le runtimeconfig.json épinglé sur .NET 8

C'est le seul cas qu'Autodesk cite nommément pour AutoCAD. Selon Autodesk, un Object Enabler écrit en C++/CLI avec du code managé, et qui livre encore un runtimeconfig.json épinglé sur .NET 8, ne peut pas fonctionner dans un AutoCAD passé en .NET 10. Autodesk recommande de reconstruire sa partie managée pour .NET 10. À défaut, la correction la plus simple consiste à supprimer ce runtimeconfig.json périmé, celui de l'Object Enabler. Cela ne concerne ni les autres fichiers runtimeconfig.json, ni les compléments écrits en C#.

Les dépendances partagées entre compléments

AutoCAD, Revit, Inventor et Vault chargent tous les compléments dans le même processus, à côté des composants d'Autodesk. Autodesk prévient que les compléments qui embarquent du code natif ou des bibliothèques tierces peuvent demander une recompilation et une mise à jour de leurs dépendances. Dans son annonce, Autodesk écrit que, « pour R2025.5 », DevExpress passe dans Vault de la version 22.2.12 à la 25.1.6, et qu'un développeur qui référence DevExpress directement peut vouloir s'aligner sur cette version.

Le même processus ne veut pas toujours dire le même contexte de chargement. Revit 2026 permet à un complément de s'isoler dans son propre contexte de chargement d'assemblies, avec l'option UseRevitContext à False dans son manifeste. Cette isolation est facultative : sans cette option, le complément partage le contexte de Revit et des autres compléments.

Ce qui casse à la recompilation

Le complément fonctionne, mais vous devez le modifier. Et la mise à jour a changé votre poste de développement.

Les DLL installées ne permettent plus de compiler en net8

Beaucoup de projets référencent directement acdbmgd.dll, accoremgd.dll, RevitAPI.dll ou RevitAPIUI.dll dans le dossier d'installation du produit. Une fois la mise à jour installée, ces DLL sont compilées pour .NET 10, et un projet qui cible net8.0-windows ne se construit plus. Voici ce que nous avons obtenu avec AutoCAD 2025 mis à jour :

error CS1705: Assembly 'accoremgd' with identity 'accoremgd, Version=25.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Runtime' with identity 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Avec Revit 2025.5, le message est le même pour RevitAPI et RevitAPIUI, en version 25.5.0.0.

Correction pour AutoCAD. Compiler contre le paquet NuGet officiel AutoCAD.NET plutôt que contre les DLL installées. Ce paquet publié par Autodesk existe en deux versions par produit :

Paquet	Produit	Cible
AutoCAD.NET 25.0.1	AutoCAD 2025	net8.0
AutoCAD.NET 25.0.2	AutoCAD 2025	net10.0
AutoCAD.NET 25.1.0	AutoCAD 2026	net8.0
AutoCAD.NET 25.1.1	AutoCAD 2026	net10.0

Attention au piège : une version flottante ou une mise à jour automatique des paquets vous fait passer en net10 sans prévenir. Dans un projet net8, la restauration échoue alors avec error NU1202: Package AutoCAD.NET 25.0.2 is not compatible with net8.0-windows7.0 (.NETCoreApp,Version=v8.0). Package AutoCAD.NET 25.0.2 supports: net10.0 (.NETCoreApp,Version=v10.0). Pour rester en net8, épinglez la version :

<ItemGroup>
  <PackageReference Include="AutoCAD.NET" Version="25.0.1" ExcludeAssets="runtime" />
</ItemGroup>

ExcludeAssets="runtime" évite de copier les DLL d'AutoCAD dans le dossier de sortie : c'est AutoCAD qui les fournit à l'exécution.

Correction pour Revit. Le principe est le même : il faut compiler contre des assemblies de référence de Revit 2025 ou 2026 compilées pour net8, comme celles d'une installation qui n'a pas encore reçu la mise à jour. Conservez-les avec le projet, ou dans un paquet NuGet interne que vous tenez vous-même : le paquet AutoCAD.NET n'a pas d'équivalent publié par Autodesk dans les sources consultées pour cet article.

Si vous passez votre projet en net10

Recibler en net10.0-windows fait apparaître d'autres changements, cette fois à la compilation :

WinForms et WPF dans le même projet. ContextMenu, DataGrid, DataGridCell, Menu, MenuItem, ToolBar et StatusBar deviennent ambigus quand le type est écrit sans qualification alors que les espaces de noms System.Windows.Controls et System.Windows.Forms sont tous deux en portée, par des using explicites ou implicites : error CS0104: 'ContextMenu' is an ambiguous reference between 'System.Windows.Controls.ContextMenu' and 'System.Windows.Forms.ContextMenu'. Activer UseWPF et UseWindowsForms ne suffit pas à provoquer l'erreur. Il faut lever l'ambiguïté par un alias using ou par le nom complet du type.
Grilles WPF vides. Un <Grid.ColumnDefinitions> ou un <Grid.RowDefinitions> vide ne compile plus : l'erreur MC3063: Property 'ColumnDefinitions' does not have a value. peut apparaître enveloppée dans une erreur MC1000. Il faut y laisser au moins une définition ou supprimer l'élément. Le changement touche la compilation du XAML.
Anciennes API WinForms. Form.OnClosing et Form.OnClosed (WFDEV004), Clipboard.GetData(string) (WFDEV005) et les anciens contrôles ContextMenu, MainMenu, DataGrid, StatusBar et ToolBar (WFDEV006) produisent désormais des avertissements. Ce ne sont que des avertissements, qui ne bloquent la construction que si les avertissements sont traités comme des erreurs (TreatWarningsAsErrors).
Audit NuGet des dépendances transitives. Pour un projet qui cible .NET 10, NuGet audite aussi les paquets transitifs. Si vous traitez les avertissements comme des erreurs, la restauration peut échouer sur NU1901 à NU1904. C'est une question de restauration et de politique d'avertissements : un complément net8 déjà compilé n'est pas concerné.
Constructeurs de certificats obsolètes. Les constructeurs de X509Certificate2 qui prennent un tableau d'octets ou un chemin, ainsi que X509Certificate2Collection.Import, produisent l'avertissement SYSLIB0057 à la compilation depuis .NET 9. Le code déjà compilé, lui, continue de s'exécuter.

Compiler en net8 pour couvrir 2025 et 2026 dans les deux états. Vos utilisateurs n'installeront pas tous la mise à jour le même jour : il y aura des AutoCAD et des Revit 2025 et 2026 encore en .NET 8, et d'autres passés en .NET 10. Un binaire compilé en net8 peut couvrir les deux états d'un même millésime, sous réserve des API et des dépendances qu'il utilise. Nous avons chargé un complément net8 dans un AutoCAD 2025 mis à jour : il se charge, et sa commande s'exécute sur le runtime 10.0.14. Autodesk annonce que les compléments existants continuent de fonctionner dans tous ses produits, Revit compris. L'inverse ne marche pas : une DLL compilée en net10, chargée dans un processus .NET 8 comme un AutoCAD ou un Revit qui n'a pas reçu la mise à jour, échoue faute de trouver System.Runtime, Version=10.0.0.0. Selon l'étape du chargement, l'exception visible est une FileNotFoundException ou une ReflectionTypeLoadException. Trois réserves. D'abord, rester en net8 ne protège pas des changements de comportement décrits plus haut : votre DLL tourne quand même sur .NET 10, et il faut la tester dans un produit mis à jour. Ensuite, la cible net8 ne garantit rien pour les bibliothèques natives ou tierces que vous embarquez, ni pour la compatibilité entre deux millésimes, Revit 2025 et Revit 2026 par exemple. Enfin, l'Object Enabler en C++/CLI fait exception : Autodesk demande de le reconstruire pour .NET 10.

Récapitulatif

Changement	Symptôme	Correction
BinaryFormatter supprimé (.NET 9)	`PlatformNotSupportedException` à la sauvegarde ou à la lecture, même sous Revit, qui l'autorisait	Changer de format de sérialisation, reprendre les fichiers existants
Conversions non vérifiées de réel en entier saturantes (.NET 9)	Résultat géométrique différent, sans erreur	Tester `NaN` et les bornes avant de convertir
DynamicResource du mauvais type (.NET 10)	Dictionnaire ou fenêtre WPF qui ne se charge plus, selon le contexte	Corriger le type de la ressource
System.Drawing, statut GDI+ `OutOfMemory` (.NET 10)	`ExternalException` non gérée là où l'on attendait `OutOfMemoryException`	Intercepter aussi `ExternalException`
XmlSerializer et `[Obsolete]` (.NET 10)	Éléments en trop dans le XML, ou `InvalidOperationException`	`[XmlIgnore]` sur les propriétés obsolètes
`DllImportSearchPath.AssemblyDirectory` seul (.NET 10)	`DllNotFoundException`	Livrer la DLL native avec le complément
Paramètres de clé X509 qui peuvent valoir `null` (.NET 10)	`NullReferenceException` dans le code de licence	Traiter le cas `null`
Object Enabler C++/CLI (AutoCAD)	L'Object Enabler ne fonctionne plus	Reconstruire pour .NET 10, ou supprimer son `runtimeconfig.json`
DLL d'AutoCAD ou de Revit installées, compilées pour .NET 10	`CS1705` à la compilation en net8	Paquet `AutoCAD.NET` épinglé en net8, assemblies de référence net8 pour Revit
Paquet AutoCAD.NET 25.0.2 ou 25.1.1	`NU1202` à la restauration en net8	Épingler 25.0.1 (2025) ou 25.1.0 (2026)
WinForms et WPF ambigus (net10)	`CS0104` sur un type non qualifié	Alias `using` ou nom complet
Grilles WPF vides (net10)	`MC3063`, éventuellement dans `MC1000`	Une définition au moins, ou supprimer l'élément

Comment savoir si votre complément est touché

Cherchez dans le code les signes qui figurent dans le tableau : BinaryFormatter, catch (OutOfMemoryException), DllImportSearchPath, [Obsolete] sur des classes sérialisées en XML, DynamicResource, conversions de double en int dans le code géométrique.
Installez la mise à jour sur un poste de test, chargez le complément tel qu'il est livré aujourd'hui, et déroulez ses commandes, ses fenêtres et ses fichiers de réglages.

Sources

Autodesk

Autodesk Desktop Products 2025/2026: .NET 10 Updates : produits et numéros de mise à jour, calendrier prévu, compatibilité des compléments existants, Object Enablers en C++/CLI, DevExpress dans Vault.
Call for Preview Testing: Revit 2026/2025 Migration to .NET 10 : passage de Revit 2025 et 2026 à .NET 10, compléments qui embarquent du code natif ou des bibliothèques tierces.
AutoCAD 2026 .NET 10 Update Beta Preview is Now Available : une mise à jour cassante livrée en cours de cycle.
Add-in Dependency Isolation : isolation facultative des dépendances d'un complément Revit 2026 (UseRevitContext).

Microsoft, changements cassants de .NET 9

Microsoft, changements cassants de .NET 10

Éditeur de compléments

Transoft : Important Notice for AutoCAD or Civil 3D Users: Autodesk .NET Framework Update : conseil d'attendre avant d'appliquer la mise à jour.

Les messages d'erreur reproduits dans l'article (CS1705, NU1202, BinaryFormatter, chargement d'une DLL net10 dans un processus .NET 8) viennent de nos propres essais sur AutoCAD 2025 et Revit 2025.5 mis à jour.

Besoin d'aide pour la mise à jour ?

Si l'un de vos compléments AutoCAD, Revit, Inventor ou Civil 3D ne passe plus la mise à jour, ou si vous voulez le vérifier avant de la déployer chez vos utilisateurs, nous pouvons nous en charger : diagnostic sur la version mise à jour, correction, et, quand ses dépendances le permettent, construction d'une DLL qui couvre les postes passés en .NET 10 comme ceux restés en .NET 8. Nous développons et maintenons des compléments pour ces logiciels : voir le développement AutoCAD et le développement Revit, ou écrivez-nous en décrivant votre complément et le symptôme observé.