2013-11-03 97 views
1

我得出的结论是nuget不值得所有与源代码管理和部署有关的问题。那么我该如何摆脱它?我想要将引用的dll放入bin文件夹并按照正常方式进行配置更改。如何摆脱Nuget

+0

你是什么意思'摆脱它'?只是不要使用它。 –

+0

对于这些类型的问题的深入研究,您可能会发现值得看看我的一位同事发表的一篇文章,这篇文章谈论了在专业开发组织中使用NuGet的挑战:https:// www .simple-talk.com/dotnet/.net-framework/taking-nuget-to-the-enterprise/ –

回答

1

我们有一个类似的问题,我可以在一定程度上看到你的观点 - NuGet在我的解决方案级别创建的包文件夹很好,因为它将所需的依赖项整理到单个文件夹中供该解决方案中的项目使用 - 但是,当我们的开发人员尝试将解决方案代码推送到源代码控制时,它确实成为一个问题,因为我不想在每个解决方案中存储EntityFramework.dll文件夹,特别是随附的所有基本文件。 (顺便说一下,我个人认为.dll甚至不应该致力于源代码控制!)

但是,就您关于摆脱它的问题而言,我不完全确定它被编入Visual Studio中的程度如何现在,但您可以尝试以下更改:

在Visual Studio中,转至工具>选项>程序包管理器>程序包源。取消选中使'NuGet官方包源代码'可用的框。理论上讲,这应该让您的IDE无法使用NuGet API。

希望这会有所帮助。

+0

这是一个选项。你有处理Nuget的所有问题的好链接吗?我一直试图使用基本的东西,这是一个惊人的噩梦。 OAuth使用剃刀的2.0版,但最新的mvc使用3.0。我不能相信我现在是唯一有这个问题的人。 – DanScan

+0

在使用NuGet之外,有很多方法可以管理你的依赖关系,因为对于事情来说,这对于对方而言相对较晚。我使用Maven的工具开发了一个'Ivy'系统,这些工具已经移植到Windows平台上。要使用这个,我必须在制造商,文件名,版本号和文件类型中提供特定文件夹结构的依赖关系。这可能听起来都是肛门,但我完全可以控制每个.dll的哪个版本包含在我的任何项目中,并且没有任何依赖项被提交到源代码控制。 –

1

我的团队选择使用NuGet进行发现(我们喜欢它),与我们的活动项目分开,并通过另一种方式管理我们的参考,以实现控制和极简主义。这就是我们如何从这些项目中删除的NuGet:

  • 首先,卸载在你的项目中的NuGet包(可选择在这一点上没有的NuGet重新添加引用,或在年底)
  • 在同一个文件夹作为解决方案文件(.sln),可能有一个.nuget文件夹,如果该文件夹中没有其他解决方案依赖于NuGet,则应删除该文件夹。
  • 在每个项目文件夹中,删除packages.config文件。如果没有检入源代码控制,每个开发人员都需要从受影响的每个分支中的每个项目中删除packages.config。
  • 在每个项目文件(.csproj),有两条线中的PropertyGroup部分应该被删除:

    < SolutionDir条件=“$(SolutionDir)== '' 或$(SolutionDir)== '未定义'” > ... </SolutionDir > <RestorePackages>真正</RestorePackages >

  • 还有在每个项目文件的底部的部分(我已经看到多个在这个位置化身,所以这只是一个例子)

    < Import Project =“$(SolutionDir).nuget \ nuget.targets”Condition =“Exists('$(SolutionDir).nuget \ NuGet.targets') “/ >

您必须与您的团队进行协调。如果有人打开一个解决方案,其中包含在其目录中包含packages.config文件的项目,NuGet将撤消上面的手动编辑;特别是如果您打开了自动检查功能。