Что точно является различием между HintPath
в .csproj файле и ReferencePath
в a .csproj.user
файл? Мы пытаемся согласиться на конвенцию, где зависимость, DLLs находятся в "выпуски" svn repo и все проекты, указывает на конкретный выпуск. Так как у различных разработчиков есть различные структуры папок, относительные ссылки не будут работать, таким образом, мы придумали план использовать переменную среды, указывающую на папку выпусков конкретного разработчика для создания абсолютной ссылки. Таким образом после того, как ссылка добавляется, мы вручную редактируем файл проекта для изменения ссылки на полный путь с помощью переменной среды.
Я заметил, что это может быть сделано с обоими 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/
При сборке существует порядок поиска сборок. Порядок поиска следующий:
Итак, если нужная сборка найдена с помощью HintPath , но альтернативная сборка может быть найдена с помощью ReferencePath ], он предпочтет сборку ReferencePath d сборке HintPath .
По моему собственному опыту, лучше всего придерживаться одного из двух видов ссылок на сборки:
Я обнаружил (во многом как вы описали) другие методы, которые либо слишком легко сломать, либо предъявляют раздражающие требования к обслуживанию.
Любая сборка, которую я не хочу передавать в GAC, должна находиться в каталоге выполнения. Любая сборка, которая не находится или не может находиться в каталоге выполнения I GAC (управляется событиями автоматической сборки).
Пока это не доставило мне никаких проблем. Хотя я уверен, что есть ситуация, когда это не сработает, обычный ответ на любую проблему был «о, просто GAC!». 8 D
Надеюсь, что это поможет!