[Résolu] Problème de chemin relatif start.scr

[Manu.Net]

Bonjour à tous,

 

J'ai un souci dont je ne trouve pas l'origine, lors du debug de mon projet .Net j'essaye d'utiliser un chemin relatif comme indiqué par Gile pour charger le fichier start.scr :

 

..\..\bin\Debug\start.scr, mais ça ne fonctionne pas : "start.scr" Impossible de trouver le fichier.

Pourtant le fichier start.scr est bien copié dans le dossier bin/Debug et si je met le chemin en dur ça fonctionne.

J'ai exactement le même pb dans le fichier start.scr, il faut que le chemin soit en dur, sinon ça ne fonctionne pas.

Lorsque je lance le netload à la main sous Autocad, je tombe pourtant bien directement sur le dossier bin/Debug de mon projet.

J'ai essayé en créant un nouveau projet, et même en essayant d'utiliser le projet CONVPALETTE de Gile : Même Problème ! Et ceci sous AutoCAD 2016 ou 2017...

 

Je sèche...

 

Ca ne serait rien si il n'y a avait que ça, le problème c'est que ma solution comprend 2 projets et que mon deuxième projet (assembly) ne veut pas se charger pour le même problème de chemin relatif...

 

Auriez-vous une idée pour m'aider ?

 

Merci,

 

Manu

[(gile)]

Salut,

 

Dans la série "syndrome sécuritaire quand tu nous tiens ...", après les chemins approuvés (TRUSTEDPATHS), Autodesk, depuis AutoCAD 2016, nous a ajouté une nouvelle variable système LEGACYCODESEARCH qui vérifie si la recherche de fichiers exécutables prend en compte le dossier à partir duquel le programme est démarré.

Pour utiliser le chemin relatif, il faut donc vivre dangereusement en mettant LEGACYCODESEARCH à 1.

[Manu.Net]

Salut,

 

Dans la série "syndrome sécuritaire quand tu nous tiens ...", après les chemins approuvés (TRUSTEDPATHS), Autodesk, depuis AutoCAD 2016, nous a jouté une nouvelle variable système LEGACYCODESEARCH qui vérifie si la recherche de fichiers exécutables prend en compte le dossier à partir duquel le programme est démarré.

Pour utiliser le chemin relatif, il faut donc vivre dangereusement en mettant LEGACYCODESEARCH à 1.

 

Super, un grand merci Gile !

 

J'aurais dû demander avant...

 

Ca résout bien mes problèmes de start.scr, mais malheureusement pas ceux de ma 2ème assembly (WPF.AutocadTheme.dll) qui ne veut pas se charger quand elle est déclarée dans du xaml :

 

xmlns:thm="clr-namespace:WPF.AutocadThemes;assembly=WPF.AutocadThemes"

 

Mais qui se charge si j'utilise du code avec un using classique et l'appel à une classe, ou alors en xaml dans une application WPF classique hors Autocad.

 

Tu as déjà rencontré ce problème ?

Détail de l'exception:

 

Exception levée : 'System.Windows.Markup.XamlParseException' dans PresentationFramework.dll

 

Informations supplémentaires : Impossible de charger le fichier ou l'assembly 'WPF.AutocadThemes, PublicKeyToken=null' ou une de ses dépendances. Le fichier spécifié est introuvable.

[Manu.Net]

C'est le même problème que dans ce post :

 

https://forums.autodesk.com/t5/net/load-error-dll-s-called-by-my-dll-plugin-in-2015-2014-and-2013/td-p/6394517

 

Le problème n’apparaît que si on utilise l'assembly en xaml uniquement

 

Il y a moyen de contourner le pb en faisant un using et en instanciant un objet quelconque de l'assembly dans le constructeur de la CommandClass par exemple, mais bon, c'est bof bof... <_<

 

Des idées ?

[Manu.Net]

Je me répond à moi-même car j'ai pu avancer grâce au détail de l'exception :

 

=== Informations d'état de liaison préalable ===

JRN : DisplayName = WPF.AutocadThemes, PublicKeyToken=null

(Partial)

