Visual Studio中的HintPath与ReferencePath

到底是什么之间的区别HintPath在.csproj的文件和ReferencePath一个.csproj.user文件？我们正在尝试遵循一个约定，其中依赖项DLL位于“发布” svn存储库中，并且所有项目都指向特定的发布。由于不同的开发人员具有不同的文件夹结构，因此相对引用将不起作用，因此我们提出了一种方案，该方案使用指向特定开发人员的releases文件夹的环境变量来创建绝对引用。因此，在添加引用之后，我们可以手动编辑项目文件以使用环境变量将引用更改为绝对路径。

我注意到，可以同时使用HintPath和和来完成此操作ReferencePath，但是我只能发现它们之间的唯一区别HintPath是在构建时以及ReferencePath将项目加载到IDE中时已解决。我不太确定那是什么后果。我注意到VS有时会重写，.csproj.user而我必须重写ReferencePath，但是我不确定是什么触发了它。

我听说最好不要检入该.csproj.user文件，因为它是特定于用户的，因此我希望以此为目标，但是我也听说HintPath-指定的DLL不能“保证”在以下情况下加载：例如，相同的DLL位于项目的输出目录中。有什么想法吗？

根据这个MSDN博客： https //blogs.msdn.microsoft.com/manishagarwal/2005/09/28/resolving-file-references-in-team-build-part-2/

生成装配时有一个搜索顺序。搜索顺序如下：

• 当前项目中的文件-由$ {CandidateAssemblyFiles}表示。
• 来自.user / targets文件的$（ReferencePath）属性。
• 参考项目指示的％（HintPath）元数据。
• 目标框架目录。
• 在使用AssemblyFoldersEx注册的注册表中找到目录。
• 已注册的程序集文件夹，以$ {AssemblyFolders}表示。
• $（OutputPath）或$（OutDir）
• 广汽集团

因此，如果所需的组件由发现HintPath，但替代的组件可以使用发现ReferencePath，它会更喜欢ReferencePath “组件d的HintPath ” d之一。

在文件Microsoft.Common.targets中查找

问题的答案在Microsoft.Common.targets目标框架版本的文件中。

对于.Net Framework 4.0版（和4.5版！），AssemblySearchPaths-element的定义如下：

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

对于.Net Framework 3.5，定义相同，但是注释错误。2.0的定义稍有不同，它使用$（OutputPath）代替$（OutDir）。

在我的机器上，我具有以下版本的文件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

Windows 7上安装了Visual Studio 2008、2010和2013。

搜索输出目录的事实可能有点令人沮丧（正如原始发布者指出的那样），因为它可能隐藏了不正确的HintPath。该解决方案在您的本地计算机上可以正常构建，但是在干净的文件夹结构（例如，在构建计算机上）上构建时会中断。

我自己的经验是，最好坚持两种汇编引用之一：

• 当前构建目录中的“本地”程序集
• GAC中的程序集

我发现（很像您描述的）其他方法太容易被破坏或有烦人的维护要求。

我不需要GAC的任何程序集都必须位于执行目录中。任何不在我的GAC执行目录中的程序集（由自动生成事件进行管理）。

到目前为止，这还没有给我带来任何问题。虽然我肯定有一种情况无法解决问题，但通常对任何问题的回答都是“哦，GAC它！”。8天

希望有帮助！

尽管这是一个旧文档，但是它帮助我解决了在另一台计算机上忽略“ HintPath”的问题。这是因为所引用的DLL也必须位于源代码控制中：

https://msdn.microsoft.com/zh-CN/library/ee817675.aspx#tdlg_ch4_includeoutersystemassemblieswithprojects

摘抄：

包括然后引用外部系统程序集
1.在解决方案资源管理器中，右键单击需要引用程序集的项目，然后单击“添加现有项”。
2.浏览到该程序集，然后单击“确定”。然后将该程序集复制到项目文件夹中，并自动添加到VSS（假设该项目已在源代码控制下）。
3.使用“添加引用”对话框中的“浏览”按钮在项目文件夹中设置对程序集的文件引用。