HintPath VS Visual Studio中的ReferencePath

.csproj文件中的.csproj.user.csproj.user文件中的ReferencePath究竟有什么区别? 我们正试图提交一个约定,其中依赖关系DLL在“发布”svn库中,所有项目都指向特定版本。 由于不同的开发人员具有不同的文件夹结构,相对引用将无法工作,所以我们想出了一个scheme,使用指向特定开发人员发布文件夹的环境variables来创build绝对引用。 因此,在添加引用之后,我们手动编辑项目文件以使用环境variables将引用更改为绝对path。

我注意到这可以通过HintPathReferencePath来完成,但是我可以在它们之间find唯一的区别,就是在项目加载到IDE中时, HintPath在构build时和ReferencePath被parsing。 我真的不确定这些后果是什么。 我注意到,VS有时重写.csproj.user ,我不得不重写ReferencePath ,但我不知道是什么触发。

我听说最好不要检查.csproj.user文件,因为它是用户特定的,所以我想HintPath ,但我也听说HintPath DLL不是“保证“,如果相同的DLL例如位于项目的输出目录中,则被加载。 对此有何想法?

4 Solutions collect form web for “HintPath VS Visual Studio中的ReferencePath”

根据这个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也需要在源代码控制中:

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

摘抄:

包括然后引用外部系统组件
 1.在解决scheme资源pipe理器中,右键单击需要引用程序集的项目,然后单击添加现有项目。
 2.浏览到程序集,然后单击确定。 然后将程序集复制到项目文件夹中并自动添加到VSS(假定项目已经在源代码pipe理下)。
 3.使用“添加引用”对话框中的“浏览”button在项目文件夹中设置对程序集的文件引用。
  • 通过Visual Studio 2010定位.NET Framework 4.5
  • 如何更改XSLTdebugging器的input文件?
  • Visual Studio 2015解决scheme向后兼容Visual Studio 2013
  • Visual Studio警告级别的含义?
  • 在Visual Studio中运行应用程序时,Access数据库的更改不会保留
  • 在Mac上的Visual Studio
  • 在IIS Express中创build虚拟目录
  • 为什么Visual Studio编辑器在空白处显示点?
  • 如何在SQL Server CE(精简版)数据库中创build外键关系?
  • 我在哪里可以findJSHint数字错误代码的列表?
  • 在Visual Studio 2017中未发现unit testing