1

我得出的结论是，nuget 并不值得它在源代码控制和部署方面遇到的所有问题。那么我该如何摆脱它呢？我想采用将引用的 dll 放入 bin 文件夹并正常进行配置更改的旧路线。

4

2 回答 2

1

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

  • 首先，卸载项目中的 NuGet 包（可选择在此时或最后重新添加没有 NuGet 的引用）
  • 在与您的解决方案文件 (.sln) 相同的文件夹中，可能有一个 .nuget 文件夹，如果该文件夹中没有其他解决方案依赖 NuGet，您应该删除该文件夹。
  • 在每个项目文件夹中，删除 packages.config 文件。如果没有将其签入源代码控制，则每个开发人员都需要从受影响的每个分支中的每个项目中删除 packages.config。

  • 在每个项目文件 (.csproj) 中，PropertyGroup 部分中有两行应删除：

    <SolutionDir Condition="$(SolutionDir) == '' 或 $(SolutionDir) == ' Undefined '">...</SolutionDir> <RestorePackages>true</RestorePackages>

  • 每个项目文件的底部还有一个部分（我在这个位置看到了多个化身，所以这只是一个例子）

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

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

于 2014-05-06T03:53:54.367 回答
1

我们有一个类似的问题，我可以在某种程度上理解你的观点 - NuGet 在我的解决方案级别创建的包文件夹很好，因为它将所需的依赖项整理到一个文件夹中以供该解决方案中的项目使用 - 但它确实当我们的开发人员尝试将解决方案代码推送到源代码控制中时成为一个问题，因为我不想为每个解决方案存储一个 EntityFramework.dll 文件夹，尤其是与它附带的所有口香糖。（顺便说一句，我个人认为 .dll 甚至不应该致力于源代码控制！）

但就你关于摆脱它的问题而言，我不完全确定它现在融入 Visual Studio 的程度，但你可以尝试以下改变：

在 Visual Studio 中，转到工具 > 选项 > 包管理器 > 包源。取消选中使“NuGet 官方包源”可用的框。从理论上讲，这应该会使 NuGet API 对您的 IDE 不可用。

希望这可以帮助。

于 2013-11-04T07:54:14.300 回答