HintPath vs ReferencePath en Visual Studio

¿Cuál es exactamente la diferencia entre HintPath en un archivo .csproj y ReferencePath en un archivo .csproj.user ? Estamos tratando de comprometernos con una convención donde las DLL de dependencias están en un repository svn de “lanzamientos” y todos los proyectos apuntan a una versión particular. Como diferentes desarrolladores tienen diferentes estructuras de carpetas, las referencias relativas no funcionarán, por lo que se nos ocurrió un esquema para usar una variable de entorno que apunte a la carpeta de lanzamientos del desarrollador particular para crear una referencia absoluta. Entonces, después de agregar una referencia, editamos manualmente el archivo del proyecto para cambiar la referencia a una ruta absoluta utilizando la variable de entorno.

Me di cuenta de que esto se puede hacer tanto con HintPath como con ReferencePath , pero la única diferencia que pude encontrar entre ellos es que HintPath se resuelve en tiempo de comstackción y ReferencePath cuando el proyecto se carga en el IDE. No estoy seguro de cuáles son las ramificaciones de eso. Me he dado cuenta de que a veces VS reescribe el .csproj.user y tengo que volver a escribir ReferencePath , pero no estoy seguro de qué desencadena eso.

He oído que es mejor no registrar el archivo .csproj.user dado que es específico del usuario, por lo que me gustaría apuntar a eso, pero también he oído que HintPath DLL no está “garantizado”. “para ser cargado si la misma DLL, por ejemplo, se encuentra en el directorio de salida del proyecto. Tiene alguna idea sobre esto?

De acuerdo con este blog de MSDN: https://blogs.msdn.microsoft.com/manishagarwal/2005/09/28/resolving-file-references-in-team-build-part-2/

Hay un orden de búsqueda de ensamblajes al construir. El orden de búsqueda es el siguiente:

  • Archivos del proyecto actual: indicados por $ {CandidateAssemblyFiles}.
  • $ (ReferencePath) propiedad que proviene del archivo .user / targets.
  • Metadatos% (HintPath) indicados por elemento de referencia.
  • Target framework directory.
  • Directorios encontrados en el registro que usa el Registro de AssemblyFoldersEx.
  • Carpetas de conjunto registradas, indicadas por $ {AssemblyFolders}.
  • $ (OutputPath) o $ (OutDir)
  • GAC

Por lo tanto, si HintPath encuentra el ensamblaje deseado, pero se puede encontrar un ensamblaje alternativo utilizando ReferencePath , preferirá el ensamblaje ReferencePath ‘d al HintPath ‘ d one.

Mire en el archivo Microsoft.Common.targets

La respuesta a la pregunta se encuentra en el archivo Microsoft.Common.targets para su versión de marco de destino.

Para .Net Framework versión 4.0 (y 4.5!) El elemento AssemblySearchPaths se define así:

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

Para .Net Framework 3.5 la definición es la misma, pero el comentario es incorrecto. La definición 2.0 es ligeramente diferente, usa $ (OutputPath) en lugar de $ (OutDir).

En mi máquina tengo las siguientes versiones del archivo 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 

Esto es con Visual Studio 2008, 2010 y 2013 instalados en Windows 7.

El hecho de que se busque el directorio de salida puede ser un poco frustrante (como lo señala el póster original) porque puede ocultar un HintPath incorrecto. La solución crea OK en su máquina local, pero se rompe cuando se construye en una estructura de carpeta limpia (por ejemplo, en la máquina de comstackción).

Mi propia experiencia ha sido que lo mejor es apegarse a uno de los dos tipos de referencias de ensamblaje:

  • Un ensamblado ‘local’ en el directorio de comstackción actual
  • Una asamblea en el GAC

He encontrado (al igual que usted ha descrito) que otros métodos se rompen con demasiada facilidad o tienen requisitos de mantenimiento molestos.

Cualquier ensamblado que no quiera GAC, tiene que vivir en el directorio de ejecución. Cualquier ensamblado que no esté o no pueda estar en el directorio de ejecución I GAC (administrado por eventos automáticos de comstackción).

Esto no me ha dado ningún problema hasta ahora. Aunque estoy seguro de que hay una situación en la que no funcionará, la respuesta habitual a cualquier problema ha sido “¡oh, solo GAC!”. 8 D

¡Espero que ayude!

Aunque este es un documento antiguo, pero me ayudó a resolver el problema de ‘HintPath’ que se ignora en otra máquina. Fue porque la DLL referenciada también tenía que estar en control de fuente:

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

Extracto:

 Para incluir y luego hacer referencia a un conjunto de sistema externo
 1. En el Explorador de soluciones, haga clic con el botón derecho en el proyecto que necesita hacer referencia al conjunto, y luego haga clic en Agregar elemento existente.
 2. Busque el ensamblaje y luego haga clic en Aceptar.  El ensamblaje luego se copia en la carpeta del proyecto y se agrega automáticamente a VSS (suponiendo que el proyecto ya esté bajo control de fuente).
 3. Use el botón Examinar en el cuadro de diálogo Agregar referencia para establecer una referencia de archivo para ensamblar en la carpeta del proyecto.