使用Visual Studio强制引用是绝对的

时间:2009-05-01 18:31:41

标签: visual-studio visual-studio-2008

在VS(本例中为2008)中添加对Web应用程序项目的引用时,csproj文件中的“hintpath”将被创建为相对引用。有没有办法(使用GUI,而不是手动编辑文件)使其成为绝对引用(即C:\ Temp \ DllName.dll)?

我遇到的问题是当单独的构建机器具有不同的项目工作目录时。当引用是相对的,并且引用的dll不在项目工作目录中时,相对引用可能不指向两台机器上的相同位置。

6 个答案:

答案 0 :(得分:10)

这是一个老问题,但它仍然是相关的。我在寻找解决方案的过程中偶然发现了如何从全球第三方软件库中引用程序集。

目前我的方法类似于thinkOfaNumber写的答案。我更喜欢将环境变量嵌入到.csproj文件中,而不是使用硬编码的绝对路径。然后环境变量保存绝对路径。例如:

<Reference Include="Foo">
  <HintPath>$(THIRDPARTY_ROOT)\foo\3.1.0\bin\foo.dll</HintPath>
</Reference>

这种额外的间接级别可以灵活地在不同的构建计算机上使用不同的路径(例如开发人员系统与构建服务器)。

我仍然需要手动编辑.csproj文件才能执行此操作。

答案 1 :(得分:6)

我发现这样做的唯一方法是在添加引用后手动编辑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并对注册表执行操作,所以绝对路径是唯一的出路。

答案 2 :(得分:5)

默认情况下,Visual Studio在最初添加引用时使用相对引用,因为它假定引用是指工作副本中其他位置的文件。

这曾经让我疯了,但我用三种不同的方式解决了它:

  1. 将我的源代码保存在我的D:驱动器上,这意味着C:驱动器上引用的DLL无法与相对路径一起存储。
  2. 通过说服所有开发人员工作站使用单个图像/脚本的权力。现在他们都是一样的,文件都在C:驱动器上的相同位置。
  3. 意识到您可以向AssemblyFolders registry key添加文件夹,这意味着您不再需要使用任何类型的路径来引用已知程序集。

答案 3 :(得分:0)

尝试右键单击项目的属性,然后转到参考路径,并在那里添加硬编码路径。

答案 4 :(得分:0)

我们也遇到过这个问题。我们想使用绝对路径,因为每个部署都在不同的位置创建了Packages文件夹(我们还有多个构建机器)。我们的想法是将NuGet软件包放在一个地方,这可以释放浪费的内存,使其具有相同内容的多个副本。

我们的具体问题是我们可以在NuGet.Config文件中设置绝对路径,NuGet包将在部署期间恢复到该位置,但是在MSBuild步骤期间它无法找到它们。相同的部署。

我写了一个PowerShell脚本来解决这个问题。它基本上用我想要使用的绝对路径替换相对的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
}

我们将此脚本设置为在部署中的MSBuild步骤之前作为PowerShell构建步骤运行。结果是在构建计算机上的工作目录中更改了csproj文件,但在Visual Studio源代码控制中没有。 (如果您希望它们在源代码管理中进行更改,您可以在PowerShell中运行它并检查更改。)

答案 5 :(得分:-1)

我想帮忙,但为什么这有必要?我从来没有做过这样的事情 - 自vs.net beta 2003以来。我认为这里有另一个更深层次的问题。

如果必须,您可以尝试项目属性中的“参考路径”页面