HintPath VS Visual Studio中的ReferencePath
.csproj文件中的.csproj.user和.csproj.user文件中的ReferencePath究竟有什么区别？ 我们正试图提交一个约定，其中依赖关系DLL在“发布”svn库中，所有项目都指向特定版本。 由于不同的开发人员具有不同的文件夹结构，相对引用将无法工作，所以我们想出了一个scheme，使用指向特定开发人员发布文件夹的环境variables来创build绝对引用。 因此，在添加引用之后，我们手动编辑项目文件以使用环境variables将引用更改为绝对path。
我注意到这可以通过HintPath和ReferencePath来完成，但是我可以在它们之间find唯一的区别，就是在项目加载到IDE中时， HintPath在构build时和ReferencePath被parsing。 我真的不确定这些后果是什么。 我注意到，VS有时重写.csproj.user ，我不得不重写ReferencePath ，但我不知道是什么触发。
我听说最好不要检查.csproj.user文件，因为它是用户特定的，所以我想HintPath ，但我也听说HintPath DLL不是“保证“，如果相同的DLL例如位于项目的输出目录中，则被加载。 对此有何想法？
根据这个MSDN博客： https ： //blogs.msdn.microsoft.com/manishagarwal/2005/09/28/resolving-file-references-in-team-build-part-2/
构build时有一个search组件的search顺序。 search顺序如下：
- 来自当前项目的文件 – 由$ {CandidateAssemblyFiles}指示。
- $（ReferencePath）属性来自.user / targets文件。
- 由参考项目指示的％（HintPath）元数据。
- 目标框架目录。
- 在registry中find使用AssemblyFoldersEx注册的目录。
- 已注册的程序集文件夹，由$ {AssemblyFolders}指示。
- $（OutputPath）或$（OutDir）
- GAC
因此，如果所需的程序集是由HintPathfind的，但是可以使用ReferencePathfind替代程序集，那么它将首选参考 path的程序集到HintPath 。
查看文件Microsoft.Common.targets
问题的答案是在您的目标框架版本的Microsoft.Common.targets文件中。
对于.Net Framework版本4.0（和4.5！），AssemblySearchPaths元素是这样定义的：
<!-- 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。
输出目录被search的事实可能有点令人沮丧（正如原始的海报指出的那样），因为它可能隐藏不正确的HintPath。 该解决scheme在您的本地机器上生成OK，但是当您以干净的文件夹结构（例如，在生成机器上）进行构build时会中断。
我自己的经验是，最好坚持两种assembly参考之一：
- 当前构build目录中的“本地”程序集
- GAC中的程序集
我发现（很像你所描述的）其他方法要么太容易打破，要么烦人的维护要求。
我不想要GAC的任何程序集都必须存在于执行目录中。 任何不在或不在执行目录中的程序集GAC（由自动构build事件pipe理）。
到目前为止，这并没有给我带来任何问题。 虽然我确定有一种情况是行不通的，但对于任何问题，通常的答案都是“哦，只是GAC！”。 8 D
希望有所帮助！
尽pipe这是一个旧文档，但它帮助我解决了在另一台机器上忽略“HintPath”的问题。 这是因为引用的DLL也需要在源代码控制中：
摘抄：
包括然后引用外部系统组件 1.在解决scheme资源pipe理器中，右键单击需要引用程序集的项目，然后单击添加现有项目。 2.浏览到程序集，然后单击确定。 然后将程序集复制到项目文件夹中并自动添加到VSS（假定项目已经在源代码pipe理下）。 3.使用“添加引用”对话框中的“浏览”button在项目文件夹中设置对程序集的文件引用。
