Modèle C# ou VB pour Visual Studio Express

[(gile)]

Salut,

 

J'ai posté deux tutoriels sur AUGIfr (et aussi sur gileCAD).

L'objectif de ces tutoriels est de montrer comment créer un modèle pour démarrer un nouveau projet C# ou VB pour AutoCAD dans Visual Studio Express permettant de lancer automatiquement AutoCAD en chargeant la DLL depuis Visual Studio en mode Debug

 

Ça peut sembler une porte ouverte enfoncée dans la mesure où Autodesk fournit des assistants (AutoCAD 2013 DotNet Wizards et AutoCAD 2010-2012 DotNet Wizards sur cette page)

Mais avec ces assistants, il faut supprimer quantité de lignes de code dans celui créé automatiquement et ils ne chargent automatiquement pas la DLL au lancement d'AutoCAD.

 

Par ailleurs, je pense que se faire ses propres modèles permet de cibler plus précisément ses besoins (type de projet, version ciblée, ...) et peut-être aussi d'un peu mieux comprendre le fonctionnement de Visual Studio et le processus de génération d'un projet .NET.

[GEGEMATIC]

Salut,

J'aime bien les modèles Autodesk car ils intègrent des exemples pour l'initialisation, la définition de commandes ou de commande lisp etc...

 

Mais j'ai commencé avec ton tutoriel pour la création de son propre modèle,

et je trouve que ça m'a beaucoup apporté en terme de compréhension et de démystification d'un projet visual studio.

 

Donc je recommande à tous de commencer par là.

 

Pour compléter ton billet, j'ai commencé un récapitulatif sur la documentation .net, je vais le poster sous peu ...

[(gile)]

Salut,

 

Merci.

 

J'aime bien les modèles Autodesk car ils intègrent des exemples pour l'initialisation, la définition de commandes ou de commande lisp etc...

C'est justement ce que je leur reprocherais, si tu veux faire une fonction LISP par exemple, tu commences par supprimer tout le code (et les commentaires) inutile dans la classe myCommands.vb ainsi que la classe myPlugin.vb. Idem pour une commande ou une extension d'application.

Je préfère avoir plusieurs modèles correspondant à des types de projets précis avec les ébauches de code adéquates.

 

De plus, avec le modèle Autodesk, quand tu lances un débogage, la DLL n'est pas chargée automatiquement comme elle l'est avec ceux fait en suivant ces tutoriels.

[GEGEMATIC]

 

C'est justement ce que je leur reprocherais, si tu veux faire une fonction LISP par exemple, tu commences par supprimer tout le code (et les commentaires) inutile dans la classe myCommands.vb ainsi que la classe myPlugin.vb. Idem pour une commande ou une extension d'application.

Je préfère avoir plusieurs modèles correspondant à des projets précis avec les ébauches de code correspondant.

 

De plus, avec le modèle Autodesk, quand tu lances un débogage, la DLL n'est pas chargée automatiquement comme elle l'est avec ceux fait en suivant ces tutoriels.

 

Ces modèles Autodesk, je les vois plus comme des tutos, c'est vrais que commencer à chaque fois un projet avec eux, ce serait un peu lourd.

Mais pour beaucoup, qui comme moi sont encore dans le bac à sable, il peuvent servir de guide pour faire des tests ...

 

Pour le débogage, il n'ont effectivement pas le chargement de la dll.

 

Concrètement, ce que je fait, c'est que j'ouvre les feuille .vb ou .cs d'autres projet avec N++, pour ne pas me mélanger les pinceaux, et je copie les parties qui m’intéressent dans visual studio.

[krunch]

Bonjour

 

Je reviens sur le démarrage car en fait je n'ai pas compris le processus général et je perds pas mal de temps à cause de ça ...

 

Alors voilà comment ça se passe :

- je crée un projet depuis le modèle fabriqué grâce au tuto de (gile)

- dans les Properties je renomme le Nom de l'assembly

