0

我发现自己在各种应用程序中一遍又一遍地使用了相当多的代码。我最近决定花时间将它们全部组织在一个位置，这样我就可以从我的任何解决方案中引用它们。我从一个类库项目开始，添加了一堆不同的函数和一些我使用的派生控件。一些函数由派生控件使用，也可以直接从应用程序调用。我构建了项目并开始在我的项目中使用 DLL。

我对这个自定义 DLL 有几个问题（我使用的是 Visual C# 2010 Express）：

  1. 我注意到的第一件事是它似乎不像微软的股票库那样工作。例如，我可以“使用 System.Windows.Controls;” 在程序中，但我只能使用 using 指令引用自定义库的命名空间。如果这样做有意义的话，以类似的方式组织我的课程会很好。是否可以像 Microsoft 那样嵌套类？

编辑：例如......如果我在我的应用程序代码顶部键入“使用系统。”，我会得到一堆子命名空间可供选择。我继续输入“Windows。”，我得到了更多的子类别。如果我添加对 MyCustom.dll 的引用并开始输入“使用 MyCustom。”，我看不到我的任何类或子类。我只是在问如何在我的类库中组织事物，使它们的行为类似于库存库。

  1. 用我所有的可重用代码制作一个大的 DLL 文件是个好主意吗？我目前没有大量代码，但我想留出扩展空间。对此的最佳做法是什么？

  2. 在为我的应用程序制作安装程序时如何处理我的 DLL？我通常使用 InnoSetup 来制作我的安装程序。

  3. 这是我主要关心的问题...假设我在 Application1 中使用自定义 DLL 中的一个函数，并且有人安装了它。我稍后会为我正在构建的 Application2 添加一些功能或更改该功能。如果新功能破坏了 Application1 或以不合需要的方式更改了某些内容，那么当用户安装 Application2 时会发生什么？我的自定义 DLL 是在应用程序之间共享，还是每个应用程序都有自己的 DLL 版本？显然，我会构建一个新版本的 Application1 以使其与新的 DLL 一起工作，但不能保证用户会更新它。

谢谢！

4

3 回答 3

1

DLL 非常适合您尝试做的事情。

1）我可以“使用 System.Windows.Controls；” 在程序中，但我只能使用 using 指令引用自定义库的命名空间。

这是因为 MS 在其 DLL 中公开了多个接口。为此，通常需要您在 DLL 中注册多个组件，从而使用您的代码将类导出到客户端。

2) 用我所有的可重用代码制作一个大 DLL 文件是个好主意吗？

DLL 通常是一种部署布局。因此，如果您的客户可能只对代码的子集感兴趣，那么将代码分解为更小的 DLL，但除非有需要，否则不需要。可以为其他开发团队提供特定的 API 组件以满足他们的需求，以便您只在需要时发布更小的粒度组件，DLL 越大，客户端越多，对他们的影响就越大。

3) 当我为我的应用程序制作安装程序时，我如何处理我的 DLL？我通常使用 InnoSetup 来制作我的安装程序。

Windows 的现代安装程序都包括分发 DLL 和在 Windows 注册表中注册 DLL 内的组件的能力。

4）这是我的主要关注点......（跨部署的同一个dll的多个版本）

在过去，当人们将他们的 DLL 部署到 Windows 系统文件夹时，这是一个大问题。在部署良好的 Windows 应用程序中不再是这种情况。Windows 将 DLL 沙盒自动安装到安装应用程序的本地，因此即使是认为其安装到 system32 或从那里加载的应用程序也确实不是。只要您遵循 DLL 部署规则并将您的 DLL 与您的应用程序一起发送，并且不要试图将它们强制放入系统目录，您就不必担心冲突（这些窗口可能无论如何都不会允许）

希望有帮助

于 2012-09-18T02:49:41.063 回答
1
  1. 我不明白你的问题。请重新措辞。
  2. 它因人而异。通常可重用库特定于您的解决方案（例如包含常见enum类型的共享库或数据库模型）。如果您只有在不同项目中重复使用的代码片段，则可以将源文件复制到您的项目中，或者引用源文件（VS 确实允许您这样做）而不复制它。如果您曾经使用源代码控制，请小心。
  3. 无需担心，DLL 只是您的应用程序的另一个依赖项。VS 将（默认情况下）将 DLL 复制到应用程序项目的输出目录，因此您只需配置安装程序以包含文件bin夹中的所有文件（可能 XML 文档文件除外）。
  4. 除非您费了很多力气让您的 DLL 在文件系统中共享（这在 1990 年代硬盘空间有限时很流行，请参阅“Microsoft Shared”文件夹作为示例），这不是问题，因为您的应用程序的每个发行版都将拥有自己的共享 DLL 副本（“共享”是在编译时，而不是在运行时）。如果应用程序尝试使用与其编译所针对的文件不兼容的 DLL 文件启动，.NET CLR 将引发错误（您可以使用强名称程序集进一步强制执行此操作）。
于 2012-09-18T02:49:55.837 回答
1

1) 通过将类文件中的命名空间从：SomeNamespace 更改为：SomeNamespace.SubNamespace，您可以将代码嵌套在它自己的子命名空间中。顺便说一句，如果您在 Visual Studio 的解决方案资源管理器中对项目执行“添加 -> 新建 -> 文件夹”，当您执行“添加 -> 新建 -> 类”时，VS 将自动使用您的“嵌套”命名空间，这将是您添加的文件夹的名称。因此，如果您的原始命名空间是：MyDLLProject，并且您在项目中添加了一个名为：HelpfulStuff 的文件夹，那么当您向该文件夹添加新的类文件时，您将看到命名空间现在是“MyDLLProject.HelpfulStuff”，因此，您将需要以这种方式在您的代码中引用它，或者通过完全指定它，或者通过包含“使用 MyDLLProject.HelpfulStuff”

2) 将任何和所有 RE-USEABLE 代码包装到 DLL 中当然是一个好习惯，因为它很容易在其他项目中使用，并且只需更改一次，如果需要更改，无论有多少项目用它。但是，如果您可以相当肯定您永远不会在其他任何地方使用该代码，则可能不值得花费时间和精力。

3) InnoSetup 应自动包含项目引用的任何程序集（.NET DLL）。您可以在 VS 的解决方案资源管理器中查看引用了哪些 DLL，并从项目树中的“引用”节点添加引用。如果您选择创建一个，则需要在此处添加对您自己的 DLL 的引用。

4) 除非您确实通过在 GAC（全局程序集缓存）中注册来使您的 DLL 成为共享组件，否则您无需担心这一点。您的应用程序将始终拥有它自己使用的 DLL 的副本，并且不会以您想象的方式相互踩踏。

于 2012-09-18T03:10:19.360 回答