3

在我当前的 .net 项目中，我使用了各种 .dlls 文件，有些是外部编写的，有些是我创建的。现在我问自己，在不同的解决方案和项目上处理不同的 .dll 文件并让它们与 SVN 一起工作以便它们可以在不同的开发人员之间使用的最佳实践是什么。

好的，所以我在问一些一般提示：

  • 我应该通过源将 .dll 项目绑定到不同的解决方案中，还是直接通过它的 release.dll 绑定？

  • 如何防止人们通过 SVN 获取文件以重新绑定 dll 源（全局程序集问题等）

  • 使用尽可能多的 .dll（按功能划分）或使用一个大的 .dll 以获得更简单的概述是好的吗？

请不要太难，我是这个行业的初学者，英语不是我的母语。

提前谢谢你，哈利。

4

5 回答 5

2

.NET 中的 DLL 的问题在于，它们与 .NET 之前的 Windows 编程中的 DLL 完全不同。它们只是代码的容器。

几年前我读过一篇很好的文章，它也解释了这一点，因为它曾经也让我感到困惑——我相信它是由一位 MS 模式和实践人员写的，谈论命名空间、程序集、项目之间的关系和解决方案（如果我找到它，我会发布链接）。

出于源代码控制的目的，我认为您最好存储代码，并让它在最终用户的机器上编译。将已编译的 DLL 放入源代码管理通常是您为 3rd 方依赖项所做的事情。

这只是根据我的经验 - 一些专家可能有更好的建议。

于 2012-02-27T08:06:50.163 回答
2

我建议设置包含您的外部 dll 的自己的 NuGet 提要。您可以将 NUGet 提要设置为共享文件夹（无需安装）。这些提要将在您的组织内部，您可以完全控制升级。

多个项目可以使用相同的 NuGet 包共享相同的 dll。

http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

于 2012-02-27T08:14:23.730 回答
1

我认为在您的应用程序中使用 dll 不是一个可以用“是”或“否”来回答的问题，因为这取决于您使用哪个 dll 的原因。

因此，如果您已经在解决方案中使用了 3rd 方 dll，我认为将您的代码而不是您正在创建的 dll 放在此处将是最佳实践，这样您就没有很多 dll，并且您的编译器不会有很多 dll 的引用也是。

于 2012-02-27T08:09:41.700 回答
1

我认为 3 层架构是很好的做法。

GUI.dll
Business.dll
DataAccess.dll

我更喜欢项目引用而不是 DLL 引用，因为您在调试配置中引用了调试 dll，而在发布配置中引用了发布 dll。

于 2012-02-27T08:13:35.830 回答
1

通常，如果有充分的理由这样做，您应该将代码分成不同的程序集......

  • 您在不同的项目中使用程序集的代码
  • 您想将数据与 GUI 分开
  • DLL 更新了很多次，为了简单起见，您只需要更新其中的一小部分

将代码放入 dll 而不是将其放入一个大项目中的原因有很多。但是如果没有理由，你不应该创建很多 dll（我已经看到一些人为每个命名空间创建一个 dll，它们包含的类并不多，也没有理由拆分它们）。

当然，将代码拆分为 dll 可能会导致一些问题，例如您在 dll a 中有一个类，在 dll b 中有一个类，它们中的每一个都需要对另一个的引用。这主要是应用程序的设计问题。

于 2012-02-27T08:15:22.070 回答