AVT : des informations de liaison partielle ont été fournies pour un assembly :

AVT : Nom d'assembly : WPF.AutocadThemes, PublicKeyToken=null | ID de domaine : 1

AVT : une liaison partielle se produit lorsqu'une partie seulement du nom complet de l'assembly est fournie.

AVT : cela peut entraîner le chargement d'un assembly erroné par le classeur.

AVT : il est recommandé de fournir une identité textuelle complètement spécifiée pour l'assembly,

AVT : qui comprend le nom simple, la version, la culture et le jeton de clé publique.

AVT : pour plus d'informations et pour obtenir des solutions à ce problème, consultez le livre blanc à l'adresse suivante http://go.microsoft.com/fwlink/?LinkId=109270.

JRN : Appbase = file:///C:/Program Files/Autodesk/AutoCAD 2016/

JRN : PrivatePath initial = NULL

Assembly appelant : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.

===

JRN : cette liaison démarre dans le contexte de chargement de default.

JRN : utilisation du fichier de configuration de l'application : C:\Program Files\Autodesk\AutoCAD 2016\acad.exe.Config

JRN : utilisation du fichier de configuration d'hôte :

JRN : utilisation du fichier de configuration de l'ordinateur à partir de C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.

JRN : stratégie non appliquée à la référence à ce stade (liaison d'assembly privée, personnalisée, partielle ou basée sur l'emplacement).

JRN : tentative de téléchargement de la nouvelle URL file:///C:/Program Files/Autodesk/AutoCAD 2016/WPF.AutocadThemes.DLL.

JRN : tentative de téléchargement de la nouvelle URL file:///C:/Program Files/Autodesk/AutoCAD 2016/WPF.AutocadThemes/WPF.AutocadThemes.DLL.

JRN : tentative de téléchargement de la nouvelle URL file:///C:/Program Files/Autodesk/AutoCAD 2016/WPF.AutocadThemes.EXE.

JRN : tentative de téléchargement de la nouvelle URL file:///C:/Program Files/Autodesk/AutoCAD 2016/WPF.AutocadThemes/WPF.AutocadThemes.EXE.

 

Et à ce post :

 

http://forums.autodesk.com/t5/net/autocad-2015-dll-configuration-file-read-error/td-p/5437852

 

Dans ce cas particulier, Autocad va chercher à charger l'assembly depuis son dossier d'install : C:/Program Files/Autodesk/AutoCAD 2016/ ou depuis un sous dossier du nom de l'assembly

 

Il reste donc comme solutions :

 

- Soit de copier l'assembly dans le dossier d'install d'AutoCAD (j'ai testé ça fonctionne) ou à priori dans un sous dossier portant le nom de l'assembly

- Soit d'utiliser la solution de contournement dont je parlais plus haut

- Soit de faire un netload préalable de cette assembly

 

Bref, rien de très satisfaisant mais à priori ce sont les seules solutions simples

 

Manu

[(gile)]

Juste une question, WPF.AutocadThemes.dll est elle bien dans les références du projet principal avec la propriété Copie Local à True ?

[Manu.Net]

Juste une question, WPF.AutocadThemes.dll est elle bien dans les références du projet principal avec la propriété Copie Local à True ?

 

Oui, et la copie se fait bien dans le dossier de sortie bin/Debug

[(gile)]

Re,

 

Confronté au même problème avec un contrôle personnalisé j'ai opté pour l'option du NETLOAD dans une classe qui implémente IExtensionApplication :

 

    public class Initialization : IExtensionApplication
   {
       public void Initialize()
       {
           AcAp.Idle += AcAp_Idle;
       }

       private void AcAp_Idle(object sender, EventArgs e)
       {
           var doc = AcAp.DocumentManager.MdiActiveDocument;
           if (doc != null)
           {
               AcAp.Idle -= AcAp_Idle;
               doc.SendStringToExecute("(command \"netload\" \"CustomControls.dll\") ", false, false, false);
           }
       }

       public void Terminate() { }
   }

[Manu.Net]

Intéressante cette interface, merci pour l'info