115 votes

HintPath vs ReferencePath dans Visual Studio

Quelle est la différence exacte entre le HintPath dans un fichier .csproj et l'option ReferencePath dans un .csproj.user fichier ? Nous essayons de nous engager dans une convention où les DLLs de dépendance sont dans un repo svn "releases" et tous les projets pointent vers une version particulière. Étant donné que les développeurs ont des structures de dossiers différentes, les références relatives ne fonctionnent pas. Nous avons donc trouvé un moyen d'utiliser une variable d'environnement pointant vers le dossier releases du développeur en question pour créer une référence absolue. Ainsi, après l'ajout d'une référence, nous modifions manuellement le fichier du projet pour changer la référence en un chemin absolu à l'aide de la variable d'environnement.

J'ai remarqué que cela peut être fait à la fois avec la fonction HintPath y el ReferencePath mais la seule différence que j'ai pu trouver entre eux est que HintPath est résolu au moment de la construction et ReferencePath lorsque le projet est chargé dans l'IDE. Je ne suis pas vraiment sûr des ramifications de cela. J'ai remarqué que VS réécrit parfois les fichiers de type .csproj.user et je dois réécrire le ReferencePath mais je ne suis pas sûr de ce qui déclenche ça.

J'ai entendu dire que c'est mieux de ne pas vérifier dans le .csproj.user puisqu'il est spécifique à l'utilisateur, et j'aimerais donc viser cet objectif, mais j'ai également entendu dire que le fichier HintPath -Il n'est pas "garanti" que la DLL spécifiée sera chargée si la même DLL se trouve, par exemple, dans le répertoire de sortie du projet. Avez-vous des idées à ce sujet ?

128voto

ajs410 Points 899

Selon ce blog MSDN http://blogs.msdn.com/manishagarwal/archive/2005/09/28/474769.aspx

Il existe un ordre de recherche pour les assemblages lors de la construction. L'ordre de recherche est le suivant :

  • Fichiers du projet en cours - indiqués par {CandidateAssemblyFiles}.
  • La propriété $(ReferencePath) qui provient du fichier .user/targets.
  • %(HintPath) métadonnées indiquées par l'élément de référence.
  • Répertoire du framework cible.
  • Répertoires trouvés dans le registre qui utilise l'enregistrement AssemblyFoldersEx.
  • Dossiers d'assemblage enregistrés, indiqués par {AssemblyFolders}.
  • $(OutputPath) ou $(OutDir)
  • CAG

Ainsi, si l'assemblage souhaité est trouvé par HintPath, mais qu'un autre assemblage peut être trouvé en utilisant ReferencePath, il préférera l'assemblage de ReferencePath à celui de HintPath.

5voto

Task Points 2160

D'après ma propre expérience, il est préférable de s'en tenir à l'un des deux types de références d'assemblage :

  • Un assemblage "local" dans le répertoire de construction actuel.
  • Un assemblage dans le GAC

J'ai trouvé (un peu comme vous l'avez décrit) que les autres méthodes étaient trop facilement cassables ou nécessitaient un entretien fastidieux.

Tout assemblage que je ne veux pas mettre dans le GAC, doit vivre dans le répertoire d'exécution. Tout assemblage qui n'est pas ou ne peut pas être dans le répertoire d'exécution doit être placé dans le GAC (géré par les événements de construction automatique).

Cela ne m'a pas posé de problème jusqu'à présent. Bien que je sois sûr qu'il y ait une situation où cela ne fonctionnera pas, la réponse habituelle à tout problème a été "oh, il suffit de le GACer !". 8 D

J'espère que cela vous aidera !

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X