Discussion :

[TotorLeCastor]

Bonjour à tous,

Voilà mon problème :

J'ai crée un projet de déploiement (MSI). J'y ai ajouté la sortie d'un projet de ma solution. Ce projet est dépendant de 'n' autres projets de cette même solution. Du coup, les sorties de ces projets sont ajoutés automatiquement dans le dossier d'application de mon projet d'installation.

Jusque là tout va bien. Mais j'ai eu l'envie saugrenu de voulais créer un répertoire "dll" dans mon dossier d'application. J'y déplace mes dépendances pour avoir un dossier d'application organisé.

Génération du MSI + Install du MSI = OK

Pourtant, lors du lancement de l'executation de ma sortie principale, il ne cherche pas la dépendance dans le sous répertoire créer. Un petit coup de filmon.exe m'a permis de voir qu'il cherche toujours ces dépendances dans le répertoire courant.

Comment faire pour qu'il recherche les dll dont il a besoin dans le répertoire où je les ai déplacé dans le projet de déploiement.

Merci d'avance car là je bloque depuis plus d'une journée ...

[smyley]

B
Pourtant, lors du lancement de l'executation de ma sortie principale, il ne cherche pas la dépendance dans le sous répertoire créer.

Oui en effet, c'est le comportement normal du Framework. Il n'y a que dans certains cas qu'il prend la peine de chercher dans un sous dossier (en gros, si le sous dossier porte le même nom que la dll et que la dll y es).
En gros, soit tu installes tes dlls dans le GAC soit tu triches. Comment tricher ? AppDomain.AppendPrivatePath qui est marqué Obsolete car contraire au design du Framework, mais qui est extrêmement pratique quand on a besoin de ce genre de fonctionnalités. D'ailleurs je trouve absurde de vouloir à tout prix masquer cette fonction car les seules autres solutions "fiables" sont soit le GAC qui rajoute une complexité car il faut signer l'assembly, et après batailler contre les problèmes de versions ou alors Assembly.Load et Assembly.LoadFrom qui font des problèmes encore plus étranges ou un Type ne peut parfois pas être convertible en lui même ... () et utiliser systématiquement un nouvel AppDomain (car il faut passer par le AppDomainSetup normalement) peut conduire à des problèmes où si les types ne sont pas Serializables (disons ... une fenêtre) alors ça marche pas.

[TotorLeCastor]

Alors j'ai essayé d'ajouter cette ligne au tout début de mon programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AppDomain.CurrentDomain.AppendPrivatePath(@"dll");

Sachant que toutes les fichiers dll dont mon application a besoin sont dans le répertoire de même nom (lui même présent dans mon dossier d'application).

Cependant, lors de l'exécution du programme, il ne recherche les dépendances qu'à la racine ou dans les répertoires de la racine suivant cette règle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$dossierdapplication/nomdemadll/nomdemadll.dll

Et je n'ai pas trop compris cette méthode avec AppDomainSetup ...

[smyley]

Dans AppendPrivatePath donne lui un chemin absolu, pas relatif.

[TotorLeCastor]

J'ai lu ton message hier soir à la maison et je m'étais fait une joie d'appliquer ta suggestion d'un chemin absolue. J'avais un doute sur le fait de l'avoir déjà tenté mais bon, j'y ai cru.

Et c'est donc un échec qui m'a attendu ce matin... Même avec un chemin absolue, il ne le retrouve pas à l'exécution.

Après quelques tests, voilà quelques résultats assez étranges :

Quand j'utilise le raccourci made in VS2008 (alias Advertised Shortcut), ce dernier fait des appels à explorer pour vérifier la présence de toutes mes dlls. En revanche, quand c'est au tour de mon programme, là c'est le même scénario: il cherche à la racine et dans le sous répertoire du même nom que la dll.

Et pour ce qui est raccourci maison (fabrication artisanale), là on arrive seulement aux echecs d'accès de mon programme.

C'est mot pour ça commence franchement à devenir compliqué pour par grand chose en somme ?

edit: merci à File Monitor, sans qui je serai encore plus perdu que maintenant (si si c'est possible)

[smyley]

Et si tu essayais un truc un peut différent ?
- Tu interceptes l'évènement AppDomain.AssemblyResolve qui t'indiquera une dll non trouvée et à ce moment tu la recherches toi même ...

[TotorLeCastor]

Bon finalement j'ai trouvé une solution (qui sera jusqu'à preuve du contraire LA solution)

J'ai crée un fichier XML dans le dossier d'application du même nom que mon exécutable.

exemple :
monprogramme.exe : monprogramme.config

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="subdir\subdir1;subdir\subdir2"/>
    </assemblyBinding>
  </runtime>
</configuration>

Voilà !

Merci pour ton aide smyley car sans ta participation j'aurai abandonné dans mes recherches.

edit: Merci aussi File Monitor pour m'avoir mis sur la piste de ce fichier .config