Impossible de compiler un plugin AutoCAD 2026 en C# avec Visual Studio.

[DenisH]

Bonjour à la communauté.

Je viens de me prendre la tête avec l’IA (Gemini 3 Pro). Attention, je me prends la tête « avec » elle, sur un problème que je rencontre. Ca fait 2 jours qu’on planche tout les deux dessus, et pas de solution.
Elle m’envoi donc vers vous :

Description du problème : Impossible de compiler un plugin AutoCAD® 2026 en C# avec Visual Studio 2022 (ou 2026), car VS réécrit constamment le fichier .csproj, provoquant des erreurs CS1705 et CS7069.

• Environnement :
• AutoCAD® 2025 (Standard) et 2026 (Standard)
• Visual Studio Community 2022 (j’ai désinstallé 2026, croyant que le pb venait de là)
• .NET Framework 4.8
• Windows 11

Les messages d’erreur exacts :
CS1705 : L’assembly ‹ Acdbmgd › avec l’identité ‹ Acdbmgd, Version=25.1.0.0, Culture=neutral, PublicKeyToken=null › utilise ‹ System.Linq.Expressions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a › dont la version est supérieure à celle de l’assembly référencé ‹ System.Linq.Expressions › avec l’identité 'System.Linq.Expressions, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
CS7069 : Une référence au type ‹ MarshalByRefObject › déclare qu’il est défini dans ‹ System.Runtime ›, mais il est introuvable

Pièce jointe dans le ZIP : .cs, app.config, .csproj.
TestAutoCADPluginNew.zip (2,6 Ko)

Nous avons tenté de corriger manuellement le .csproj, d’ajouter des redirections de liaison, de créer un nouveau projet, vérifié les chemins des DLL, et même désinstaller Visual Studio 2026 pour installer le 2022.

Le pire, c’est qu’il y a trois jours, Gemini m’a proposé un code en C# pour dessiner une simple ligne, et ça a fonctionné, depuis, impossible de faire autre chose…

Si quelqu’un a une solution, une idée, nous sommes preneurs.

Denis…

[Patrick]

Salut Denis, bienvenue dans le monde merveilleux de l’IA.

Bon, bien que j’ai fait du développement DotNet sur AutoCAD® par le passé, c’est un peu fini pour moi tout ça, maintenant que je suis à la retraite, donc je ne vais pas pouvoir t’aider directement. Par contre, il me semble que @koroma a des problèmes un petit peu similaires au tien, et qu’il serait peut-être intéressant que vous en discutiez.

[DenisH]

C’est parfait, j’espère que @koroma aura une solution, même un début de solution…
Merci @Patrick !

[borelly]

en tout cas c est le cas pour Revit® depuis version 2025 certain fonction sont à réadapter
(code changer)

[borelly]

oublie .net framework 4.8 ils on dut passe en .net 8.0 (net core multi support)

[Charles]

Salut @DenisH ,

le problème vient de là :

@DenisH

.NET Framework 4.8

Depuis 2025, AutoCAD® est passé sous NET Core 8.0.

[DenisH]

Bonjour à la communauté (bienvenue à @borelly) et merci pour toutes vos réponses.
En fait, il faut juste télécharger et installer « PluginVsix.vsix », que j’ai trouvé sur GitHub et bien choisir son AutoCAD®.
Tout le reste ne me parait plus « nécessaire ».
D’après ce que j’ai compris, c’est bien le dialogue entre AutoCAD® (.NET 8.0) et Visual Studio (.NET 4.8) qui posait problème.
Maintenant, je créé directement un projet AutoCAD® dans Visual Studio.
Bien à toi la communauté.
Denis…

[serge.camire]

Bonjour,

Je confirme que ce plugin nécessite le Framework 8.0 et qu’il est prévu pour AutoCAD® 2026. On pourrait le rétrograder sans difficulté vers 2025.

