HintPath vs ReferencePath in Visual Studio

Question

Was genau ist der Unterschied zwischen HintPath in einer .csproj-Datei und der ReferencePath in einer .csproj.user Datei? Wir versuchen, uns auf eine Konvention festzulegen, bei der Abhängigkeits-DLLs in einem "Releases" -svn-Repository gespeichert sind und alle Projekte auf ein bestimmtes Release verweisen. Da verschiedene Entwickler unterschiedliche Ordnerstrukturen haben, funktionieren relative Verweise nicht, daher haben wir ein Schema entwickelt, das eine Umgebungsvariable verwendet, die auf den Veröffentlichungsordner des jeweiligen Entwicklers zeigt, um eine absolute Referenz zu erstellen. Nachdem eine Referenz hinzugefügt wurde, bearbeiten wir die Projektdatei manuell, um den Verweis auf einen absoluten Pfad mithilfe der Umgebungsvariablen zu ändern.

Ich habe bemerkt, dass dies sowohl mit dem HintPath getan werden kann und die ReferencePath, aber der einzige Unterschied, den ich zwischen ihnen finden könnte, ist, dass HintPath zur Build-Zeit aufgelöst wird und ReferencePath, wenn das Projekt in die IDE geladen wird. Ich bin mir nicht sicher, was die Konsequenzen davon sind. Ich habe bemerkt, dass VS manchmal die .csproj.user umschreibt und ich die ReferencePath umschreiben muss, aber ich bin mir nicht sicher, was das auslöst.

Ich habe gehört, dass es am besten ist, nicht in der .csproj.user Datei einzuchecken, da es benutzerspezifisch ist, also möchte ich darauf zielen, aber ich habe auch gehört, dass die HintPath -spezifizierte DLL nicht ist " garantiert "geladen werden, wenn die gleiche DLL zB ist befindet sich im Ausgabeverzeichnis des Projekts. Irgendwelche Gedanken dazu?

Answer 1

Nach diesem Blog MSDN: https://blogs.msdn.microsoft.com/manishagarwal/2005/09/28/resolving-file-references-in-team-build-part-2/

Es gibt einen Suchauftrag für Baugruppen beim Bau. Die Suchreihenfolge lautet wie folgt:

• Dateien aus dem aktuellen Projekt - angezeigt durch $ {CandidateAssemblyFiles}.
• $ (ReferencePath) -Eigenschaft, die von .user/targets-Datei stammt.
• % (HintPath) Metadaten, die durch das Referenzelement angegeben werden.
• Ziel-Framework-Verzeichnis.
• Verzeichnisse gefunden in der Registrierung, die AssemblyFoldersEx Registration verwendet.
• Registrierte Assembly-Ordner, angezeigt durch $ {AssemblyFolders}.
• $ (OutputPath) oder $ (OutDir)
• GAC

Also, wenn die gewünschte Anordnung von HintPath, gefunden wird, aber eine alternative Baugruppe kann mit ReferencePath gefunden wird, wird es vorziehen die ReferencePath 'd Montage an die HintPath' d ein.

Answer 2

Meine eigene Erfahrung ist, dass es am besten zu einem von zwei Arten von Montag Referenzen haften:

• A ‚lokaler‘ Montag im aktuellen Build-Verzeichnis
• Eine Assembly im GAC

Ich habe (wie du es beschrieben hast) andere Methoden gefunden, entweder zu leicht kaputt zu sein oder lästige Wartungsanforderungen zu haben.

Jede Assembly, die ich nicht zu GAC, muss im Ausführungsverzeichnis leben. Eine Assembly, die sich nicht im Ausführungsverzeichnis I GAC befindet oder nicht enthalten kann (wird von automatischen Erstellungsereignissen verwaltet).

Das hat mir bisher keine Probleme bereitet. Während ich sicher bin, dass es eine Situation gibt, in der es nicht funktioniert, war die übliche Antwort auf jedes Problem "Oh, nur GAC it!". 8 D

Hoffe, dass hilft!

Answer 3

Blick in der Datei Microsoft.Common.targets

Die Antwort auf die Frage ist in der Datei Microsoft.Common.targets für Ihr Ziel Framework-Version.

Für .Net Framework Version 4.0 das AssemblySearchPaths-Element wie folgt definiert ist (und 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> 

Für .Net Framework 3.5 die Definition ist die gleiche, aber der Kommentar ist falsch. Die 2.0-Definition ist etwas anders, es verwendet $ (OutputPath) anstelle von $ (OutDir).

Auf meinem Rechner habe ich die folgenden Versionen der Datei 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 

Dies ist mit Visual Studio 2008, 2010 und 2013 installiert auf Windows 7.

Die Tatsache, dass Die Suche im Ausgabeverzeichnis kann ein wenig frustrierend sein (wie das ursprüngliche Poster zeigt), weil es einen falschen HintPath verbergen könnte. Die Lösung baut auf Ihrem lokalen Computer auf, bricht jedoch beim Erstellen in einer sauberen Ordnerstruktur (z. B. auf dem Buildcomputer) ab.

Answer 4

Obwohl dies ein altes Dokument ist, aber es half mir das Problem zu lösen, dass "HintPath" auf einem anderen Rechner ignoriert wurde. Es wurde, weil die referenzierte DLL benötigt als auch in der Quellcodeverwaltung sein:

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

Auszug:

 
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.