La DLL dépendante n'est pas copiée dans le dossier de sortie de la compilation dans Visual Studio.

Question

J'ai une solution Visual Studio. J'ai plusieurs projets dans cette solution. Il y a un projet principal qui agit comme le démarrage et utilise d'autres projets. Il y a un projet appelé "ProjectX". Sa référence est ajoutée au projet principal. Le ProjectX fait référence à une autre dll .NET (disons abc.dll) qui ne fait pas partie de la solution.

Maintenant, cette abc.dll devrait être copiée dans le dossier bin/debug du projet principal, mais elle n'y est pas copiée. Pourquoi n'est-elle pas copiée, y a-t-il des raisons connues ?

Answer 1

Dans mon cas, c'était la chose la plus stupide, causée par un comportement par défaut de TFS/VS avec lequel je ne suis pas d'accord.

Puisque l'ajout de la dll comme référence au projet principal ne fonctionnait pas, j'ai décidé de l'ajouter comme "élément existant", avec Copy Local = Always. Même dans ce cas, le fichier n'était pas là.

Il s'avère que, même si le fichier est présent dans la solution VS et que tout a été compilé à la fois localement et sur le serveur, VS/TFS n'a pas réellement ajouté le fichier au contrôle de source. Il n'était pas du tout inclus dans les "Pending Changes". J'ai dû aller manuellement dans l'explorateur de contrôle de source et cliquer explicitement sur l'icône "Ajouter des éléments au dossier".

C'est stupide parce que je développe depuis 15 ans en VS. J'ai déjà rencontré ce problème auparavant, mais je ne m'en souvenais pas et, d'une manière ou d'une autre, je l'ai manqué parce que tout compilait toujours parce que le fichier était une référence normale, mais le fichier qui a été ajouté comme élément existant n'était pas copié parce qu'il n'existait pas sur le serveur de contrôle de source.

J'espère que cela fera gagner du temps à quelqu'un, puisque j'ai perdu deux jours de ma vie à cause de cela.

Answer 2

Il s'agit d'une légère modification de l'exemple de nvirth.

internal class DummyClass
{
    private static void Dummy()
    {
        Noop(typeof(AbcDll.AnyClass));
    }
    private static void Noop(Type _) { }
}

Answer 3

Je voudrais ajouter aux événements de Postbuild de copier les bibliothèques nécessaires dans les répertoires de sortie. Quelque chose comme XCopy pathtolibraries targetdirectory

Vous pouvez les trouver dans les propriétés du projet -> Build Events.

Answer 4

TLDR ; Visual Studio 2019 peut simplement avoir besoin d'un redémarrage.

J'ai rencontré cette situation en utilisant des projets basés sur le projet Microsoft.NET.Sdk.

<Project Sdk="Microsoft.NET.Sdk">

Plus précisément :

• Project1 : cibles .netstandard2.1
  • références Microsoft.Extensions.Logging.Console via Nuget
• Project2 : cibles .netstandard2.1
  • références Project1 via une référence de projet
• Project2Tests : cibles .netcoreapp3.1
  • références Project2 via une référence de projet

Lors de l'exécution du test, j'ai reçu le message d'erreur indiquant que Microsoft.Extensions.Logging.Console n'a pas pu être trouvé, et c'était en effet no dans le répertoire de sortie.

J'ai décidé de contourner le problème en ajoutant Microsoft.Extensions.Logging.Console à Project2 pour découvrir que le gestionnaire de Nuget de Visual Studio n'a pas listé Microsoft.Extensions.Logging.Console tel qu'installé dans Project1 malgré sa présence dans le Project1.csproj fichier.

Un simple arrêt et redémarrage de Visual Studio a permis de résoudre le problème sans qu'il soit nécessaire d'ajouter une référence supplémentaire. Cela permettra peut-être à quelqu'un d'économiser 45 minutes de productivité perdue :-)

Answer 5

Vous pouvez définir à la fois le projet principal et le chemin de sortie de construction de ProjectX dans le même dossier, alors vous pouvez obtenir toutes les dlls dont vous avez besoin dans ce dossier.