Visual Studio의 HintPath 대 ReferencePath

Visual Studio의 HintPath 대 ReferencePath

---

정확히의 차이 무엇입니까 HintPath.csproj 파일과 ReferencePathA의 .csproj.user파일은? 우리는 종속성 DLL이 "릴리스"svn 저장소에 있고 모든 프로젝트가 특정 릴리스를 가리키는 규칙을 적용하려고합니다. 개발자마다 폴더 구조가 다르기 때문에 상대 참조가 작동하지 않으므로 특정 개발자의 릴리스 폴더를 가리키는 환경 변수를 사용하여 절대 참조를 만드는 체계를 마련했습니다. 따라서 참조가 추가 된 후 환경 변수를 사용하여 참조를 절대 경로로 변경하도록 프로젝트 파일을 수동으로 편집합니다.

이 작업은 HintPath및 으로 모두 수행 할 수 있지만 둘 다에서 ReferencePath찾을 수있는 유일한 차이점 HintPath은 빌드시와 ReferencePath프로젝트가 IDE에로드 될 때 해결 된다는 것입니다 . 그래도 그 결과가 무엇인지 잘 모르겠습니다. 나는 VS 가끔를 다시 쓰는 것으로 나타났습니다 .csproj.user그리고 나는를 다시 작성해야 ReferencePath하지만, 나는 확실히 그 트리거 무엇인지 모르겠어요.

.csproj.user사용자별로 파일 을 체크인하지 않는 것이 가장 좋다고 들었 으므로이를 목표로하고 싶지만, 지정된 HintPathDLL이 다음과 같은 경우로드 될 "보장"되지 않는다고 들었습니다. 동일한 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)
• GAC

따라서 HintPath 에서 원하는 어셈블리를 찾았 지만 ReferencePath를 사용하여 대체 어셈블리를 찾을 수있는 경우 HintPath 'd 어셈블리 보다 ReferencePath'd 어셈블리를 선호합니다 .

---

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 정의는 약간 다르며 $ (OutDir) 대신 $ (OutputPath)를 사용합니다.

내 컴퓨터에는 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이 설치된 경우입니다.

The fact that the output directory is searched can be a bit frustrating (as the original poster points out) because it may hide an incorrect HintPath. The solution builds OK on your local machine, but breaks when you build on in a clean folder structure (e.g. on the build machine).

---

My own experience has been that it's best to stick to one of two kinds of assembly references:

• A 'local' assembly in the current build directory
• An assembly in the GAC

I've found (much like you've described) other methods to either be too easily broken or have annoying maintenance requirements.

Any assembly I don't want to GAC, has to live in the execution directory. Any assembly that isn't or can't be in the execution directory I GAC (managed by automatic build events).

This hasn't given me any problems so far. While I'm sure there's a situation where it won't work, the usual answer to any problem has been "oh, just GAC it!". 8 D

Hope that helps!

---

Although this is an old document, but it helped me resolve the problem of 'HintPath' being ignored on another machine. It was because the referenced DLL needed to be in source control as well:

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

Excerpt:

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.

참고URL : https://stackoverflow.com/questions/1882038/hintpath-vs-referencepath-in-visual-studio