HintPath vs ReferencePath in Visual Studio

Question

Qual è esattamente la differenza tra lo HintPath in un file .csproj e lo ReferencePath in un file .csproj.user? Stiamo provando a impegnarci in una convenzione in cui le DLL di dipendenza sono in un repository svn "release" e tutti i progetti puntano a una versione specifica. Poiché diversi sviluppatori hanno strutture di cartelle diverse, i riferimenti relativi non funzioneranno, quindi abbiamo creato uno schema per utilizzare una variabile di ambiente che punta alla cartella delle versioni dello sviluppatore particolare per creare un riferimento assoluto. Quindi, dopo aver aggiunto un riferimento, modifichiamo manualmente il file di progetto per cambiare il riferimento a un percorso assoluto utilizzando la variabile di ambiente.

ho notato che questo può essere fatto sia con il HintPath e ReferencePath, ma l'unica differenza che ho trovato tra loro è che HintPath si risolve in accumulo di tempo e ReferencePath quando il progetto viene caricato nel IDE. Non sono davvero sicuro di quali siano le conseguenze di ciò. Ho notato che VS a volte riscrive lo .csproj.user e devo riscrivere lo ReferencePath, ma non sono sicuro di ciò che lo innesca.

Ho sentito dire che è meglio non fare il check in del file .csproj.user dal momento che è specifico per l'utente, quindi mi piacerebbe puntare per questo, ma ho anche sentito dire che il HintPath DLL specificate con non è " garantito "da caricare se la stessa DLL è ad es situato nella directory di output del progetto. Qualche idea su questo?

Answer 1

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

c'è un ordine di ricerca per le assemblee nella costruzione. L'ordine di ricerca è il seguente:

• File dal progetto corrente - indicato da $ {CandidateAssemblyFiles}.
• $ (ReferencePath) proprietà proveniente da .user/target file.
• % (HintPath) metadati indicati dall'elemento di riferimento.
• Directory framework di destinazione.
• Directory trovate nel registro che utilizza la registrazione AssemblyFoldersEx.
• Cartelle di assembly registrate, indicate da $ {AssemblyFolders}.
• $ (OutputPath) o $ (outdir)
• GAC

Quindi, se l'assemblea desiderato viene trovato da HintPath, ma un gruppo alternativo può essere trovato usando ReferencePath, si preferirà il ReferencePath 'd assembly al HintPath' d uno.

Answer 2

La mia esperienza è stata che è meglio attenersi a uno dei due tipi di riferimenti di montaggio:

• Un complessivo di 'locale' nella directory di compilazione corrente
• Un assembly nella GAC ​​

Ho trovato (molto come hai descritto) altri metodi per essere troppo facilmente infranti o avere fastidiosi requisiti di manutenzione.

Qualsiasi assembly che non voglio GAC, deve vivere nella directory di esecuzione. Qualsiasi assembly che non è o non può essere nella directory di esecuzione I GAC (gestito da eventi di build automatici).

Questo non mi ha dato alcun problema finora. Mentre sono sicuro che c'è una situazione in cui non funzionerà, la solita risposta a qualsiasi problema è stata "oh, solo GAC!". 8 D

Spero che questo aiuti!

Answer 3

Cercare nelle Microsoft.Common.targets di file

La risposta alla domanda è nel file Microsoft.Common.targets per la versione framework di destinazione.

Per .Net Framework versione 4.0 l'AssemblySearchPaths-elemento è definito come questo (e 4.5!):

<!-- 
    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> 

per NET Framework 3.5 La definizione è la stessa, ma il commento è sbagliato. La definizione 2.0 è leggermente diversa, utilizza $ (OutputPath) anziché $ (OutDir).

Sulla mia macchina ho le seguenti versioni dei file: 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 

Questo è con Visual Studio 2008, 2010 e il 2013 installato su Windows 7.

Il fatto che la directory di output viene cercata può essere un po 'frustrante (come fa notare il poster originale) perché potrebbe nascondere un HintPath errato. La soluzione si basa su OK sul computer locale, ma si interrompe quando si esegue il build in una struttura di cartelle pulita (ad esempio sul computer di creazione).

Answer 4

Anche se questo è un vecchio documento, ma mi ha aiutato a risolvere il problema di "HintPath" che viene ignorato su un'altra macchina. E 'stato perché la DLL di riferimento aveva bisogno di essere in controllo del codice sorgente così:

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

Estratto:

 
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.