Voici où ça me semble accrocher (erreur CS1705). Dans le fichier de projet (*.vcproj) se trouvent des références à des chemins qui existent sur le poste de celui qui vous les a préparées. Un chemin qui remonte aussi longtemps sans être résolues jusqu’à la racine (voir ci-bas « ..........\Program Files\Autodesk® » m’indique que ses DLL ont été identifiées depuis une version de Visual Studio installée plus haut ou plus bas vers la racine que le votre.

Il se peut peut que d’autres références requièrent d’autres réajustement de chemin. L’erreur CS7069 est peut-être une conséquence de l’erreur CS1705). Sinon, voir ici : Compiler Error CS1705

Voici 2 workarounds pour celles d’AutoCAD®:

1. Le meilleur : Aller dans VS puis dans la section du projet, supprimer un à un les dll et les remettre chaque fois en indiquant le répertoire d’AutoCAD® 2026.
2. À vos risques : (en admettant qu’AutoCAD® soit sur C) Éditer manuellement le fichier *.vcproj et substituer « ..........\Program Files\Autodesk®\AutoCAD® 2026 » par « C:\Program Files\Autodesk®\AutoCAD® 2026 ». Ça va vous faire sauver 5 minutes.

      <HintPath>..\..\..\..\..\Program Files\Autodesk\AutoCAD 2026\accoremgd.dll</HintPath>
    </Reference>
    <Reference Include="AcCui">
      <HintPath>..\..\..\..\..\Program Files\Autodesk\AutoCAD 2026\AcCui.dll</HintPath>
    </Reference>
    <Reference Include="AcCustomize">
      <HintPath>..\..\..\..\..\Program Files\Autodesk\AutoCAD 2026\AcCustomize.dll</HintPath>
    </Reference>
    <Reference Include="acdbmgd">
      <HintPath>..\..\..\..\..\Program Files\Autodesk\AutoCAD 2026\acdbmgd.dll</HintPath>
    </Reference>
    <Reference Include="AcDx">
      <HintPath>..\..\..\..\..\Program Files\Autodesk\AutoCAD 2026\AcDx.dll</HintPath>
    </Reference>
    <Reference Include="AcDxPublishUi">
      <HintPath>..\..\..\..\..\Program Files\Autodesk\AutoCAD 2026\AcDxPublishUi.dll</HintPath>
    </Reference>
    <Reference Include="acmgd">
      <HintPath>..\..\..\..\..\Program Files\Autodesk\AutoCAD 2026\acmgd.dll</HintPath>
    </Reference>

[Patrick]

Merci bien @serge.camire pour ton expertise et content de te revoir ici même si c’est virtuellement.

[serge.camire]

Pas de quoi. En me relisant, j’ai remarqué que les \ avaient été supprimés du texte formatté mais on les voit dans le texte en mode Code. La liste des DLL appartenant à AutoCAD® est plus longues dans le fichier source.

Parlant de se revoir, ça pourrait être en vrai en 2026 si tu me laisses (en privé) les coordonnées où tu te trouves.

[DenisH]

Merci @serge.camire pour ton aide.
J’avais déjà changer les Path, mais VS les réécrivait systématiquement…

Pour voir maitre @Patrick, c’est au Brésil qu’il faut aller.
C’est dommage pour moi, j’y vivais avant, mais je suis revenu en France…
Denis…

[serge.camire]

Alors je regarderai vers le Brésil. Je reviens à peine du Pérou et de la Bolivie Ce sera peut-être pour 2027.

Pour la solution, si VS les remet les chemins relatifs et que l’Explorateur de solutions ne met pas un drapeau jaune, c’est OK. Par contre, il y a aussi une référence manquante au Desktop Connector (voir prochaine image).

Certaines fonctionnalités cloud d’AutoCAD® (comme l’accès à BIM 360) s’appuient sur Desktop Connector, mais le fichier DLL n’est jamais intégré dans AutoCAD®. Pour l’installer, tu peux accéder à la page suivante :

