使用NuGet和Source Control的多人团队

时间:2011-08-10 17:29:25

标签: visual-studio visual-studio-2010 version-control tfs nuget

我是使用Team Foundation Server进行源代码管理的双人团队。我开始了一个新的解决方案对于该解决方案,我创建了几个项目在其中许多我使用NuGet安装AutoMapper和Unity。然后我右键单击解决方案并选择“添加到源代码管理”。然后,我检查了所产生的挂起更改。

我团队中的另一个人做了最新的事,所有的Nu​​Get引用都失败了。

所以,我想我需要添加Packages文件夹。所以我做到了。

在我这样做之后,NuGet引用仍然失败(对他来说)。

此外,当我尝试将NuGet包添加到文件时,我现在收到此错误:

  

拒绝访问路径'C:\ src \ MyPath \ ToMySolution \ packages \ repositories.config'。

我认为这是因为repositories.config文件现在处于源代码控制之下(因此只有在手动签出之前它才会被读取)。

所以,这是我的两个问题:

  1. 我如何或我应该检查哪些NuGet包对我的同事有效?
  2. 当我需要使用NuGet时,有没有办法不必手动签出NuGet文件?
  3. 我这样做错了吗?或者NuGet是否真的不适合与Source Control一起使用?

6 个答案:

答案 0 :(得分:11)

修改2014/03/31:不再需要基于MSBuild的手动包恢复启用,另请参阅http://xavierdecoster.com/migrate-away-from-msbuild-based-nuget-package-restore

编辑2012/02/07:这是NuGet vsix的内置功能,称为启用包恢复。

  

过时的替代

     

有一个NuGet包,它叫做NuGetPowerTools。它在Visual Studio中向NuGet包管理器控制台添加了两个新命令,其中Enable-PackageRestore对您来说很有意思。

它将添加一个包含nuget.exe,nuget.settings.targets和nuget.targets的.nuget文件夹。 运行启用包还原时,它将枚举解决方案中的所有项目,并在项目文件中添加 import nuget.targets 语句(实际上是msbuild文件)。

无论何时构建项目或整个解决方案,nuget都将获取该项目/解决方案的所有包,如packages.config文件中所定义。这发生在预构建步骤中。

简而言之:

  1. 不办理登机手续包
  2. 登记配置文件(repositories.config和packages.config文件)
  3. 使用启用包恢复
  4. 签入.nuget文件夹
  5. 每当有人获取源代码时,无论是团队中的另一个开发人员还是构建代理,都会指示msbuild进程在预构建步骤中获取所有必需的包。

    此外,当程序包未提交到TFS源代码管理时,您不会遇到只读标志问题,也不会合并与二进制文件的冲突。

    如果您愿意,您还可以查看此方法on my blog的底层推理。

答案 1 :(得分:5)

不要检查包中的包文件夹。

将以下预建事件添加到您的项目中:

$(SolutionDir)build\nuget install $(ProjectDir)packages.config -source \\server\path\NuGetPackages -o $(SolutionDir)packages

如果不使用自定义包,则省略-source参数。

将nuget.exe签入$(SolutionDir)build \ nuget

答案 2 :(得分:1)

我总是只检查packages.config文件夹,并使用开发人员(和构建服务器)可以用来在本地更新软件包的rake任务。

任务看起来像:

def nuget_for_project(project_dir)
  sh "tools\\NuGet.exe " +
    "i Source\\#{project_dir}\\packages.config " +
    "-o Source\\Packages"
end

namespace :nuget do
  desc "nuget for servicebus"
  task "ServiceBus" do
    nuget_for_project "SampleProject.ServiceBus"
  end    

  desc "nuget for web"
  task "Web" do
    nuget_for_project "SampleProject.Web"
  end  

  desc "nuget for all"
  task "all" => ["nuget:ServiceBus", "nuget:Web"]
end

请注意,上面的脚本使用检查到源代码管理中的工具文件夹中的本地版NuGet.exe。

您可以为msbuild或nant编写此代码。

我在前一段时间写了一篇更长的blog post,这可能会有所帮助。

答案 3 :(得分:1)

我也有这个问题。我喜欢Nuget恢复的想法,但我觉得我不需要它。我希望我的JR开发人员能够检查解决方案,并拥有他们需要的一切。

所以我将我的packages文件夹放在源代码管理下。

我在这种情况下启用Nuget的解决方案是从上面注意到这一点:

“我认为这是因为repositories.config文件现在处于源代码管理之下(因此只有在手动签出后才能读取)。”

我打开了repositories.config文件并添加了一个空行。然后添加了我需要的Nuget包。问题解决了。

答案 4 :(得分:0)

必须对本文大声疾呼: http://www.jsinh.in/2013/11/enable-nuget-package-restore/ 它准确描述了该做什么以及为什么做。

某些系统可能需要对各种软件包进行版本控制以保持构建一致性的概念,但是,如果packages.config文件受版本控制且可以下载软件包,那么构建可以在任何时候进行,而无需对其进行版本控制。实际包装内容本身。警告:包的构建器可能在您不知情的情况下将项添加到较旧的构建中。

很少见,但可能。

例如,在项目中内置了版本为2.0.2的“abc.package”包。您不要对'abc.package'进行版本控制,而是对packages.config进行版本控制。几个月后,您需要为几个月前制作的构建添加一个错误修复程序。你从VC获得了这些东西。 VisualStudio下载了'abc.package'的2.0.2版本,但是自上次构建以来,插件的开发人员已经插入或修复了一些代码。此新代码在您的应用中可能会有不同的行为。

所以,有很好的理由来VC包装!

答案 5 :(得分:0)

以防这对任何人都有帮助,我的解决方案非常简单:

  1. 在NP ++中打开目标文件
  2. 在编辑菜单中,一直到底部,点击Clear Read-Only Flag
  3. 保存文件
  4. 利润
  5. 在撰写本文时,这对我来说是一个解决方案,有39个项目。