Lenteur programme vb.net sur autre poste

[Hyppolight]

Bonjour,

 

Tout d'abord je tiens (pour mon premier post) tenir à remercier l'ensemble des administrateurs et autres modérateurs qui consacrent du temps à répondre à l'ensemble des questions posés sur ce site (voire d'autres sites pour certains ...)

 

Bon, après avoir essuyé ma langue (un peu de lèche ne fait pas de mal, mais il faut bien savoir se protéger...), j'en viens au vif du sujet:

 

Je suis actuellement sur un projet de développement d'édition de blocs personnalisés.

 

Le but principal étant de pouvoir gérer les propriétés dynamiques des blocs ainsi que leurs attributs depuis une boite de dialogue avec des menus déroulants. (Relevé et gestion du matériel sur des poteaux ERDF ou France Telecom sur tablette)

 

L'ensemble du programme créé fonctionne parfaitement et ne pose aucun problème sur mon propre poste.

 

Cependant, une fois la solution générée et le fichier DLL chargé sur un autre poste, je fais face à un énorme problème de lenteur.

 

En effet, une validation ou la création d'un bloc sur mon ordinateur se fait en une fraction de secondes (environ 10ms) alors que cette même opération peu prendre plus de 20s sur un autre PC.

 

J'ai tout d'abord pensé que ce problème pouvait venir d'un problème de performance des tablettes (Panasonic FZ-G1 avec AutoCAD Map 2014) mais j'ai ensuite utilisé l'ordinateur d'un collègue ayant les mêmes caractéritiques techniques que le mien et j'ai abouti au même résultat.

 

Après avoir recherché des réponses à ma question sur le NET (ca fait bientôt 3 ans que j'arrive à le faire sans pourrir les forums de questions récurrentes...) je n'ai pas trouvé de solution à ce jour.

 

Même si mes notions d'AutoCAD sont plutôt bonnes (LISP, AutoScript, CUI, FDO...), je reste un 'novice' en ce qui concerne la programmation en VB.NET et en particulier sur AutoCAD. (Formation de manière autodidacte depuis 2010 avec de bonnes connaissances VBA à la base)

 

Liste des références utilisées:

 

* AcCoreMdg.dll + AcDbMgb.dll + AcMgd.dll

(version 19.1.0.0 avec copie locale "False" depuis "C:\Autodesk\Autodesk_ObjectARX_2014_Win_64_and_32Bit\inc")

 

* ManagedMapApi.dll

(version 16.1.200.22 copie locale "False" depuis "C:\Autodesk\Autodesk_ObjectARX_2014_Win_64_and_32Bit\inc" (mais il me semble que je l'ai personnellement copier à l'intérieur)

 

* références .COM Microsoft + référence .NET System

 

Problèmes rencontrés lors d'essai de signature de l'assembly:

 

- "Il existe une différence entre l'architecture de processeur du projet en cours de génération "MSIL" et l'architecture de processeur de référence "ManagedMapApi, Version=16.1.200.22, Culture=neutral, processorArchitecture=AMD64", "AMD64". Cette différence peut entraîner des problèmes de runtime. Veuillez modifier l'architecture de processeur ciblée de votre projet à l'aide du gestionnaire de configuration de façon à aligner les architectures de processeur entre votre projet et les références, ou prendre une dépendance sur les références avec une architecture de processeur correspondant à l'architecture de processeur ciblée de votre projet."

 

- "Impossible de créer l'assembly: L'assembly référencé 'Acdbmgd' n'a pas un nom fort."

 

 

Questions :

 

- Avez-vous déjà été confronté à ce genre de problème? (lenteur suite à la génération)

 

- Peut-on référencé de manière forte 'Acdbmgd' sans détériorer le programme?

[Hyppolight]

Suite à plusieurs tests. Je viens de comprendre pourquoi le programme met autant de temps lors de son utilisation sur le terrain.

 

En test, je n'utilise pas d'Xrefs alors qu'il y en a sur le terrain.

 

Lors de l'ajout de câbles ou autre matériel, je finis par une ligne de commande "ed.regen" qui lance la régénération de l'ensemble de l'espace objet.

 

Sans d'XREF, la régénération est quasiment instantanée alors qu'elle est beaucoup plus lente lorsqu'un XREF de type fond de plan cadastrale est inséré.

 

Il va donc falloir régénérer le bloc et non l'espace objet.

[Hyppolight]

Bonjour,

 

Etant retomber sur mon message en lancant une recherche google sur "ManagedMapApi" et ayant entre temps trouver la réponse je me permets de donner la solution au problème ci-dessous au cas où certains rencontreraient le même problème:

 

- "Il existe une différence entre l'architecture de processeur du projet en cours de génération "MSIL" et l'architecture de processeur de référence "ManagedMapApi, Version=16.1.200.22, Culture=neutral, processorArchitecture=AMD64", "AMD64". Cette différence peut entraîner des problèmes de runtime. Veuillez modifier l'architecture de processeur ciblée de votre projet à l'aide du gestionnaire de configuration de façon à aligner les architectures de processeur entre votre projet et les références, ou prendre une dépendance sur les références avec une architecture de processeur correspondant à l'architecture de processeur ciblée de votre projet."

 

Contraitement au fichier AcCoreMgd.dll, AcDbMgd.dll et AcMgd.dll qui sont compatibles en version 32 Bits (x86) et 64 Bits (x64), le fichier ManagedMapApi.dll n'est compatible qu'en version 64 Bits.

 

Il faut donc accéder au gestionnaire de configurations :

 

- En développant le combobox "Debug" ou "Release" à proximité du bouton démarrer et en cliquant sur "gestionnaire de configurations".

Une fois à l'intérieur de la boite de dialogue, changer la valeur "Any CPU" de la plateforme pour la valeur "x64" (pour le debug et/ou pour le release en fonction du mode d'utilisation de votre programme)

 

Attention : Penser à modifier le fullpath du dossier dans les "chemin de recherche de fichiers de support en cours d'utilisation" et éventuellement dans "Emplacement approuvés" en fonction de la version d'AutoCAD, car le fullpath du fichier dll généré a été modifé (il passe de ...\bin\Debug (ou release) en ...\bin\x64\Debug)

 

A+