visual-studio - references - visual studio reference c#




MSBuild ne copie pas les références(fichiers DLL) si vous utilisez des dépendances de projet dans la solution (12)

J'ai quatre projets dans ma solution Visual Studio (tout le monde cible .NET 3.5) - pour mon problème, seuls ces deux sont importants:

  1. MyBaseProject <- cette bibliothèque de classes fait référence à un fichier DLL tiers (elmah.dll)
  2. MyWebProject1 <- ce projet d'application Web fait référence à MyBaseProject

J'ai ajouté la référence elmah.dll à MyBaseProject dans Visual studio 2008 en cliquant sur "Ajouter une référence ..." → onglet "Parcourir" → en sélectionnant le "elmah.dll".

Les propriétés de la référence Elmah sont les suivantes:

  • Alias ​​- global
  • Copier local - true
  • Culture -
  • Description - Erreur de journalisation des modules et des gestionnaires (ELMAH) pour ASP.NET
  • Type de fichier - Assemblage
  • Chemin d'accès - D: \ webs \ otherfolder \ _myPath \ __ tools \ elmah \ Elmah.dll
  • Résolu - Vrai
  • Version d'exécution - v2.0.50727
  • Version spécifiée - false
  • Nom fort - faux
  • Version - 1.0.11211.0

Dans MyWebProject1, j'ai ajouté la référence à Project MyBaseProject par: "Ajouter une référence ..." → onglet "Projets" → en sélectionnant "MyBaseProject". Les propriétés de cette référence sont les mêmes à l'exception des membres suivants:

  • La description -
  • Chemin d'accès - D: \ webs \ CMS \ MyBaseProject \ bin \ Debug \ MyBaseProject.dll
  • Version - 1.0.0.0

Si je cours la construction dans Visual Studio, le fichier elmah.dll est copié dans le répertoire bin de MyWebProject1 , avec MyBaseProject.dll!

Toutefois, si je nettoie et exécute MSBuild pour la solution (via D: \ webs \ CMS> C: \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ MSBuild.exe / t: ReBuild / p: Configuration = Debug MyProject.sln ) elmah.dll est manquant dans le répertoire bin de MyWebProject1 - bien que la construction elle-même ne contienne aucun avertissement ou erreur!

J'ai déjà fait en sorte que le fichier .csproj de MyBaseProject contienne l'élément private avec la valeur "true" (qui devrait être un alias pour " copy local " dans Visual Studio):

<Reference Include="Elmah, Version=1.0.11211.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\mypath\__tools\elmah\Elmah.dll</HintPath>
    **<Private>true</Private>**
</Reference>

