Discussion :

[Tonlight]

Bonjour,

Je travaille sur des applications VB.NET permettant de manipuler des fichiers. J'ai plusieurs applications pour gérer différents flux (FTP, SFTP, CIFS). Pour éviter d'avoir un code trop redondant, j'ai regroupé pas mal de méthodes et fonctions dans une dll.

Le seul moyen que j'ai trouvé pour utiliser cette dll est de créer une copie locale à chaque exe dans le répertoire d'application.

Dans VS2005, dans les références du projet, j'ajoute ma dll en laissant le paramètre copie locale à True.

Dès que j'apporte une modification à ma dll, je suis donc obligé de redéployer ma dll dasn chaque répertoire ...

Je cherche donc à avoir ma dll dans un répertoire unique où tous les exe viendraient chercher la ressource.

Jusque là rien de trop compliqué, le hic est que mes exe sont exécutés sur un serveur et que je ne veux pas fournir de chemin unc (\\serveur\directory\) pour accéder à la dll.

Le chemin d'accès à la dll n'est donc pas le même quand je développe et quand l'exe sera en production.

Comment feriez-vous pour utiliser une dll dans un répertoire unique ?

[cybermaxs]

Salut,

Je suppose que tes projets ne sont pas liés entre eux dans le même, sinon ce serai trivial.

Pour le développement il existe ceci dans l'app.config

Code :

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

1
2
3
4
5
<configuration>
<runtime>
<developmentMode developerInstallation="true" />
</runtime>
</configuration>

en affectant dans la variable d'environnement DEVPATH le chemin des assemblys. Cela te permet de disposer d'un autre répertore commun.

En production, la problème est différent. Cette astuce ne doit pas être utilisée. Ne peux tu pas utiliser le GAC ? en plus, en versionnant ton assembly, tu ne risques pas d'incompatibilités.

[Tonlight]

Salut et merci de ta réponse,

Il n'y a pas de liaisons entre les projets. Ma Dll me permet de généraliser des envois de mail, de centraliser mes accès à une bd de paramétrage ... des choses comme ça.

Je ne suis pas sûr de bien comprendre l'utilité de modifier le app.config
Cela me permettrait de définir un répertoire unique pour toutes mes appli pendant ma phase de dév ?

Comment mettre à jour le chemin d'accès à ma dll quand je passe en prod.

Je n'ai jamais utiliser le GAC, tu l'as déjà utiliser ?

[cybermaxs]

Je ne suis pas sûr de bien comprendre l'utilité de modifier le app.config
Cela me permettrait de définir un répertoire unique pour toutes mes appli pendant ma phase de dév ?

oui en dév, tes applis rechercheront si elles trouvent les références.

Je n'ai jamais utiliser le GAC, tu l'as déjà utiliser ?

Ah ? Le GAC est un moyen justement de mettre à disposition un assembly sur un poste pour toutes les applis dotnet. Par exemple, l'assembly System.Data y est présente, et c'est elle que tu peux ajouter via ClicDroit sur Références.

[Tonlight]

Donc le plus simple serait de déposer ma dll dans C:\WINDOWS\Microsoft.NET\Framework\ un chemin qui doit exister sur toute bécane utilisant du .NET ?

[cybermaxs]

ce n'est pas aussi simple ...
Pour placer une assembly dans le GAC, elle doit être fortement nommée, ce qui signifie être signée avec un clé, avoir un version et une culture. Tu trouveras des exemples sur le net. C'est une opération courante.

Sinon oui, cela suffira.

[Tonlight]

Merci pour tes explications, je vais essayer.

Bon week.

[Graffito]

Ou plus simple, dans le constructeur de la Forme principale :

Code :

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

1
2
3
System.Environment.SetEnvironmentVariable("path",
   "Le_Path_de_ma_Dll1"+";"+"Le_Path_de_ma_Dll2"+";"+
    System.Environment.GetEnvironmentVariable("path"));

[Tonlight]

Définir une variable d'environnement me permettra d'accéder à mon assembly en mode production, mais je ne pourrais pas bénéficier des Imports de l'assembly lors de la compilation, non ?

Dans ma dll, j'ai définit des DataSet pour accéder à une bd (une sorte d'architecture 3-tiers).

Je peux ajouter une référence le temps du dev et après lors de la publication définir ma variable d'envirronement et supprimer ma référence ?

[cybermaxs]

Pas tout à fait.
En premier, si tu supprimes ta référence, ton projet ne compilera plus.
La résolution des références se produit très grossièrement le la sorte : pour toutes les références, le Framework recherche en premier dans le répertoire de livraison si il trouve l'assembly correspondante (nom, version, culture). Si elle n'est pas trouvée, le Framework va recherche dans le GAC avec les même paramètres. C'est la théorie.

Cependant, il y a moyen de contourner cette résolution a plusieurs endroits. En plus des méthodes évoquées dans les autres post, il y a aussi l'event AssemblyResolve de l'AppDomain en cours.

[Tonlight]

J'ai créé un projet d'installation pour intégrer mon assembly dans le GAC mais j'ai des connections strings qui sont stockés dans un fichier Monassembly.dll.config et je n'ai pas le droit d'intégrer autre chose qu'un assembly dans le GAC.

Quelle galère.

[Guulh]

Dès que j'apporte une modification à ma dll, je suis donc obligé de redéployer ma dll dasn chaque répertoire ...

Tu peux simplement recompiler chacun des projets qui fait usage de cette dll. Quand un projet P a une dépendance sur une DLL D, alors à chaque compil de P, la dernière version de D est automatiquement récupérée et copiée dans le répertoire de sortie de P. C'est tout automatique.

[Tonlight]

Ce qui m'oblige à recompiler l'ensemble de mes projets P, les redéployer, m'assurer qu'aucune modif n'a été faite dessus ....

Mon objectif premier était de me simplifier la vie en ayant ma dll à un seul endroit .

[Guulh]

Ca serait tout de même plus sûr, car sinon tu es obligé de t'assurer chaque fois que les modifs apportées restent compatibles avec les clients de la dll.

Sinon, pour revenir sur la solution qui consiste à la mettre dans la GAC : si je ne me trompe, les dll ne vont pas chercher leur config dans tadll.dll.config, mais dans la section qui va bien de tonExeClient.exe.config. Donc pas de pb de déploiement, il faut juste s'assurer que chaque exe configure correctement la dll dans son fichier de config.