Migration de solution DotNet pour AutoCAD 2013

Par Serge Camiré

Contenu

Sommaire
Pas de nouveau pour l’instant avec AutoLISP ni avec VBA
Le riz, le vin … et le saké
Terminologie
Versions de Framework
Compatibilité avec AutoCAD
Compatibilité du Common Runtime Library et des références
Le riz : efforts minimums
     Modification du Framework
     Modification des références
          Références à des librairies managées d’AutoCAD
          Références COM remplacée par des Primary Interop Assemblies (PIAs)
          Références à des fonctions non managées
Le vin : tirer profit des améliorations technologiques
     Autoloader : un Assistant d’installation de solutions
     APPAUTOLOAD
     Réutilisation du code source
     Dynamic DotNet
     InstallShield Limited Edition pour Visual Studio 2010
     Nouveautés du FrameWork 4.0
Le saké : aller encore plus loin
     Le déploiement en réseau
          Les contraintes du déploiement en réseau changent
          Caspol (CLR 2.0)
          Sandboxing et AppDomain (CLR 4.0)
          Porte-documents ou Centre de synchronisation
     Les apparences (skins)
          Pourquoi des skins
          Un petit coup d’oeil au Managed Extensibility Framework
          La gestion des normes de dessins avec le MEF
Windows 8 et ses impacts
     .Net Framework 4.5
     AutoLISP
     Metro style App

Sommaire

Cet article traite de la migration des applications DotNet pour AutoCAD 2013. Malgré sa longueur, vous retrouverez en un seul document une foule d’informations pertinentes concernant les efforts minimaux pour faire en sorte que vos applications fonctionnent, ainsi que des pistes pour tirer davantage des nouvelles possibilités. Il y a tant à découvrir qu’après tout vous aurez peut-être l’impression après sa lecture que l’article était très court.

Malgré que cela ne fût pas planifié, on peut dire que cet article s’inscrit dans une série de 5 dont les 2 premiers sont déjà créés et disponibles dans les hyperliens :
1. Nouveautés technologique de l’environnement de programmation
     a. Dynamic .NET dans AutoCAD 2013
     b. Dynamic .NET dans AutoCAD 2013 (suite)
2. Migration de solution ObjectARX pour AutoCAD 2013
3. Migration de solution DotNet pour AutoCAD 2013 : cet article
4. Création d’un Assistant de déploiement de solution (à venir)
5. Création d’un Assistant de création de projet (à venir)

On glissera d’abord un très bref mot sur AutoLISP et VBA puisqu’il n’y a pas d’efforts à faire pour la migration en 2013.

Pas de nouveau pour l’instant avec AutoLISP ni avec VBA

