Dev Faq
11
votes

Ajout de la même référence "* .dll" à plusieurs projets dans la même solution

J'ai une solution Visual Studio 2008.NET C ++ / CLI. Ma solution consiste en de nombreux sous-projets. Je définis un répertoire de construction personnalisé pour chaque projet et l'appelé "sortie".

Ma solution:

  • myfirstProject (* .exe)
  • mysecondprject (* .dll)
  • ...
  • mynthproject (* .dll)

    Chacun du sous-projet Utilisez log4.net.so I Créer un répertoire (appelé logbinaire) et mettre log4.net DLL dans ce dossier. Ensuite, pour utiliser log4net, j'ajoute cette DLL comme référence à chacun de mon projet.

    Mais quand j'essaie de compiler mon projet principal (* .exe), j'ai eu des tonnes d'avertissement (plus de 400).

    juste un exemple:

    avertissement 110 AVERTISSEMENT C4945: "AbsoluteTimeDateDateDateDeatTateDateDateDated": ne peut pas importer le symbole de 'Certainspath \ log4net.dll': comme 'Log4Net :: DateFormatter :: AbsoluteTimeDateDateDeform' a déjà été importé à partir d'un autre assemblage 'log4net' "Quelqu'un \ log4net.dll"

    beaucoup d'avertissements avec:

    a déjà été importé d'un autre assemblage

    Pourquoi est-ce que je reçois ces avertissements? Quelqu'un a-t-il une solution pour ajouter la même DLL à plusieurs projets (sauf en utilisant GAC)?

0 commentaires

5 Réponses :

1
votes

Changer de référence sur les projets, définissez toutes les propriétés "Copier local ..." sur FALSE.

Source: http://developertips.blogspot.com/2008/ 07 / CCLI-AVERTISSEMENT-C4945.HTML

1 commentaires

Eh bien, cela ne fonctionne pas ... doit aussi faire "user ..." Propriétés faux pour référencé * .dll..mais dans cette situation, vous ne pouvez pas utiliser ce * .dll ... ce n'est pas une solution élagante mais Ce que j'ai trouvé, c'est créer un projet vide * .dll Ajouter une référence à celle * DLL (dans ma situation Ajouter log4.net DLL à ce projet factice) .Ce si souhaité utiliser cette dll (log4.net) d'un autre projet ajoutez ce mannequin Projet DLL au lieu d'une référence directe à la DLL partagée (log4.net)

0
votes

J'ai eu ce même problème. Il est causé par la situation suivante, où un projet dépend d'un autre projet: 

my_solution -> System.Xaml.dll -> System.dll
my_solution -> System.dll

3 commentaires

Cela ne fonctionne pas si vous avez (disons) 2 projets de hiérarchie à mi-hiérarchie qui ont besoin d'un accès aux projets de feuilles. Lorsque les projets de niveau intermédiaire sont inclus, vous obtenez le projet principal qui gémit que les symboles ont déjà été inclus par l'une ou l'autre.

Pas besoin de voter - votez-le lorsque vous n'avez pas fourni de solution vous-même. Après des années d'avertissement de construction, à mon travail, nous avons simplement désactivé l'avertissement de construction 4945 comme étant complètement inutile.

Mais vous n'avez pas exactement le même problème; L'OP indique que tous ses composants font également référence au projet dépendant et si c'est le cas, ce que vous avez affiché ne résoudra pas son problème. Si vous pouvez poster une réponse sur la manière de désactiver les avertissements, alors je suis upvote avec plaisir que ...

0
votes

J'ai eu le même avertissement sur cette situation: 

Solution -> Project1
Solution -> Project2 -> (Project1)
Solution -> Project3 -> (Project1, Project2)

0 commentaires
5
votes

J'ai enfin trouvé une solution à ce problème qui ne ressemble pas à un hack. J'ai trouvé la réponse dans une réponse de ' PYRO_SERV` sur le site social MSDN :

Le correctif consiste à utiliser les drapeaux "Utiliser des dépendances dans la construction" et "Utiliser dans la construction" des indicateurs sur chaque projet de projet VC (via la feuille de propriétés VC) et les basculer, le cas échéant, pour que votre cas résolve cette erreur.

Donc pour l'exemple de l'OP qui ressemble à ceci comme ceci: xxx

Le moyen d'éviter les avertissements est de définir Utiliser des dépendances dans la construction < / code> sur false pour toutes les références à proj1, proj2, .., projn .

