HintPath по сравнению с ReferencePath в Visual Studio

Что точно является различием между HintPath в .csproj файле и ReferencePath в a .csproj.user файл? Мы пытаемся согласиться на конвенцию, где зависимость, DLLs находятся в "выпуски" svn repo и все проекты, указывает на конкретный выпуск. Так как у различных разработчиков есть различные структуры папок, относительные ссылки не будут работать, таким образом, мы придумали план использовать переменную среды, указывающую на папку выпусков конкретного разработчика для создания абсолютной ссылки. Таким образом после того, как ссылка добавляется, мы вручную редактируем файл проекта для изменения ссылки на полный путь с помощью переменной среды.

Я заметил, что это может быть сделано с обоими HintPath и ReferencePath, но единственная разница, которую я мог найти между ними, является этим HintPath разрешен во время изготовления и ReferencePath когда проект загружается в IDE. Я не действительно уверен, каковы разветвления этого все же. Я заметил, что VS иногда переписывает .csproj.user и я должен переписать ReferencePath, но я не уверен, что инициировало это.

Я услышал, что лучше не зарегистрироваться .csproj.user файл, так как это является определенным для пользователя, таким образом, я хотел бы стремиться к этому, но я также услышал что HintPath- указанный DLL, как "гарантируют", не будет загружен, если тот же DLL будет, например, расположен в выходном каталоге проекта. Какие-либо мысли об этом?

110
задан SamB 15 October 2015 в 03:05
поделиться

2 ответа

Согласно этому блогу MSDN: https: //blogs.msdn. microsoft.com/manishagarwal/2005/09/28/resolving-file-references-in-team-build-part-2/

При сборке существует порядок поиска сборок. Порядок поиска следующий:

  • Файлы из текущего проекта - обозначаются $ {CandidateAssemblyFiles}.
  • Свойство $ (ReferencePath), полученное из файла .user / target.
  • % (HintPath) метаданных, обозначенных элементом ссылки.
  • Каталог целевой платформы.
  • В реестре обнаружены каталоги, в которых используется регистрация AssemblyFoldersEx.
  • Зарегистрированные папки сборки, обозначенные $ {AssemblyFolders}.
  • $ (OutputPath) или $ (OutDir)
  • GAC

Итак, если нужная сборка найдена с помощью HintPath , но альтернативная сборка может быть найдена с помощью ReferencePath ], он предпочтет сборку ReferencePath d сборке HintPath .

123
ответ дан 24 November 2019 в 03:15
поделиться

По моему собственному опыту, лучше всего придерживаться одного из двух видов ссылок на сборки:

  • «Локальная» сборка в текущей Каталог сборки
  • Сборка в GAC

Я обнаружил (во многом как вы описали) другие методы, которые либо слишком легко сломать, либо предъявляют раздражающие требования к обслуживанию.

Любая сборка, которую я не хочу передавать в GAC, должна находиться в каталоге выполнения. Любая сборка, которая не находится или не может находиться в каталоге выполнения I GAC (управляется событиями автоматической сборки).

Пока это не доставило мне никаких проблем. Хотя я уверен, что есть ситуация, когда это не сработает, обычный ответ на любую проблему был «о, просто GAC!». 8 D

Надеюсь, что это поможет!

5
ответ дан 24 November 2019 в 03:15
поделиться