.net - studio - que es una referencia en visual basic
HintPath vs ReferencePath en Visual Studio (4)
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:
Extracto:
To include and then reference an outer-system assembly 1. In Solution Explorer, right-click the project that needs to reference the assembly,,and then click Add Existing Item. 2. Browse to the assembly, and then click OK. The assembly is then copied into the project folder and automatically added to VSS (assuming the project is already under source control). 3. Use the Browse button in the Add Reference dialog box to set a file reference to assembly in the project folder.
¿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 repositorio 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 compilació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.
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 compilació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 compilació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!
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í:
<!--
The SearchPaths property is set to find assemblies in the following order:
(1) Files from current project - indicated by {CandidateAssemblyFiles}
(2) $(ReferencePath) - the reference path property, which comes from the .USER file.
(3) The hintpath from the referenced item itself, indicated by {HintPathFromItem}.
(4) The directory of MSBuild''s "target" runtime from GetFrameworkPath.
The "target" runtime folder is the folder of the runtime that MSBuild is a part of.
(5) Registered assembly folders, indicated by {Registry:*,*,*}
(6) Legacy registered assembly folders, indicated by {AssemblyFolders}
(7) Resolve to the GAC.
(8) Treat the reference''s Include as if it were a real file name.
(9) Look in the application''s output folder (like bin/debug)
-->
<AssemblySearchPaths Condition=" ''$(AssemblySearchPaths)'' == ''''">
{CandidateAssemblyFiles};
$(ReferencePath);
{HintPathFromItem};
{TargetFrameworkDirectory};
{Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)};
{AssemblyFolders};
{GAC};
{RawFileName};
$(OutDir)
</AssemblySearchPaths>
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 compilación).