Je viens de vérifier cela avec une solution de démonstration et cela fonctionne bien - je Je ne peux pas croire à quel point la solution est simple et combien de temps j'ai gaspillé pour le trouver!

2 commentaires

Juste FYI, j'ai récemment eu un problème similaire découlant de "dépendances d'utilisation" étant défini sur true par défaut, sauf que dans mon cas, en plus de produire les avertissements, il produisait également C3699 '^' ne peut pas utiliser cette indirection sur type 'X' ERREURS - Sauf que les types en question étaient des types gérés de manière à ce que cela aurait dû être capable de le faire. Juste au cas où quelqu'un d'autre rencontre aussi ce petit étrangeté aussi.

cette. Exactement le problème pour moi aussi sur Visual-Studio-2005. Ensemble Utiliser des dépendances dans la construction = FALSE , ajoutez les références et tout va bien. On peut noter que le utilise des dépendances dans la construction n'existe même pas dans la version vs plus récente (2010 ...)

1
votes

J'avais le même problème aujourd'hui.
Tout d'abord, grâce à Jon Cage et à l'article lié de son poste sur ce fil, voir ci-dessus (ou ci-dessous) . +1 !!! Il a résolu mon problème.

mais parce que je déteste les choses comme les basculer, le cas échéant pour votre cas , ce qui signifie que essai et erreur , j'ai fait des tests comme j'ai 2 solutions avec un bon nombre de projets C ++ / CLI dans chacun.

Voici mes conseils et mes explications:
pour tous les assemblages "auto créés" (qui ont "copier local" défini sur true):

"Propriétés communes" -> "Cadre et références" -> "Références" -> Sélectionnez une référence.
Sur la feuille de propriété à droite -> "Build Propriétés" -> "Utilisez des dépendances dans la construction"
- (copié de l'article de Forum MSDN Lield MSDN de Post de Jon Cage)

Définir ce paramètre Utilisez des dépendances dans la construction à "FALSE" en décochissant.
Cela fonctionne comme «renvoi de référence», voir exemple ci-dessous.

arrière-plan technique:
-> signifie "références"
Méthode 1:
Dans ma solution Swcore:
A.1.1 Network-> Outils , A.1.2 Réseau-> Basics .
A.2.1 Outils-> Basics .
A.3.1 Drives-> Basics , A.3.2 Drives-> Outils , A.3.3 Drives-> Réseau
A.4.1 ...
Avec "Utiliser des dépendances dans la construction" définies sur True, la référence A.1.2 peut être omise, car elle est incluse dans A.2.1.
Tous les fichiers sont créés dans Swcore \ version \
== problème:
En solution DDI:
B.1.1 DDI_HARDWARE-> DDI_JOB , B.1.2 DDI_HARDWARE-> Drives
B.2.1 DDI_JOB-> BASICS , B.2.2 DDI_JOB-> Outils , B.2.3 DDI_JOB-> Job
ddi_job est créé dans ddi \ version \ et avec "u.d.inbuild" défini sur true, il inclut basics .
ddi_hardware est créé ... et avec "u.d.inbuild" défini sur true, il comprend ddi_job-> basics .
Ddi_hardware Références également les bases de Swcore \ Livraison \
== >> double référence aux bases et aux autres. Vs voit 2 fichiers et ne peut pas comprendre qu'il s'agit du même contenu.

Méthode 2:
A.1.1 Network-> Outils , A.1.2 Réseau-> Basics .
A.2.1 Outils-> Basics .
Avec "u.d.inbuild" défini sur False, la référence A.1.2 ne peut pas être omise, car elle n'est pas transmise à partir de A.2.1.
== fonctionne, car aucun assemblage ne contiendra d'autres dépendances plus profondes, il n'y aura donc pas de conflits.

BTW: Cela vous oblige à spécifier toutes les références nécessaires pour chaque projet, vous avez donc également une vue d'ensemble ce que vous utilisez dans votre projet.

Dernières informations: Je ne peux pas dire à coup sûr si mon explication est correcte. Peut-être. sinon peut confirmer.

0 commentaires

Articles qui pourrait vous intéresser :

Authentification du canal gRPC-Web avec Blazor Webassembly via l'injection de dépendances
comment réparer "le type ou le nom de l'espace de noms" système "est introuvable s'il vous manque une directive ou une référence d'assembly (CS0246)"
Unity3D sur Ubuntu 19.10 avec vscode et extension C #: obtenez une erreur et la saisie semi-automatique ne fonctionne pas
VSTO avec .NET Core 3.0