D’entrée de jeu, mentionnons qu’il n’y aura pas d’article sur la migration d’AutoLISP ni sur VBA puisque cela ne requière pas d’efforts de migration, du moins pour le moment. Attendez-vous cependant à ce qu’il y en ait prochainement pour AutoLISP, surtout dans vos routines d’erreur (*error*) si celles-ci utilisent des expressions (command) {par exemple(defun *error* (msg) (command " _u"))}. À l’instar de la commande defun-q qui a été créée comme complément à defun, il devrait y avoir un complément à command (probablement command-s). Ce changement est attribuable au retrait du support des fibres que ne supportera plus Microsoft avec son Windows 8 (si le sujet des fibres vous intéresse, visitez ce lien : http://en.wikipedia.org/wiki/Fiber_(computer_science)).

Pour ce qui est de VBA, malgré les avertissements d’Autodesk à l’effet que la version d’AutoCAD 2010, puis la 2011, puis la 2012 ne supporterait plus cette plateforme, et bien sachez que c’est encore disponible en téléchargeant un module complémentaire. Mentionnons qu’AutoCAD fournit ses meilleurs efforts pour garder cette technologie et nous devons les en remercier. S’ils en annoncent régulièrement le retrait, c’est suite aux annonces qu’ils reçoivent eux-mêmes de Microsoft. Cependant, II semblerait que ces derniers envisagent finalement de la garder vivante. Un dossier à suivre. Par contre, on ne saura que trop vous encourager à créer vos nouvelles applications en DotNet qui vous offrira beaucoup plus de possibilités.

Le riz, le vin … et le saké

Chez Autodesk, et peut-être ailleurs, on fait mention de riz et de vin à chaque fois qu’on parle de migration. Le riz étant l’élément de survie de bien des peuples, on l’utilise pour signifier une conversion minimale afin que tout fonctionne, mais sans plus. Le vin étant un produit plus noble, on l’utilise pour signifier la plus-value que votre produit tirera des nouveautés. Le saké est un vin de riz. Personne encore n’utilise ce terme dans un contexte de migration mais puisque c’est une combinaison des 2 termes mais un produit totalement différent, on l’utilisera plus loin dans cet article pour vous parler de ce qu’on peut tirer de totalement nouveau en combinant de nouvelles technologies.

Terminologie

Le but de cet article est avant tout de vous guider vers la migration de vos applications en DotNet pour AutoCAD 2013. Nous commencerons toutefois par un très court rappel des termes qui seront utilisés dans cet article. On présume toutefois que vous en avez déjà une petite idée.

Le .NET Framework est un composant Windows intégral qui prend en charge la création et l'exécution d'applications autonomes ou de DLL ainsi que de services Web XML. Il existe également un Framework pour tous les autres systèmes d’exploitation, incluant le .NET Compact Framework spécialement conçue pour être exécuté sur des terminaux mobiles.

Par opposition aux applications basées sur le Framework, nous retrouvons les applications natives pour poste de travail soit en C++ (incluant ObjectARX), les applications créées avec Visual Studio 6 et antérieures, le VBA, les composants COM, les langages de services Web dont tous les langages de script.

Dans le monde des applications managées, il existe une première couche obligatoire entre le système d’exploitation et le reste qui se nomme le Runtime. On y fera référence sous le nom de Common Langage Runtime ou CLR. Vient ensuite une succession de couches dont la plus commune est la librairie managée de base ou Base Class Library (BCL). Par-dessus ces couches, viennent vos applications.

Voici une image tirée du site http://msdn.microsoft.com/fr-fr/library/zw4w595w.aspx qui illustre le concept.

Versions de Framework

Nous sommes rendus à la 7e génération depuis la sortie des Frameworks en 2002. Pour vous aider à démêler tout ça, on vous a préparé un tableau qui montre leur évolution, la version du Common Runtime Library qu’elles supportaient, leurs caractéristiques majeures. En parallèle, vous trouverez la version de Visual Studio concernées, celles d’AutoCAD ainsi que la version de Windows qui l’a supportée de façon native. On a repris un graphique inspiré du site officiel de Microsoft au http://msdn.microsoft.com/en-us/library/bb822049(VS.110).aspx pour dissiper toutes controverses quant au CLR employé par le .Net Framework 4.5 car à la fin de l’article, vous trouverez une section traitant de Windows 8 et du non support du .Net Framework 4.0.

Note : Ne reculant devant rien, on a utilisé le site http://www.colorschemer.com/online.html pour assortir les couleurs du prochain graphique J.


Compatibilité avec AutoCAD

AutoCAD 2005 fut la première fois à exploiter les capacités de DotNet malgré que c’était surtout un prototype. Bien sûr, il était possible d’utiliser DotNet en application autonome et de façon « out-of-process » pour les versions antérieures d’AutoCAD mais ceci est sanraquo; était la 2006. À cette époque, Il était alors possible d’utiliser Visual Studio 2002 ou 2003. À noter que Visual Studio 2002 était lui-même une version non aboutie.

Compatibilité du Common Runtime Library et des références

Le plus important à souligner c’est que ce n’est pas tant la compatibilité du Framework qui compte mais la compatibilité au Common Langage Library (CLR) qui est derrière pour faire fonctionner vos routines autonomes. Comme le montre le graphique précédent, les versions de Visual Studio 2005 et 2008 était basées sur le CLR 2.0 et celle de Visual Studio 2010 sur le CLR 4.0.

AutoCAD 2012 (et 2013) utilisent le .NET Framework 4 (FW4.0). Ce FW est le premier qui n'utilise pas automatiquement sa version du Common Language Runtime (i.e. le CLR 4.) pour exécuter des applications générées avec les versions antérieures du .NET Framework. Il peut aussi utiliser le CLR 2.0 au besoin. Ceci a un impact important sur vos applications créées pour AutoCAD 2010 et 2011 car cela signifie qu’elles pourront être compatibles à AutoCAD 2012 comme nous le verrons plus loin. L’inverse n’est pas vrai, c’est-à-dire qu’une application utilisant le FW4.0 ne pourra fonctionner dans AutoCAD 2010 ou 2011. Ne vous réjouissez pas trop vite, vos application pour AutoCAD 2010 exigerons des modifications pour passer à la 2013 comme nous le verrons à l’instant.

Vos DLL pour AutoCAD font référence aux fichiers acdbmgd.dll et acmgd.dll (il y en a aussi d’autres). Ces fichiers sont des wrappers sur le noyau d’AutoCAD et sont identifiées à une version de Visual Studio spécifique. Elles ne poseront pas de difficulté à se charger mais lorsque vous tenterez d’exécuter l’une des commandes ou routines qui y sont définies, vous obtiendrez ce message d’erreur : « ; erreur: Demande ADS erronée ».

Dans d’autres circonstances, si vous désirez quand même forcer l’exécution des applications plus anciennes sur le .NET Framework 4, vous devez compiler votre application avec la version du .NET Framework cible spécifiée dans les propriétés de votre projet dans Visual Studio. Voyez le lien http://msdn.microsoft.com/en-us/library/ee518876.aspx pour plus de détails.

Également dans certaines circonstances, surtout si vous utilisez des composants COM, vous pourrez créer un fichier de type XML qui portera le nom de votre fichier exécutable mais avec une extension.config en plus du reste. Par exemple, le fichier MonProjet.dll aura comme compagnon MonProjet.Dll.Config ou simplement app.config. Consultez le lien http://msdn.microsoft.com/en-us/library/9w519wzk.aspx pour plus de détails. Voici en quoi peut ressembler ce fichier.

<configuration>
   <startup>
      <!-- startup useLegacyV2RuntimeActivationPolicy="true">

      <!-- Depuis .NET Framework version 4, seuls les numéros  ->
      <!-- de version principale et secondaire sont nécessaires ->
      <!-- (c'est-à-dire "v4.0" au lieu de "v4.0.30319"). La ->
      <!-- (chaîne plus courte est recommandée. ->

      <!-- supportedRuntime version="v4.0"/ ->
      <supportedRuntime version="v2.0.50727"/>
      <!-- supportedRuntime version="v1.1.4322"/ ->
      <!-- supportedRuntime version="v1.0.3705"/ ->
   </startup>
</configuration>

Le riz : efforts minimums

Depuis sa version 2000, AutoCAD ne brise normalement la compatibilité des dessins et de la programmation ObjectARX et DotNet qu’aux 3 ans. Cet événement coïncide avec ce qu’on appelle un changement du numéro majeur de version. Les numéros 15, 16, 17, 18 et 19 sont respectivement associés aux triplets suivant : (2000, 2000i, 2002); (2004, 2005, 2006); (2007, 2008, 2009); (2010, 2011, 2012); (2013, 2014, 2015). Étrangement, la version 2012 était basée sur le Framework 4.0 mais acceptait quand même les DLL conçues pour 2010 ou 2011 basées sur le Framework 3.5 (lire un autre CLR).

Modification du Framework

Pour votre solution pour AutoCAD 2013, vous devez obligatoirement spécifier le Framework 4.0 (ou 4.5 en Windows 8).

Modification des références

Références à des librairies managées d’AutoCAD

Lors d’un changement du numéro majeur, il faut modifier la référence aux fichiers acdbmgd.dll et acmgd.dll. Si vous avez d’autres références à des Dll d’AutoCAD, il faut aussi les mettre à jour (e.g. AcCui.dll si vous accédez aux fonctions du CUI).

AutoCAD 2013 propose un nouveau module nommé « AutoCAD 2013 Core Console » qui est en fait un AutoCAD sans interface graphique (voyez l’article de Kean Walmsley http://through-the-interface.typepad.com/through_the_interface/2012/02/the-autocad-2013-core-console.html pour plus de détails). Ceci entraine l’ajout d’une toute nouvelle référence nommée AcCoreMgd.dll. Cette DLL est responsable entre autre pour les attributs de fonction CommandMethod et LispFunction.

En ajoutant l’interface non graphique, AutoCAD a procédé à une redistribution de certaines fonctions autrefois dans AcMgd.dll. Ainsi donc, il est hautement possible qu’après l’insertion de cette référence, vous ayez de nombreuses erreurs de ce genre :

Exemple de l’attribut de fonction CommandMethod 
Erreur 1 'Open' n'est pas un membre de 'Autodesk.AutoCAD.ApplicationServices.DocumentCollection'.
  C:\Dev\DotNet\ClassLibrary1\Test.vb 98 19 ClassLibrary1
Erreur 2 'RegistryProductRootKey' n'est pas un membre de
  'Autodesk.AutoCAD.DatabaseServices.HostApplicationServices'.
  C:\Dev\DotNet\ClassLibrary1\Test.vb 488 38 ClassLibrary1
 

Voici comment résoudre l’erreur 1:
Note : Nous avons défini un raccourci AcadNETApp au début du fichier pour alléger le texte :

L'erreur est causée par un déplacement de la fonction à un autre espace de nom. Pour la corriger, vous pouvez la plupart du temps appuyer sur la touche F2 et laisser Visual Studio chercher la fonction via l'Explorateur d'objets.

En cherchant dans la liste, on trouve assez rapidement ce qu'on cherche. La méthode Open est membre de Autodesk.AutoCAD.ApplicationServices.DocumentCollectionExtension

Nous verrons à la section Réutilisation du code source que l'on peut partager le code source pour plusieurs Framework, donc plusieurs versions d'AutoCAD en utilisant des constantes personnalisées et des instructions #if . Avec la constante «  _AcadVer_=19.0  », le code précédent s'écrirait donc :

Comme exercice, recherche z à quel espace de noms la propriété 'RegistryProductRootKey' est membre tel que signalé dans l’erreur 2. Cette propriété rensigne sur la clé du produit. La solution se trouve à la toute fin de l’article.

Références COM remplacée par des Primary Interop Assemblies (PIAs)

Si vous avez des références sur le Type Library d’une ancienne version d’AutoCAD (e.g. AutoCAD 2010 Type Library), il faudra la remplacer. On peut être appelé à se servir de cette référence pour accéder à l’objet Preferences. Avec l’ancienne façon, vous trouviez la référence dans l’onglet COM puis Visual Studio utilisait la version enregistrée dans le Global Assembly Cache (GAC). Une référence à OLE Automation l'accompagnait. Avec la nouvelle façon, vous la trouverez ailleurs, soit en parcourant le répertoire d’installation d’AutoCAD (e.g. C:\Program Files\Autodesk\AutoCAD 2013) puis en choisissant les 2 fichiers Autodesk.AutoCAD.Interop.dll et Autodesk.AutoCAD.Interop.Common.dll. En principe, Visual Studio saura retrouver les références sur le poste où vos applications seront déployées. Note: même si AutoCAD 2013 Type Library est disponible, choisissez quand même la nouvelle méthode.

Attention : la valeur de « Copie locale » doit aussi être à False pour les fichiers de type Primary Interop Assemblies (PIAs). C’est vrai pour les PIA d’AutoCAD, Excel et autres. C'est déjà désagréable pour les développeurs qui veulent juste écrire du code utilisant un API COM d'avoir à se soucier de l'expédition des PIA sur le poste du client, de s'inquiéter de savoir si ou non il existe déjà sur la machine cliente et quelle version il a. Comme mentionné dans le premier article sur l’inférence dynamique, vous pouvez concevoir le leitmotiv principal du FW4.0 comme une version d'interopérabilité où les paradigmes sont simplifiés (typage dynamique). Ainsi, votre application peut être compilée sans connaitre le type exact des objets contenus dans les PIAs et la liaison se fera lors de l’exécution.

Voyez cet article pour plus de détails : http://msdn.microsoft.com/en-us/library/dd409610.aspx.

Profitez-en pour rafraichir les autres composants COM ou .NET applicables comme ADODB, Excel, etc.

Références à des fonctions non managées

Si vous avez des références aux fonctions décorées du fichier acad.exe (par exemple, parce qu’il n’existe pas d’équivalent de la commande VIEW en DotNet), vérifiez à l’aide de l’outil DUMPBIN /SYMBOLS ou de l’outil Dependency Walker si les noms « mangled » ou déformés ont changés. En théorie, ceux-ci ne devraient pas changer mais sait-on jamais. Dans l’exemple suivant, vous pourrez noter qu’on a préparé une fonction pour la version 32 et 64 bits.

Note : l'usage de la fonctionnalité P/Invoke (ou Platform Invoke) est préférable à l'appel de fonction décorée lorsque cela est possible car vous n'avez pas à vous en soucier lors de migration et vous n'avez pas non plus à vous soucier du nombre de bits du système d'exploitation. Par exemple, vous pouvez utiliser le P/Invoke pour accéder aux variables d'AutoLISP de cette façon. L'article « Using P/Invoke to Call Unmanaged APIs from Your Managed Classes » donne plus d'informations sur la méthode P/Invoke (ou Platform Invoke) derrière ce type d'appel : http://msdn.microsoft.com/en-us/library/aa719104(v=vs.71).aspx

Le vin : tirer profit des améliorations technologiques

Autoloader : un Assistant d’installation de solutions

Nous glissons très brièvement un mot sur les possibilités disponibles depuis AutoCAD 2012 de faire charger vos fichiers AutoLISP (lsp, fas, vlx) vos menus (mnu, cuix), vos DLL managées (dll) et vos applications non managées (arx, dbx). Nous y reviendrons plus en détails dans un autre article. Pour y arriver, il suffit de créer des paquets dans des sous-dossiers du répertoire d’applications %programfiles%\Autodesk\ApplicationPlugins ou du répertoire itinérant %appdata%\Autodesk\ApplicationPlugins en ajoutant un fichier de paramètres au format XML puis vos fichiers.

Note 1 : le répertoire %programfiles% est visible à tous les utilisateurs mais demande des droits d’administrateur pour pouvoir y copier des fichiers tandis que %appdata% ne l’est qu’à l’utilisateur actif mais ne demande pas de droits spéciaux. Si vous désirez savoir à quoi correspondent les 2 variables, vous pouvez taper l’expression directement dans la barre d’adresse de l’Explorateur de Windows. Si vous avez installé le module Fusion lors de l’installation d’AutoCAD, vous trouverez un exemple de plug-in autochargé dans le répertoire « C:\Program Files\Autodesk\ApplicationPlugins\FusionPlugin2013.bundle ».

Note 2 : Selon les spécifications du fichier XML dans le paquet, des clés de registre peuvent être créées pour le mécanisme d’autochargement. Si vous désinstallez vos applications, l’Assistant Autoloader ne nettoiera pas ces clés. C’est l’une des nombreuses différences trouvées entre cet utilitaire et un Assistant de type Setup.exe ou MSI.

Note 3 : Si votre solution comporte des éléments qui doivent être enregistrés, vous devez vous en occuper vous-même. Cela peut être des OCX, des PIA qui n’appartient pas aux logiciels publics tels que AutoCAD ou Office, des dll signés avec des noms forts (Strong Name Key), etc.


Répertoire ApplicationPlugins sous %ProgramFiles% avec Windows XP 32


Répertoire ApplicationPlugins sous %AppData% avec Windows 7 64

Il existe une variable nommée APPAUTOLOAD permettant de choisir la méthode de chargement des paquets.

Réutilisation du code source

Rien de pire que de gérer différents codes source juste parce qu’on doit supporter différentes versions de Visual Studio. Les langages C# et VB sous Visual Studio vous permettent d’ajouter des fichiers existant en liaison, exactement comme les références externes dans AutoCAD. Note : le langage C++ (pour ObjectARX) ne permet cela mais on peut y arriver par un autre moyen.

Nous allons découvrir via un projet VB comment procéder. Tout d’abord, nous allons créer un projet comportant une et une seule commande, celle-ci ouvrant la célèbre boite de dialogue HelloWorld.

Dans l’image suivante, vous constaterez d’abord 2 éléments :
•    Imports acApp = Autodesk.AutoCAD.ApplicationServices.Application
•    result = acApp.ShowModalDialog(Nothing, frm, False) ' Mieux

La première expression permet non seulement de raccourcir de beaucoup le code lorsque vient le temps de spécifier l’objet Application mais surtout, cela permet de supprimer toute ambigüité lorsque vous avez 2 objets dans le même projet, par exemple AutoCAD et Excel.

La deuxième expression peut vous sembler étrange. Au lieu de lancer la boite de dialogue par l’expression « frm.ShowDialog()», nous avons choisi la méthode proposée par Autodesk. Pour savoir pourquoi, consultez l’article de Kean Walmsley « The right way to show modal and modeless dialogs in AutoCAD using .NET ». Il est à noter qu’il existe plusieurs surcharge de cette méthode et différentes signatures selon la version d’AutoCAD, d’où l’intérêt didactique de la démarche.

Si vous regardez l’arborescence de répertoires de votre solution, vous obtiendrez quelque chose de similaire à ceci.

Ce qui vous saute aux yeux, ou du moins on espère que cela vous sautera aux yeux après avoir adopté nos quelques suggestions est que :
•    On peut difficilement deviner avec quelle version d’AutoCAD nous sommes compatibles
•    Si on veut supporter plusieurs versions majeures d’AutoCAD, donc plusieurs versions de Visual Studio, nous multiplierons le nombre de fichiers sources. Au moment de copier les fichiers, pas de problèmes, mais le jour où vous aurez des correctifs à faire, vous ferez des jongleries.

Voici ce vers quoi on veut tendre :
•    Avoir un répertoire commun pour les fichiers source qui soit en dehors du contexte de la version d’AutoCAD
•    Créer autant de sous-répertoires que de versions majeures d’AutoCAD à supporter. On se rappellera que R17 se réfère aux versions 2007 à 2009, R18 aux versions 2010 à 2012, R19 aux versions 2013 à 2015.
•    Avant de procéder ces modifications, faites-vous une copie de sauvegarde.

Important :
On sait que la version 2012 d’AutoCAD est basée sur le Framework 4.0 tandis que les versions 2010 et 2011 sont basées sur le Framework 3.5. Si vous souhaitez que vos DLL soient compatibles aux 3 années d’AutoCAD, compilez-les avec le Framework 3.5. Inversement, si vous les compilez avec le Framework 4.0, elles ne seront compatibles qu’avec AutoCAD 2012. 

Attention : dans la boite de dialogue suivante, il faut spécifier « Ajouter en tant que lien ». À défaut de faire cela, les fichiers seront copiés localement et vous évoluerez avec des fichiers distincts, ce qui gênera les futures mises à jour. La différence entre « Ajouter » et « Ajouter en tant que lien » est la même qu’entre INSERER et INSERT pour l’insertion d’un bloc ou d’une référence externe.

Les 2 fichiers sont maintenant insérés en tant que lien externe. On remarquera la présente de la marque de raccourci sous le nom des 2 fichiers. Important : nous n’avons pas sélectionné le fichier frmHelloWorld.Designer.vb. En effet, les fichiers Designer suivent toujours leur parent.

La prochaine étape consiste à définir une ou des constantes de compilation personnalisées. Celles-ci serviront à marquer les bouts de code qui diffèreront selon la version d’AutoCAD et qui serviront lors de la compilation conditionnelle. La compilation conditionnelle permet de compiler de façon sélective des blocs de code spécifiques tout en excluant d'autres blocs. À la compilation, les blocs exclus sont tout simplement ignorés donc le DLL produit n’en est pas plus lourd. Dans notre premier projet, on présume être avec Visual Studio 2005 et le Framework 2.0. Nous allons donc définir une variable _AcadVer_ selon la valeur numérique 17.2.

Nous allons maintenant définir nos blocs conditionnels via les instructions :

Pour plus d’information sur la syntaxe, consultez le lien Compilation conditionnelle en Visual Basic.

En C#, les constantes personnalisées n’existent pas mais un autre concept les remplace, soit les instructions « #Define ».

Ce qui nous importe est que le comportement de la méthode ShowModalDialog diffère que la version d’AutoCAD ciblée soit 2009 ou plus comme le montre l’exemple suivante. Le premier paramètre est respectivement Nothing ou IntPtr.Zero selon les 2 situations.

On sauvegarde la solution puis on recommence cette fois pur les autres Frameworks à supporter en suivant ces instructions:
·    Copier le répertoire R17 sous le répertoire R18 et/ou le répertoire R19
·    Pour chacun des nouveaux répertoire, ouvrez la solution avec la bonne version de Visual Studio et procédez à la migration.
·    Une fois le projet migré, assurez-vous que la version de Framework soit ajusté. Cela demande de redémarrer Visual Studio.
·    Profitez-en pour recctifiez la ou les constantes de compilation. Ici, notre variable _AcadVer_ sera ajustée à la valeur 18.1 ou 19.0 selon la version d’AutoCAD cicbée.

•    Corrigez ensuite les références aux fichiers AcDbMgd.dll etAcMgd.dll pour qu’elles correspondent à la version d’AutoCAD ciblé. Si vous avez d’autres DLL comme AcCui.dll, rectifiez-les également. Dans le cas de la 2010, on aura en plus le fichier AcCoreMgd.dll, nous y reviendrons. N’oubliez surtout pas de mettre l’attribut « Copie locale » à faux.

Au final, vous obtenez autant de solutions que vous désirez mais n,avez qu’un seul répertoire de source. Cela facilite d’autant plus la gestion documentaire, par exemple si vous utilisez des outils comme Visual Source Safe, Team Foundation, Apache Subversion, GNU, le Autodesk Vault (pourquoi pas) ou autres.

Dynamic DotNet

Nous avons couvert ce sujet dans l’article Dynamic .NET in AutoCAD 2013 (ou sur AUGI). Un des principaux avantages du typage dynamique au moment de l’exécution est que le code peut fonctionner dans des environnements inconnus du compilateur, pourvu qu’il n’y ait pas d’erreur au moment de l’exécution.

InstallShield Limited Edition pour Visual Studio 2010

En dépit du nouvel Autoloader, il est possible que vous ayez à utiliser un outil plus puissant pour le déploiement de vos applications. InstallShield 2010 Limited Edition (ISLE) est une version gratuite d'InstallShield pour les développeurs Visual Studio et remplace les fonctionnalités des modèles de projet d'installation et de déploiement de Visual Studio. Il permet entre autre de créer des fichiers Windows Installer (.msi). Consultez le document « Choix d'un outil de déploiement de Windows Installer » pour plus de détails sur les caractéristiques du produit : http://msdn.microsoft.com/fr-fr/library/ee721500.aspx

Pour installer ISLE, ouvrez la boite de dialogue des nouveaux projets puis sous « Autres types de projets » -> « Configuration et déploiement », vous trouverez l’Assistant d’installation.

Nouveautés du FrameWork 4.0

Afin de tirer profit des avantages de la nouvelle plateforme, on vous recommande ces quelques liens
Nouveautés de .NET Framework 4 : http://msdn.microsoft.com/fr-fr/library/ms171868(VS.100).aspx
Nouveautés de VB : http://msdn.microsoft.com/fr-fr/library/we86c8x2(VS.100).aspx
Nouveautés de C# : http://msdn.microsoft.com/fr-fr/library/bb383815.aspx

Voici quelques grands titres.
•    Interopabilité (IronPython, etc)
•    Parallel FX pour parallélisation des traitements
•    Projets fondés sur des modèles
•    MultiTargeting (des Frameworks)
•    Zoom dans le code (gr¸ace au WPF)
•    Meilleur Intellisense
•    Surbrillance des références
•    Recherche des références
•    Tests unitaires
•    Continuation de ligne implicite (attention à la compatibilité multi-projets)
•    Expressions lambda
•    Covariance et contravariance générique
•    Inférence de type

Le saké : aller encore plus loin

Le déploiement en réseau

Les contraintes du déploiement en réseau changent

Si vous espérez installer vos dll sur un disque réseau, vous devrez définir des jeux de permission FullTrust (ce niveau est un sur-ensemble de LocalIntranet). Voici les opérations affectées par ce jeu de permission qui, s’il n’est pas défini feront cesser votre programme:

Avec le jeu de permissions LocalIntranet seulement
•    L’accès aux variables d’environnement
•    L’ouverture de boite de dialogue
•    L’accès à des emplacements non fixe (disque réseau, clé USB, CD/DVD, etc.)
•    Réflexion (La réflexion permet d'inspecter dynamiquement le contenu d'assemblages, d'en lire ses types, de créer des instances de ces types durant l'exécution du programme et d'appeler leurs méthodes ou champs dynamiquement.)
•    La sécurité
•    Les interfaces utilisateur
•    Le DNS
•    L’impression

Aux autres niveaux
•    Lecture/écriture de fichier
•    L’accès aux sockets (Un socket est un identifiant unique permettant de transmettre de l’information sur le réseau)
•    L’accès Web
•    Le journal des événements
•    Les permissions personnalisées OleDb
•    Les compteurs de performance
•    Le client SQL
•    Les permissions personnalisé DataPermission

Autrement dit, vous n’irez pas loin.

Caspol à la rescousse (CLR 2.0)

L’utilitaire Caspol (Code Access Security Policy) est un utilitaire permettant de modifier la politique de sécurité, c’est-à-dire les permissions sur le fonctionnement. Il est indispensable pour autoriser l’exécution des dll basée sur le CLR2.0 depuis un disque non fixe (i.e. un réseau).

Lors de l’exécution de DLL à partir d’un disque fixe, la stratégie de sécurité locale est mise à jour automatiquement pour permettre au code du projet de s'exécuter normalement. Cependant, ce n’est pas le cas si le DLL est placé sur un support amovible ou réseau. On doit alors mettre à jour explicitement la stratégie de sécurité sur chaque ordinateur où est utilisée la solution, afin d'autoriser le code assembleur à s'exécuter et à accéder au modèle objet de l’application hôte (ici, AutoCAD). Puisque les partages réseau ne reçoivent que les permissions LocalIntranet, il est relativement fréquent de vouloir utiliser Caspol pour faire davantage confiance aux répertoires réputés le mériter, même en réseau.

Il faut les pleins droits d’administrateur pour que l’effet de la commande Caspol prenne effet. Si l’utilisateur n’a que les droits du dessinateur normal, la commande ne sera pas bloquée mais aucun changement ne sera effectif.

Une politique de sécurité est associée à un code de groupe. L’ajout de codes de groupe se fait via Caspol avec droits d’administrateur à fréquence d’une et une seule fois durant la vie utile du déploiement (ici, les DLL spécifiques à une version d’AutoCAD) ou jusqu’à ce que quelque chose vienne potentiellement altérer la sécurité du Framework.

Il est important de préciser que les droits sont donnés au répertoire et non aux fichiers. En suivant la procédure décrite plus loin, on pourra mettre à jour les DLL sans que l’on ait à réutiliser Caspol.

La dernière opération demandera de confirmer, question à laquelle on répondra Oui
L'opération que vous effectuez va modifier la stratégie de sécurité.
Êtes-vous sûr de vouloir effectuer cette opération ? (oui/non) Oui

Il n’existe pas de mode sans confirmation. On aurait pu forcer la réponse via le fichier en lot en se servant d’une réponse inscrite dans un fichier mais on a choisi de ne pas le faire parce qu’on tient à ce que l’installateur reste vigilant.<

Sandboxing et AppDomain (CLR 4.0)

Avec le FW4.0 et par conséquent le CLR 4.0, le mécanisme employé par CASPOL est désuet car remplacé par les bacs à sable (sandbox) et les domaines d’application (AppDomains). Ce sujet est malheureusement trop vaste pour être traité dans cet article. Voici cependant un lien si vous désirez creuser le sujet :
• Sandbox (sécurité informatique) : http://fr.wikipedia.org/wiki/Sandbox_(sécurité_informatique)
• How to: Run Partially Trusted Code in a Sandbox : http://msdn.microsoft.com/en-us/library/bb763046.aspx

Porte-documents ou Centre de synchronisation

Après avoir fait nos classes avec les solutions en réseau, nous avons convenu que le principe était bon mais que la mise en pratique créait plusieurs irritants et dysfonctionnements. Une solution purement de type local quant à elle a la faiblesse de ne pas vous offrir les dernières mises à jour. Si vous en avez la chance, le mieux est de créer une application ObjectARX (qui est non managée donc non influencée par les restrictions de DotNet), laquelle agira comme le Porte-documents ou le nouveau Centre de synchronisation afin d’assurer la synchronisation entre le disque réseau et un emplacement local ayant les permissions d’écriture. Voici un lien qui explique le Porte-documents : http://windows.microsoft.com/fr-FR/windows-vista/When-would-I-use-Briefcase-instead-of-Sync-Center

Les apparences (skins)

Vous pouvez créer des skins afin de gérer facilement vos différentes normes de dessins grâce au Managed Extensibility Framework.

Pourquoi des skins

Il est aisé de donner un nouvel aspect au Lecteur Windows Media en lui appliquant une apparence. Chaque apparence possède un aspect qui lui est propre, et la plupart d’entre elles s’appliquent aux fonctions de base du Lecteur, telles que la lecture et le réglage du volume. Certaines apparences fournissent des fonctionnalités supplémentaires, par exemple des fichiers audio spéciaux que vous pouvez lire, des visualisations que vous pouvez afficher et d’autres fonctionnalités personnalisées. Les fonctionnalités fournies par une apparence sont déterminées par son créateur. Vous pouvez sélectionner et appliquer une apparence à partir de celles fournies avec le Lecteur, ou bien télécharger d’autres apparences sur Internet.

Un petit coup d’oeil au Managed Extensibility Framework

MEF (Managed Extensibility Framework) est un Framework développé par Microsoft qui permet de créer des applications extensibles facilement. Il fonctionne comme un système de plugin et est capable de composer une application en chargeant des extensions à des endroits prédéfinis. Cela permet d'étendre un logiciel sans avoir besoin de connaitre à l'avance le fonctionnement du plug-in, tant que le celui-ci respecte un contrat grâce à la fonctionnalité de découverte de MEF.

MEF fonctionne grâce à des annotations et des attributs.
•    L'attribut Export permet d'informer MEF qu'il se trouve en présence d'un plugin qui respecte un contrat particulier.
•    L'attribut Import permet d'indiquer à MEF qu'il doit se débrouiller pour nous fournir quelque chose qui respecte un contrat précis.

Le Managed Extensibility Framework (MEF) est un tout nouveau Framework qui s’ajoute par-dessus celui que vous connaissez déjà. Selon Microsoft, c’est la façon qui deviendra la plus recommandée lorsque viendra le temps de créer de nouveaux plugins. Pour mieux cerner son utilité, disons que vous créez un nouveau jeu de type Tetris. Vous pouvez par la suite créer de nouveaux modèles de briques qui seront distribués comme des extensions puis chargés dynamiquement. C’est le même dilemme lorsque vous désirez gérer les normes de dessin. À la base, vous n’avez aucune espèce d’idée de la façon dont la norme sera interprétée mais vous vous attendez à surveiller les calques, le texte, les blocs, etc.

Voici un excellent lien pour vous initier avec ce concept :
http://www.codeproject.com/Articles/188054/An-Introduction-to-Managed-Extensibility-Framework

La gestion des normes de dessins avec le MEF

Il est possible de contrôler des dessins à l'aide de fichiers dws et de plug-in. Par exemple, si un dessin a été modifié uniquement au niveau du texte, vous pouvez contrôler ce dessin en n'utilisant que les plug-ins de calques et de styles de texte pour gagner du temps. Par défaut, tous les plug-ins sont utilisés lors des contrôles de violations de normes. Il est également permis de créer ses propres plug-ins mais cela demande soit des programmes en ObjectARX ou soit DotNet. La programmation en ObjectARX n’est pas à la portée de tous et en plus dépend du système d’exploitation. De l’autre coté, les applications .Net peuvent évoluer beaucoup plus facilement mais vous ne voulez peut-être pas rouvrir le code à chaque fois que vous avez un nouveau client ou une nouvelle version de norme.

Étapes pour créer un plugin en DotNet
1.     Du bouton Démarrer de Windows, parcourez Programmes -> Microsoft Visual Studio 2012 -> Visual Studio Tools -> Invite de commandes de Visual Studio (2010 )

2.     À l’invite de commande, passez au répertoire inc-w32 d’ObjectARX (e.g. C:\ObjectARX\ObjectARX 2013\inc-win32
3.     Créez les 2 assembly nécessaires avec les instructions suivantes
        a. C:\ObjectARX\ObjectARX 2013\inc-win32 >tlbimp axdb19enu.tlb /out:AxDbLib.Interop.dll /namespace:AXDBLib
        b. C:\ObjectARX\ObjectARX 2013\inc-win32 >tlbimp acstmgr.tlb /out:AcStMgr.Interop.dll /namespace:AcStMgr /reference:AxDbLib.Interop.dll
4.     Fermez la fenêtre de l’invite de commande.
5.     Démarrez Visual Studio.
6.     En plus des références normales, ajoutez les 2 nouvelles que vous venez de créer
7.     Ajoutez également une référence COM à Microsoft MSXML 6.0 (se situe dans C:\Windows\system32\msxml6.dll)
8.     Créez une classe principale intitulée MyCadStandardPlugin et ajoutez l’attribut ProgId comme suit :

9.     Enregistrez votre solution en lui donnant comme nom d’assembly (Assembly name) et de racine d’espace (root namespace ) « MyCadStandardPlugin».
10.   Créez-vous un fichier MonPluginNormes.reg et ajoutez ces lignes :

11.     Exécutez ce fichier *.reg
12.     Faites l’implémentation normale de toutes les fonctions tel que le recommande le guide d’Autodesk à ce sujet.

Au final, vous venez de créer une DLL qui recevra les notifications d’ObjectARX ainsi que les 2 API COM qui font la communication les deux. Il ne manque que vos extensions MEP pour compléter la prochaine image. Ces extensions se créent assez facilement en suivant le lien précédemment indiqué. Malgré la communication à 4 couches par opposition au modèle à une seule couche (i.e. si vous aviez programmé directement en ObjectARX), le temps de réaction est très rapide. Vous bénéficiez par contre d’une plus grande flexibilité.

MEF utilise un concept de catalogue pour contenir les extensions. Ceux-ci se déclinent en 3 saveurs :
•     Assembly : les extensions sont contenues dans un DLL .Net
•     Répertoire : les extensions sont contenues dans un répertoire
•     Agrégat : le catalogue contient à la fois des répertoires et des assembly. C’est le modèle idéal puisqu’il vous permet de gérer plusieurs clients et plusieurs plugins pour chacun (calques, texte, blocs, etc.)

Windows 8 et ses impacts

.Net Framework 4.5

Il existe présentement une certaine confusion par rapport à Windows 8 et le soutien de plusieurs technologies dont le soutien du « .Net Framework 4.0 » (ci-après FW4.0). Tout d'abord, il est important de savoir que Windows 8 ne prendra pas en charge le FW4.0. Si vous avez déjà investi dans la migration de vos DLL pour AutoCAD 2013 (ou autres applications) ou prévoyez le faire sous peu, cette annonce risque de vous inquiéter quelque peu. De plus, les versions d’AutoCAD 2012 et 2013 sont elles-mêmes basées sur cette plateforme, ce qui risque d’inquiéter davantage. Heureusement, cela n’a rien à voir avec un désaveu ou de renoncement de la technologie. Microsoft n'a jamais complètement abandonné ses anciens produits si facilement (qu’on pense à VB6 et COM).

Le « .Net Framework 4.5 » (ci-après FW4.5) est un produit remplaçant totalement le FW4.0 plutôt que d’évoluer cote-à-côte comme avec les anciennes versions de Frameworks. Par contre, les FW2.0 à FW3.5 pourront continuer à évoluer côte à côte. C’est donc plus la question de l’incompatibilité entre le FW4.0 et le FW4.5 dont il est ici question et non de Windows 8. Si vous êtes encore sous Windows XP, Vista ou Windows 7, sachez que le répertoire d’installation du FW4.5 est le même que le FW4.0, soit C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Le principe ici est que le FW4.5 est pleinement rétro-compatible avec le FW4.0.

AutoLISP

Le retrait vraisemblable de la technologie des fibres aura impact prévisible sur AutoLISP comme nous l’avons cité brièvement dans notre première section. Par contre, d’ici à ce que Windows 8 sorte, il se peut bien que les choses aient évoluées. C’est donc un sujet à suivre.

Metro style App

La machine à rumeurs bat son plein. Une autre qui circule est la mort possible de Silverlight et de DotNet pour les plateformes mobiles. Est-ce qu’il faut prendre cela à la légère? Disons que si vous en êtres à vouloir commencer à migrer vos applications, cela peut peut-être vous décourager. Précisons que cela ne touche pas du tout le coté Desktop Apps et il est presqu’impossible que cela change dans un horizon de 10 ans. Vous n’avez donc pas à vous inquiéter. Est-ce que ce sera aussi vrai pour vos applications Web ou mobile? On ne saurait vous répondre.

Image courtoisie de http://www.zdnet.com/blog/microsoft/microsoft-to-developers-metro-is-your-future/10611


Réponse à la question concernant l’accès aux clés de registre à la section "Références à des librairies managées d’AutoCAD":

 

 

tion_dotnet_pour_autocad_2013_fichiers/image063.png" width="879" height="84">

 

 

tml>