Partager des DLL entre projets

J'ai plusieurs projets dans ma solution. Chaque projet fait référence à d'autres projets. Les dll sont assez grandes et je ne veux pas qu'elles soient incluses dans la corbeille de tous les projets qui les référencent.Partager des DLL entre projets

Quelles sont mes options? Idéalement, je voudrais les placer dans un endroit et faire référence à cela sans avoir besoin de les inclure dans mon dossier bin pour chaque projet. Le seul endroit auquel je peux penser est le GAC. Y a-t-il des idées/suggestions sur la façon dont vous vous en êtes sorti?

Est-il possible d'utiliser des chemins de palpage? Quelqu'un l'a-t-il déjà utilisé/me montre-t-il un tutoriel?

J'ai essayé de tester des chemins, d'obtenir une erreur lors de l'exécution de l'application, n'est-ce pas configuré correctement? J'ai placé mes dlls que je souhaite charger à partir de ce chemin dans le dossier C: \ Projects \ myProject \ bin. Et mettre en copie à faux dans la référence

<runtime> 
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <probing privatePath="C:\Projects\myProject\bin"/> 
    <dependentAssembly> 
    <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> 
    </dependentAssembly> 
</assemblyBinding>

Merci

Source

2013-05-17 newbie_86

Quelles sont vos préoccupations réelles avec les DLL à plusieurs endroits? Contraintes sur l'espace disque? Construire fois? Sont-ils vraiment assez gros pour que cela prenne beaucoup de temps pour les copier? – arootbeer

Pas une réponse à votre question, mais si vous voulez les avantages de ne pas avoir les assemblages dans le GAC (mettre à jour les DLL par programme plutôt que globalement, réduire les problèmes possibles) et en même temps ne pas vouloir tous ces assemblages Dans le même dossier, vous pouvez jeter un oeil à [ILMerge] (https://research.microsoft.com/fr-fr/people/mbarnett/ilmerge.aspx) qui fusionnera vos assemblées en une seule. Cependant, la surcharge d'avoir plusieurs assemblages est relativement faible. – Virtlink

Surtout l'espace disque et je veux centraliser mes DLL, donc ils sont tous dans un dossier, plutôt que partout. Le problème avec les mettre dans le GAC est que j'ai des dépendances sur des bibliothèques tierces, dont certaines ne sont pas fortement nommées ce qui devient un peu difficile. –

je suppose que ce que vous préférez, est en train de CopyLocal lors du référencement des assemblages dans Visual Studio

Les étapes pourraient être:

Ouvrir Solution Explorer
Faites un clic droit sur l'élément de référence (projet ou de montage
Sélectionnez Properties dans le menu contextuel.
Set CopyLocal-False (par défaut est true)

Ensuite, les références ne seront pas copiés sur votre project\bin\debug ou etc.

MISE À JOUR

Vous devez toujours copier votre dépendance au même dossier, ou GAC, ou des chemins d'exploration pour exécuter votre application.

C'est ainsi que .Net résout les références des assemblages.

Vous pouvez vous référer à How the Runtime Locates Assemblies.

UPDATE 1

MSDN Specifying an Assembly's Location

Utilisation de l'élément <probing> Le moteur d'exécution localise ensembles qui ne disposent pas d'un code de base par sondage. Pour plus d'informations sur le sondage, consultez la section Comment le moteur d'exécution recherche les assemblages. Vous pouvez utiliser l'élément dans le fichier de configuration de l'application pour spécifier les sous-répertoires que l'environnement d'exécution doit rechercher lors de la recherche d'un assemblage. L'exemple suivant montre comment spécifier les répertoires que le moteur d'exécution doit rechercher.

<configuration> 
    <runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="bin;bin2\subbin;bin3"/> 
    </assemblyBinding> 
    </runtime> 
</configuration>

L'attribut privatePath contient les répertoires que l'exécution doit rechercher des ensembles. Si l'application est située à C:\Program Files\MyApp, l'exécution recherche les assemblys qui ne spécifient pas de base de code dans C:\Program Files\MyApp\Bin, C:\Program Files\MyApp\Bin2\Subbin et C:\Program Files\MyApp\Bin3. Les répertoires spécifiés dans privatePath doivent être des sous-répertoires du répertoire de base de l'application.

Source

2013-05-27 00:40:50 terry

Essayé chemins d'essai, obtenir une erreur lors de l'exécution de l'application, voir modifier à la question pour le code d'installation, des idées quel pourrait être le problème? –

erreur est Impossible de charger le fichier ou l'assemblage 'xxx, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié. C'est dans ce dossier, presque comme si je ne regardais pas mon chemin privé –

Salut, je me suis souvenu que le chemin privé ne pouvait être que le répertoire sous le dossier actuel de votre application. Par exemple, votre app.exe est sous 'c: \ myproject \ bin \ debug', le chemin privé ne peut être que quelque chose comme' c: \ monprojet \ bin \ debug \ sous-dossier \ ' – terry

Vous pouvez ajouter des bibliothèques référencées dans le dossier de sortie de démarrage uniquement en projet:

1) Faites un clic droit sur le projet de départ "Add", "Existing Item". Ou [Shift]+[Alt]+[A] combinaison dans VS2010 avec les valeurs par défaut.

2) Changez le sélecteur de type en "All files (*)", trouvez et sélectionnez votre bibliothèque.

3) Placez le sélecteur "Ajouter" sur "Add As Link" et appuyez dessus.

4) Sélectionnez un lien ajouté à un projet et, dans la fenêtre Propriétés, réglez "Copy to Output Directory" sur "Copy always". Maintenant, chaque fois que vous construisez la solution, cette bibliothèque sera copiée dans le dossier de sortie de votre projet de démarrage.

5) Si vous souhaitez restreindre la copie de cette DLL à la sortie du projet qui l'utilise, faites un clic droit sur la référence dans ce projet et dans la fenêtre Propriétés réglez "Copy Local" sur false.

Implications:

Le seul endroit où votre dll référencé apparaîtra sera le répertoire de sortie de votre projet de démarrage.

Inconvénients:

Si vous allez changer votre projet de démarrage, vous aurez besoin d'ajouter tous les liens à nouveau.

Le répertoire de démarrage du projet dans l'Explorateur de solutions devient salissant.

Source

2013-05-20 14:35:58 astef

donc si je comprends bien, je voudrais les ajouter à un dossier central, puis les référencer comme un lien dans mon projet de démarrage, puis les référencer dans tous les autres projets, mais ne pas copier à la corbeille? Cela signifie que le projet de démarrage doit référencer toutes mes DLL? Hmmm, pas vraiment idéal ... –

Non, le projet de démarrage ne doit pas référencer toute votre DLL. Il doit seulement les ajouter au dossier de sortie. Au contraire, les autres projets doivent référencer leur DLL mais ne pas les copier dans leurs dossiers. C'est exactement ce dont vous avez besoin, je pense – astef

ne suit pas complètement, mais je vais essayer, merci, quelles sont les implications de cette approche? des inconvénients à le faire de cette façon? –

Partager des DLL entre projets

Répondre

Questions connexes