(La balise privée n'apparaissait pas dans le fichier xml du fichier .csproj par défaut, bien que Visual Studio ait dit "copie locale" vrai.J'ai changé "copie locale" en false - sauvegardé - et l'ai redéfini sur true - save!)

Quel est le problème avec MSBuild? Comment puis-je copier la référence (elmah.dll) dans la corbeille de MyWebProject1?

Je ne veux pas ajouter une action de copie post-construction à la commande de post-construction de chaque projet! (Imaginez que de nombreux projets dépendent de MyBaseProject!)


Cela nécessite l'ajout d'un fichier .targets à votre projet et son paramétrage pour être inclus dans la section includes du projet.

Voir ma réponse ici pour la procédure.


Comme Alex Burtsev a mentionné dans un commentaire tout ce qui est seulement utilisé dans un dictionnaire de ressources XAML, ou dans mon cas, tout ce qui est seulement utilisé en XAML et pas dans le code, n'est pas considéré comme étant utilisé par MSBuild.

Il suffisait donc simplement de créer une référence factice pour une classe / un composant de l'assemblage dans un code quelconque pour convaincre MSBuild que l'assemblage était réellement utilisé.


Inclure tous les fichiers DLL référencés de vos projectreferences dans le projet Site Web n'est pas toujours une bonne idée, surtout lorsque vous utilisez l' injection de dépendances : votre projet Web veut juste ajouter une référence au fichier / projet DLL de l'interface, pas une DLL d'implémentation concrète fichier.

Parce que si vous ajoutez une référence directement à un fichier / projet DLL d'implémentation, vous ne pouvez pas empêcher votre développeur d'appeler un "nouveau" sur des classes concrètes du fichier / projet DLL d'implémentation au lieu de via l'interface. C'est aussi vous avez indiqué un "hardcode" dans votre site Web pour utiliser l'implémentation.


J'ai eu le même problème et la DLL était une référence chargée dynamiquement. Pour résoudre le problème, j'ai ajouté un "using" avec l'espace de noms de la DLL. Maintenant, la DLL est copiée dans le dossier de sortie.


J'ai eu un problème similaire aujourd'hui, et ce n'est certainement pas la réponse à votre question. Mais je voudrais informer tout le monde, et éventuellement fournir une étincelle de perspicacité.

J'ai une application ASP.NET. Le processus de construction est défini pour nettoyer, puis construire.

J'ai deux scripts Jenkins CI . Un pour la production et un pour la mise en scène. J'ai déployé mon application à la mise en scène et tout a bien fonctionné. Déployé en production et manquait un fichier DLL qui a été référencé. Ce fichier DLL était juste à la racine du projet. Pas dans un référentiel NuGet. La DLL a été définie pour do not copy .

Le script CI et l'application étaient identiques entre les deux déploiements. Toujours après le nettoyage et le déploiement dans l'environnement de transfert, le fichier DLL a été remplacé dans l'emplacement de déploiement de l'application ASP.NET ( bin/ ). Ce n'était pas le cas pour l'environnement de production.

Il s'avère dans une branche de test que j'avais ajouté une étape au processus de construction pour copier ce fichier DLL dans le répertoire bin . Maintenant, la partie qui a pris un peu de temps pour comprendre. Le processus CI ne se nettoyait pas. La DLL a été laissée dans le répertoire de travail et était accidentellement empaquetée avec le fichier ASP.NET .zip. La branche de production n'a jamais eu le fichier DLL copié de la même manière et n'a jamais été déployé accidentellement.

TLDR; Vérifiez et assurez-vous de savoir ce que fait votre serveur de construction.


J'ai juste eu exactement le même problème et il s'est avéré être provoqué par le fait que 2 projets dans la même solution faisaient référence à une version différente de la bibliothèque de 3ème partie.

Une fois que j'ai corrigé toutes les références tout a fonctionné parfaitement.


Je traite juste comme ça. Allez dans les propriétés de votre référence et faites ceci:

Set "Copy local = false"
Save
Set "Copy local = true"
Save

et c'est tout.

Visual Studio 2010 ne place pas initialement: <private>True</private> dans la balise de référence et la définition de «copy local» sur false entraîne la création de la balise. Après cela, il sera réglé sur vrai et faux en conséquence.


Je viens de rencontrer un problème très similaire. Lors de la compilation à l'aide de Visual Studio 2010, le fichier DLL était inclus dans le dossier bin . Mais lors de la compilation en utilisant MSBuild le fichier DLL tiers n'a pas été inclus.

Très frustrant. La façon dont j'ai résolu le problème consistait à inclure la référence NuGet au package dans mon projet Web, même si je ne l'utilise pas directement ici.


La modification de l'infrastructure cible du profil client .NET Framework 4 vers .NET Framework 4 a résolu ce problème pour moi.

Donc, dans votre exemple: définissez le framework cible sur MyWebProject1 sur .NET Framework 4


Le problème auquel je faisais face était d'avoir un projet qui dépend d'un projet de bibliothèque. Pour construire je suivais ces étapes:

msbuild.exe myproject.vbproj /T:Rebuild
msbuild.exe myproject.vbproj /T:Package

Cela signifiait bien sûr que je manquais les fichiers dll de ma bibliothèque dans bin et surtout dans le fichier zip du paquet. J'ai trouvé cela fonctionne parfaitement:

msbuild.exe myproject.vbproj /T:Rebuild;Package

Je n'ai aucune idée pourquoi ce travail ou pourquoi il n'a pas d'abord. Mais espérons que cela aide.


Si vous n'utilisez pas l'assembly directement dans le code, Visual Studio, tout en essayant d'être utile, détecte qu'il n'est pas utilisé et ne l'inclut pas dans la sortie. Je ne suis pas sûr pourquoi vous voyez un comportement différent entre Visual Studio et MSBuild. Vous pouvez essayer de définir la sortie de la construction sur le diagnostic pour les deux et comparer les résultats, voir où il diverge.

En ce qui concerne votre référence elmah.dll si vous ne le référencez pas directement dans le code, vous pouvez l'ajouter en tant qu'élément à votre projet et définir l'Action de construction sur Content et la Copier dans le répertoire de sortie sur Always .


Un autre scénario où cela apparaît est si vous utilisez l'ancien type de projet "Site Web" dans Visual Studio. Pour ce type de projet, il est impossible de référencer les fichiers .dll qui sont en dehors de sa propre structure de répertoires (dossier en cours et en bas). Donc, dans la réponse ci-dessus, disons que la structure de votre répertoire ressemble à ceci:

Où ProjectX et ProjectY sont des répertoires parent / enfant et ProjectX référence A.dll qui à son tour référence B.dll et B.dll est en dehors de la structure de répertoire, comme dans un package Nuget sur la racine (packages), puis A. dll sera inclus, mais B.dll ne le sera pas.





project