Page officielle Autodesk Desktop Connector

[DenisH]

Bonjour @serge.camire et merci pour ta réponse.
C’est téléchargé, je vais regarder ça attentivement.
Denis…

[serge.camire]

Salut Denis,

Je n’avais pas compilé la solution et ça me tracassais. Je n’ai pas la version AutoCAD® 2026 (j’avoir une très vielle version beta de celle-ci) et le site d’Autodesk® pour développeur semble (encore une fois) avoir un léger problème technique pour que je la télécharge. Par contre j’ai fait des tests avec la 2025 puis refait les ajustements. Il y avait plusieurs corrections. Tu pourras comparer les versions source du fichier *.csproj et *.cs pour t’en rendre compte.

Tu n’as qu’à télécharger celui-ci. Il a été refait depuis zéro.

TestAutoCADPluginNew 2026.zip (2,2 Ko)

Note 1:

Il existe bel et bien des différences entre AutoCAD® 2025 et 2026. Avec 2025, les DLL n’étaient pas encore parfaitement alignées avec le runtime .NET 8 final et la compilation générait des avertissement MSB3277 : détection de conflits non résolus entre différentes versions de « Microsoft.VisualBasic ».

Même si on n’utilise aucune ligne de VB, le runtime .NET inclut automatiquement plusieurs assemblies de base, dont :

• Microsoft.VisualBasic.dll
• System.Runtime.dll
• System.Linq.dll
• etc.
  Pourquoi ?
  Parce que Microsoft.Visual Basic contient des helpers utilisés par le runtime, notamment :
• les fonctions d’interaction COM
• certaines API d’interopérabilité Windows
• des helpers pour les conversions de types
• des fonctions historiques encore utilisées par certaines bibliothèques

Note 2:

J’ai demandé au compilateur d’omettre certaines erreurs jugées normales et qu’il est sécuritaire d’inclure dans le fichier de projet:

  </PropertyGroup>
    <PropertyGroup>
    <NoWarn>CA1822;IDE0090;IDE0130</NoWarn>
  </PropertyGroup>

En C#, contrairement au VB, il est conseillé de modifier le Framework cible comme suit (ajout de -windows)

  <PropertyGroup>
    <TargetFramework>net8.0-windows</TargetFramework>
    <RootNamespace>ClassLibrary1_Test_NETCore_C_</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <Platforms>x64</Platforms>
  </PropertyGroup>

Notes 3

Il est impératif de n’avoir aucune référence à AnyCPU dans la balise Platforms, sans quoi il pourrait y avoir d’autres messages d’avertissement. Quoique j’ai mis <NoWarn>CA1822;IDE0090;IDE0130</NoWarn>, ce qui équivaut un peu au « #pragma » en C++ (ce dernier n’agissant qu’au niveau du fichier courant et non du projet en entier).

<Platforms>x64</Platforms>

Note 4

La référence à Desktop Connector a été supprimée. Le créateur du projet devais avoir un gabarit pour le démarrage de nouveaux projets.

Note 5

J’ai dû forcer le typage d’expressions sur 2 des lignes en valeur de retour pour ne pas risquer de générer des erreurs à l’exécution (i.e. ajout de (BlockTable) et (BlockTableRecord).

                BlockTable bt =  (BlockTable)tr.GetObject(db.BlockTableId, OpenMode.ForRead) as BlockTable;
BlockTableRecord btr = (BlockTableRecord)tr.GetObject(bt[BlockTableRecord.ModelSpace], OpenMode.ForWrite) as BlockTableRecord;

Donnes-moi de tes nouvelles.

[DenisH]

Bonjour @serge.camire et merci beaucoup pour ton aide.
Je vais regarder ça très attentivement, dès que le temps me le permettra (trop de travail en ce moment).
Encore merci à toi.
Denis.