HintPath vs ReferencePath dans Visual Studio

Quelle est exactement la différence entre HintPath dans un fichier .csproj et ReferencePath dans un fichier .csproj.user ? Nous essayons de nous engager dans une convention où les DLL de dépendance se trouvent dans un référentiel svn “releases” et tous les projets pointent vers une version particulière. Étant donné que différents développeurs ont des structures de dossiers différentes, les références relatives ne fonctionnent pas. Nous avons donc créé un schéma pour utiliser une variable d’environnement pointant vers le dossier des versions du développeur particulier afin de créer une référence absolue. Donc, après avoir ajouté une référence, nous modifions manuellement le fichier du projet pour changer la référence en un chemin absolu en utilisant la variable d’environnement.

J’ai remarqué que cela peut être fait à la fois avec HintPath et ReferencePath , mais la seule différence que je pourrais trouver entre eux est que HintPath est résolu au moment de la construction et ReferencePath lorsque le projet est chargé dans l’EDI. Je ne suis pas vraiment sûr de ce que cela signifie. J’ai remarqué que VS réécrit parfois le .csproj.user et je dois réécrire le ReferencePath , mais je ne suis pas sûr de ce qui déclenche cela.

J’ai entendu dire qu’il était préférable de ne pas archiver le fichier .csproj.user car celui-ci est spécifique à l’utilisateur, donc je voudrais viser cela, mais j’ai aussi entendu que la DLL HintPath n’est pas “garantie “à charger si la même DLL est par exemple située dans le répertoire de sortie du projet. Des pensées à ce sujet?

    Selon ce blog MSDN: https://blogs.msdn.microsoft.com/manishagarwal/2005/09/28/resolving-file-references-in-team-build-part-2/

    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}.
    • $ (ReferencePath) propriété provenant du fichier .user / cibles.
    • Métadonnées% (HintPath) indiquées par élément de référence.
    • Répertoire du cadre 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)
    • GAC

    Ainsi, si l’assembly souhaité est trouvé par HintPath , mais qu’un autre assembly peut être trouvé à l’aide de ReferencePath , il préférera l’assembly ReferencePath à celui de HintPath .

    Regardez dans le fichier Microsoft.Common.targets

    La réponse à la question se trouve dans le fichier Microsoft.Common.targets à la version de votre infrastructure cible.

    Pour .Net Framework version 4.0 (et 4.5!), AssemblySearchPaths-element est défini comme suit:

        {CandidateAssemblyFiles}; $(ReferencePath); {HintPathFromItem}; {TargetFrameworkDirectory}; {Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)}; {AssemblyFolders}; {GAC}; {RawFileName}; $(OutDir)  

    Pour .Net Framework 3.5, la définition est la même, mais le commentaire est erroné. La définition 2.0 est légèrement différente, elle utilise $ (OutputPath) au lieu de $ (OutDir).

    Sur ma machine, j’ai les versions suivantes du fichier Microsoft.Common.targets:

     C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets 

    Ceci est avec Visual Studio 2008, 2010 et 2013 installé sur Windows 7.

    Le fait que le répertoire de sortie soit recherché peut être un peu frustrant (comme l’indique l’affiche originale) car il peut masquer un HintPath incorrect. La solution crée OK sur votre ordinateur local, mais se casse lorsque vous construisez dans une structure de dossiers propre (par exemple sur la machine de génération).

    Ma propre expérience a été qu’il est préférable de suivre l’un des deux types de références d’assemblage:

    • Un assembly ‘local’ dans le répertoire de construction en cours
    • Une assemblée dans le GAC

    J’ai trouvé (un peu comme vous l’avez décrit) d’autres méthodes qui soient trop facilement cassables ou qui nécessitent des opérations de maintenance ennuyeuses.

    Tout assemblage que je ne veux pas utiliser dans GAC doit vivre dans le répertoire d’exécution. Tout assemblage qui ne figure pas ou ne peut pas figurer dans le répertoire d’exécution I GAC (géré par des événements de génération automatique).

    Cela ne m’a pas posé de problème jusqu’à présent. Bien que je sois sûr que cela ne fonctionnera pas, la réponse habituelle à tout problème a été “Oh, juste GAC!”. 8 D

    J’espère que cela pourra aider!

    Bien que ce soit un ancien document, mais cela m’a aidé à résoudre le problème de “HintPath” étant ignoré sur une autre machine. C’était parce que la DLL référencée devait également être dans le contrôle de source:

    https://msdn.microsoft.com/en-us/library/ee817675.aspx#tdlg_ch4_includeoutersystemassemblieswithprojects

    Extrait:

     Pour inclure puis référencer un assemblage de système externe
     1. Dans l'Explorateur de solutions, cliquez avec le bouton droit sur le projet qui doit référencer l'assembly, puis cliquez sur Ajouter un élément existant.
     2. Accédez à l'assembly, puis cliquez sur OK.  L'assemblage est ensuite copié dans le dossier du projet et automatiquement ajouté à VSS (en supposant que le projet est déjà sous contrôle de source).
     3. Utilisez le bouton Parcourir dans la boîte de dialog Ajouter une référence pour définir une référence de fichier à l'assembly dans le dossier du projet.