В чем именно разница между HintPath
в файле .csproj и ReferencePath
в .csproj.user
файле? Мы пытаемся придерживаться соглашения, в котором библиотеки зависимостей находятся в репозитории svn «выпусков», а все проекты указывают на конкретный выпуск. Поскольку у разных разработчиков разные структуры папок, относительные ссылки работать не будут, поэтому мы придумали схему использования переменной среды, указывающей на папку релизов конкретного разработчика, для создания абсолютной ссылки. Итак, после добавления ссылки мы вручную редактируем файл проекта, чтобы изменить ссылку на абсолютный путь с помощью переменной среды.
Я заметил, что это можно сделать как с помощью, так HintPath
и с помощью ReferencePath
, но единственное различие, которое я смог найти между ними, заключается в том, что HintPath
оно разрешается во время сборки и ReferencePath
когда проект загружается в IDE. Я не совсем уверен, каковы последствия этого. Я заметил, что VS иногда переписывает, .csproj.user
и мне приходится переписывать ReferencePath
, но я не уверен, что это вызывает.
Я слышал, что лучше не проверять .csproj.user
файл, поскольку он специфичен для пользователя, поэтому я бы хотел добиться этого, но я также слышал, что HintPath
указанная DLL не "гарантированно" будет загружена, если та же DLL находится, например, в выходном каталоге проекта. Есть мысли по этому поводу?
источник
Посмотрите в файле Microsoft.Common.targets
Ответ на вопрос находится в файле
Microsoft.Common.targets
для вашей целевой версии фреймворка.Для .Net Framework версии 4.0 (и 4.5!) Элемент AssemblySearchPaths определяется следующим образом:
Для .Net Framework 3.5 определение такое же, но комментарий неверный. Определение 2.0 немного отличается, в нем используется $ (OutputPath) вместо $ (OutDir).
На моем компьютере установлены следующие версии файла Microsoft.Common.targets:
Это с Visual Studio 2008, 2010 и 2013, установленным в Windows 7.
Тот факт, что выполняется поиск в выходном каталоге, может немного расстраивать (как указывает исходный плакат), потому что он может скрывать неверный HintPath. Решение работает нормально на вашем локальном компьютере, но ломается, когда вы создаете чистую структуру папок (например, на машине сборки).
источник
По моему собственному опыту, лучше придерживаться одного из двух типов ссылок на сборку:
Я обнаружил (как вы описали) другие методы, которые либо слишком легко сломать, либо требуют раздражающих требований к обслуживанию.
Любая сборка, которую я не хочу передавать в GAC, должна находиться в каталоге выполнения. Любая сборка, которая не находится или не может находиться в каталоге выполнения I GAC (управляется событиями автоматической сборки).
Пока это не дало мне никаких проблем. Хотя я уверен, что есть ситуация, когда это не сработает, обычным ответом на любую проблему было «о, просто GAC!». 8 Д
Надеюсь, это поможет!
источник
Хотя это старый документ, но он помог мне решить проблему игнорирования HintPath на другом компьютере. Это произошло потому, что указанная DLL также должна быть в системе управления версиями:
https://msdn.microsoft.com/en-us/library/ee817675.aspx#tdlg_ch4_includeoutersystemassemblieswithprojects
Выдержка:
источник