Принудительная ссылка, чтобы быть абсолютной, используя Visual Studio
При добавлении ссылки на проект веб-приложения в VS (в этом случае в 2008 году в этом случае), "hintpath" в файле csproj создается как относительная ссылка. Есть ли способ (используя графический интерфейс, а не вручную редактировать файл), чтобы сделать это абсолютной ссылкой (т.е. C:\Temp\DllName.dll)?
Проблема, с которой я сталкиваюсь, заключается в том, что на отдельных машинах сборки есть разные рабочие каталоги для проекта. Когда ссылка относительна, а ссылочная DLL не входит в рабочий каталог проекта, относительная ссылка может не указывать на одно и то же местоположение на обеих машинах.
Ответы
Ответ 1
Это старый вопрос, но он по-прежнему актуальен. Я наткнулся на это, ища решение, как обращаться к сборкам из глобального хранилища стороннего программного обеспечения.
Мой подход на данный момент похож на ответ, написанный thinkOfaNumber. Вместо использования строго кодированного абсолютного пути я предпочитаю встраивать переменную среды в файл .csproj. Затем переменная окружения сохраняет абсолютный путь. Пример:
<Reference Include="Foo">
<HintPath>$(THIRDPARTY_ROOT)\foo\3.1.0\bin\foo.dll</HintPath>
</Reference>
Этот дополнительный уровень косвенности дает гибкость в использовании разных путей на разных машинах сборки (например, в системе разработчиков или на сервере сборки).
Мне все равно нужно вручную отредактировать файл .csproj, чтобы сделать это.
Ответ 2
По умолчанию Visual Studio использует относительные ссылки, когда ссылка первоначально добавлена, поскольку она предполагает, что ссылка ссылается на файл в другом месте вашей рабочей копии.
Это использовало для меня орехи, но я решил это тремя способами:
Ответ 3
Единственный способ, которым я нашел это, - отредактировать файл csproj вручную после добавления ссылки.
<Reference Include="foo, Version=1.2.3.4, Culture=neutral, ...">
<SpecificVersion>False</SpecificVersion>
<HintPath>C:\absolute\path\foo.dll</HintPath>
</Reference>
и да, я ненавижу абсолютные пути и все безумие автоматического развертывания, которое он создает, но в этом случае мне приходится ссылаться на .NET-оболочку, которая использует COM-dll, которая должна быть "установлена" и что-то делать в реестре, и т.д., так что абсолютный путь - единственный способ пойти.
Ответ 4
Попробуйте щелкнуть правой кнопкой мыши по свойствам проекта, а затем перейти к ссылкам "Пути ссылок" и добавить туда жестко закодированные пути.
Ответ 5
Мы также столкнулись с этой проблемой. Мы хотели использовать абсолютные пути, потому что каждое развертывание создавало папку Packages в разных местах (и у нас также есть несколько машин для сборки). Идея заключалась в том, чтобы пакеты NuGet находились в одном месте, что освободило бы израсходованную память из нескольких копий одной и той же вещи.
Наша конкретная проблема заключалась в том, что мы могли бы установить абсолютный путь в файле NuGet.Config, пакеты NuGet вернутся в это место во время развертывания, но тогда он не смог найти их всех на этапе MSBuild в то же развертывание.
Я написал PowerShell script для решения этой проблемы. Он в основном заменяет относительные ссылки HintPath абсолютным путем, который я хочу использовать.
#Get list of all csproj files in a solution
$dir = Get-ChildItem $pwd -Recurse
$list = $dir | Where {$_.extension -eq ".csproj"}
#Replace relative paths with absolute path
$absolutePath = 'C:\absolute\path\Packages'
function replaceRelativePath($line){
if($line -match '<HintPath>[^C].+\\Packages')
{
$relative = $matches[0] -replace '\\','\\'
return ($line -replace "$relative", "<HintPath>$absolutePath")
}
else
{
return $line
}
}
#Updating files
Foreach($file in $List)
{
(Get-Content $file.FullName)| ForEach-Object{replaceRelativePath($_)} | Set-Content $file.FullName
}
Мы устанавливаем этот script для запуска как шаг сборки PowerShell перед этапами MSBuild в нашем развертывании. В результате файлы csproj изменяются для рабочего каталога на машинах сборки, но не в исходном управлении Visual Studio. (Если вы хотите, чтобы они меняли исходный элемент управления, вы могли бы запустить это в PowerShell и проверить изменения.)
Ответ 6
Я хотел бы помочь, но почему это необходимо? Мне никогда не приходилось это делать - начиная с vs .net beta 2003. Я думаю, что здесь есть еще один более глубокий вопрос.
Если вы хотите попробовать страницу Reference Path в свойствах проекта