- dans le start.scr je mets le même nom, mais avec le chemin complet car il n'est pas forcément à l'endroit initial (c'est ça ?)

- là dessus quand je génère la solution avec Démarrer, VS lance AutoCad mais il ne trouve pas 'start.scr'..

 

Donc je dois faire un Netload, mais ce n'est pas très grave ..

 

Ce qui est pénible c'est que le mode Debug passe le projet VS en lecture seule, du coup comment faites vous pour les allers-retours ?

Quand on n'est pas en mode Debug c'est la .dll qui est en lecture seule (chargée) donc VS ne peut pas la re-écrire, et le problème c'est qu'apparemment on ne peut pas décharger la .dll dans AutoCad pour pouvoir la régénérer ??

 

Bref comment fait-on si on a un fichier test sur lequel on veut charger-décharger la dll pour la régénérer et la tester au fur et à mesure de l'avancement ??

[(gile)]

Salut,

 

- je crée un projet depuis le modèle fabriqué grâce au tuto de (gile)

- dans les Properties je renomme le Nom de l'assembly

Normalement, tu nommes ton projet (assembly) dans la boite de démarrage de Visual Studio après avoir choisi le modèle et Visual Studio utilise ce nom comme nom d'assembly et espace de nom par défaut.

 

 

- dans le start.scr je mets le même nom, mais avec le chemin complet car il n'est pas forcément à l'endroit initial (c'est ça ?)

Tu n'as pas besoin de mettre le chemin complet, si tu as correctement fait ton modèle, le fichier script et la DLL sont dans le même répertoire (..\..\bin\Debug\)

 

 

- là dessus quand je génère la solution avec Démarrer, VS lance AutoCad mais il ne trouve pas 'start.scr'..

 

Donc je dois faire un Netload, mais ce n'est pas très grave ..

C'est que le fichier start.scr n'est pas copié dans le répertoire bin\Debug. Assure toi que la propriété "Copier dans le répertoire de sortie" du fichier start.scr est bien à : "Toujours copier" (c'est un des principaux avantage de ces modèles par rapport à ceux fournis par Autodesk, autant le faire comme il faut).

 

 

Ce qui est pénible c'est que le mode Debug passe le projet VS en lecture seule, du coup comment faites vous pour les allers-retours ?

On n'est plus en LISP (ou VBA) avec un éditeur intégré à AutoCAD mais avec un éditeur externe et du code compilé, donc le débogage lance AutoCAD et charge une DLL mais on ne peut pas décharger une DLL sans terminer la session. Pour modifier le code, il faut donc fermer AutoCAD, modifier le code dans Visual Studio et relancer le débogage (d'où l'intérêt d'un script qui se lance au démarrage pour charger la DLL).

Avec les systèmes 32 bits il y a une option "Modifier et Continuer" qui permet, s'il y a un point d'arrêt dans le code, de modifier le code pendant le débogage et de continuer l'évaluation. mais cette option ne fonctionne pas avec les systèmes 64 bits.

 

PS : Il y a une "pétition" pour demander à Microsoft de rendre accessible l'option "Edit and Continue" sur les systèmes 64 bits ici.

[krunch]

Normalement, tu nommes ton projet (assembly) dans la boite de démarrage de Visual Studio après avoir choisi le modèle et Visual Studio utilise ce nom comme nom d'assembly et espace de nom par défaut.

Alors je mets le nom dans la fenêtre Nouveau projet (celle où on choisit le modèle), il est copié dans le champ 'Nom de la solution', mais le nom de l'espace de nom de 'commands.cs' et celui de l'assembly restent le nom du modèle...

 

C'est que le fichier start.scr n'est pas copié dans le répertoire bin\Debug ..

Le script est bien copié dans Debug (l'option est sur 'Toujours copier'), mais AutoCAD ne trouve pas start.scr .. C'est censé marcher qqsoit l'emplacement du projet ?

 

Pour le reste c'est bien ce que je craignais (j'ai voté !) ..

 

Alors l'intérêt du script pourrait être aussi d'ajouter un open "MonFichiertest.dwg" avant le Netload ?

[(gile)]

Alors je mets le nom dans la fenêtre Nouveau projet (celle où on choisit le modèle), il est copié dans le champ 'Nom de la solution', mais le nom de l'espace de nom de 'commands.cs' et celui de l'assembly restent le nom du modèle...

C'est très curieux, je viens de refaire un essai avec la version Express et le nom de solution est bien pris comme nom pour l'assembly et l'espace de nom par défaut. Et c'est bien l'espace de nom de la classe Commands.

 

 

 

 

As-tu bien laissé les paramètre par défaut dans Visual Studio ?

 

 

Le script est bien copié dans Debug (l'option est sur 'Toujours copier'), mais AutoCAD ne trouve pas start.scr .. C'est censé marcher qqsoit l'emplacement du projet ?

C'est censé fonctionner en mode débogage (Menu DÉBOGUER -> Démarrer le débogage ou F5) avec comme chemin de sortie : bin\Debug pour le mode Debug (Propriétés du projet -> onglet Générer).

Avec ces paramètres la DLL est lancée depuis le répertoire bin\Debug dans lequel se trouve le fichier start.scr. Comme AutoCAD est lancé depuis ce répertoire par Visual Studio, ce répertoire se trouve être le premier dans ses chemins de recherche.

Vérifie aussi les chemins relatifs dans le fichier .csproj (ou .vbproj) de ton modèle :

<StartArguments>/nologo /b "..\..\bin\Debug\start.scr"</StartArguments>

[krunch]

Non c'est vrai que je n'ai pas le même comportement avec le nom de l'assembly et de l'espace de nom, et je n'ai changé aucun paramètres...

 

Sinon j'ai bien bin\Debug\ dans Propriétés du projet -> onglet Générer

 

Par contre j'ai un truc qui ne doit pas convenir dans l'onglet Déboguer - Arguments de la ligne de commande : /nologo /b "un_dossier_que_j'ai_supprimé_depuis\ACad Cs2010\ACad Cs2010\bin\Debug\start.scr"

 

Et quant aux chemins relatifs je ne sais pas où ça se trouve dans le .csproj du modèle ...

 

Ça peut être 'Arguments de la ligne de commande' ? Sinon on va pas s'enquiquiner, je refais le modèle à zéro ça paraît plus simple ..

[(gile)]

Quand tu as fait ton modèle, si tu as bien suivi le tuto, tu as modifié le fichier AcadCs2013.csproj (fichier de projet MsBuild) pour y ajouter les instructions dans le nœud PropertyGroup correspondant à la génération en mode Debug qui lancent AutoCAD (StartProgram) et le script (StartArguments) au démarrage. Après ça, tu n'as plus à modifier "Arguments de la ligne de commande" (c'est fait avec le nœud StartProgram).

 

Dans tous les cas, pour que ça fonctionne, le chemin pour le script (StartArguments/Arguments de la ligne de commande) doit être :

"..\..\bin\Debug\start.scr"

et celui de la dll dans le script :

"..\..\bin\Debug\.dll"

[krunch]

Ok, c'était donc bien ça et ça venait du nœud StartProgram ..

 

Ça marche maintenant avec les nouveaux projets (à part le nom de l'assembly et d'espace qui ne suivent pas mais ce n'est pas grave).

 

Pour info j'ai dézippé, modifié, supprimé le zip et laissé comme ça .. ça marche aussi avec un modèle non zippé.

 

Merci encore

 

-------------------------

A part ça je confirme, quand on a un fichier test il est quand même bien pratique d'ajouter son ouverture dans le script :

_open "chemin\fichier_test.dwg"   (sans espace après le ")
netload "..\..\bin\Debug\nom_dll" (avec espace)

[Maxence DELANNOY]

Avec les systèmes 32 bits il y a une option "Modifier et Continuer" qui permet, s'il y a un point d'arrêt dans le code, de modifier le code pendant le débogage et de continuer l'évaluation. mais cette option ne fonctionne pas avec les systèmes 64 bits.

 

PS : Il y a une "pétition" pour demander à Microsoft de rendre accessible l'option "Edit and Continue" sur les systèmes 64 bits ici.

 

La fonction sera disponible dans Visual Studio 2013 en 64 bits :

http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/26/debugging-support-for-64-bit-edit-and-continue-in-visual-studio-2013.aspx

[OtObOx]

Salut gile,

 

un petit message de remerciement pour ton tuto. Je l'ai suivi à la lettre et ça fonctionne pour la config VS2013 et ACAD2015.

 

Reste plus qu'à comprendre le reste :P et réussir à tracer un trait dans AutoCAD :)

 

JM

[(gile)]

Bienvenue au club. :)

 

Si tu demarres avec .NET je te recommanderais tout d'abord de choisir C# plutôt que VB parce que :

 

• Tu trouveras plus d'exemples en C# qu'en VB (même si la différence commence un peu à diminuer)
  
• Tu viens du VBA (si j'ai bien compris) et il vaut mieux aborder un nouvel environnement de programmation comme quelque chose de complètement neuf et différent sans que la similarité de syntaxe ne t'incite à reproduire en .NET ce tu faisais en VBA. L'apprentissage d'une nouvelle syntaxe est vraiment infime par rapport à tout le reste.
  
• VB.net n'est pas plus facile que C# (contrairement à qu'on peut entendre parfois), il peut juste être parfois plus laxiste, ce qui, à mon sens, est plutôt un défaut. La plus grande rigueur imposée par C# deviens vite un atout dans un environnement aussi vaste que .NET.
  
• Pour finir, je t'aiderais plus volontiers (lire, et plus encore écrire, du VB me donne de l'urticaire). ;)
  

 

Dans tout les cas, commence par faire des tutos dans l'environnement Windows sans te préoccuper d'AutoCAD dans un premier temps (même si c'est le but) pour t'habituer à Visual Studio et comprendre les concepts de base de .NET et de la POO.

 

Quand tu t'attaqueras à la programmation d'AutoCAD, si tu veux faire les tutos proposés par Autodesk sur cette page, commence par "AutoCAD 201X .NET Training" plutôt que par "My First Plug-in". Le premier est plus progressif et commence par des choses simples, le second me semble plus vouloir montrer ce qu'on peut faire avec une fonctionnalité (Overrule) qui, si elle est spectaculaire, n'en reste pas moins une des plus complexe de l'API AutoCAD.

 

Bon courage, et, même si on est peu nombreux, on essaye toujours de s'entr'aider sur CADxp..

[OtObOx]

Bienvenue au club. :)

 

Merci pour tes encouragements et ton aide ici et sur le forum Autodesk :)

 

