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.

[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.