Je suis assez d'accord avec toi quant à apprendre le C#, c'est plus professionnel et ça peut servir pour faire autre chose.

Malheureusement, je suis resté basic depuis mon ZX81 en 1984 puis le premier système DAO sur lequel j'ai travaillé, ME10, en 1995 et mes première macros sous Excel en 2000.

C'est donc tout naturellement que j'ai choisi le VB.net quand je me suis essayé sur VS 2010. J'ai fait quelques programmes, mais juste sous Windows (par exemple un truc qui va ranger les fichiers automatiquement dans l'arborescence du serveur suivant les standards du boulot) sans interactions avec des logiciels tiers, donc rien de bien compliqué. J'avais un peu laissé tombé, je suis un peu rouillé avec vb.net, mais j'ai quelques notions sur la POO et je sais que les automatismes du vba ne sont pas applicables à .net.

Je verrai bien par la suite si ça vaut le coup que j'apprenne un nouveau langage.

 

En parlant d'apprentissage de nouveau langage, j'ai téléchargé ton tuto LISP (je pense que c'est le tien) sur Exchange. Bravo, ça m'a donné l'envie d'aller plus loin ! Mais je vais essayer de ne pas courir deux lièvres à la fois, si je galère trop avec .net, j'essayerai de regarder le LISP, bien que ce langage de parenthèses et de réflexions récursives sont de premier abord repoussantes. Mais je ne doute pas que c'est un langage puissant, un paquet de programmeurs l'utilisent et en sont très satisfaits. D'autant plus que sur AutoCAD, ça a l'air de simplifier beaucoup de choses.

 

En tous cas, c'est chouette de rencontrer des passionnés, le monde de la programmation est un monde où on se retrouve tout seul avec soi même et ses lignes de codes. Pour ma part, quand je suis sur un problème de programmation, je ne sais plus m'arrêter, après une intense séance que creusage de neurones (je suis incapable de faire un début d’algorithme, j'ai tout dans la tête) j'en sors groogy et j'y pense jusqu'à ce que j'arrive à mes fins ! Et là, c'est bon :P

L'avantage avec l'époque du ZX81 et de ses 1 ko de mémoire extensibles à 32, c'est l'internet et ses forums où je peux rencontrer des personnes comme moi !!! (parce que la famille, elle n'y comprend rien !!)

 

Encore merci :)

 

Jean-Marc