DLL适合我吗？

Question

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

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

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

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

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

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

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

谢谢！

Answer 1

DLL非常适合您尝试的操作。

  

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

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

  

2）制作一个包含所有可重复使用的大型DLL文件是一个好主意   码？

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

  

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

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

  

4）这是我主要担心的问题......（同一个dll的多个版本）   部署）

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

），您不必担心冲突。

希望有所帮助

Answer 2

1. 我不明白你的问题。请重新说出来。
2. 它有所不同。通常可重用的库特定于您的解决方案（例如包含常见enum类型的共享库或数据库模型）。如果您只有在不同项目中重复使用的代码片段，则可能需要将源文件复制到项目中，或引用源文件（VS确实允许您这样做），而无需复制它。如果您使用源代码控制，请小心。
3. 没有什么可担心的，DLL只是应用程序的另一个依赖项。 VS（默认情况下）将DLL复制到应用程序项目的输出目录，因此您只需将安装程序配置为包含bin文件夹中的所有文件（XML文档文件除外）。
4. 除非你在文件系统中共享你的DLL会遇到很多麻烦（在20世纪90年代硬盘空间有限时这是一个很受欢迎的事情，请参阅“Microsoft Shared”文件夹中的例子）这不是一个问题，因为您的应用程序的每个分发都有自己的共享DLL副本（“共享”是在编译时，而不是运行时）。如果应用程序尝试使用与其编译的DLL文件不兼容的DLL文件进行启动，则.NET CLR将抛出错误（并且您可以使用强名称程序集进一步强制执行此操作）。

Answer 3

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

2）将任何和所有RE-USEABLE代码包装到DLL中当然是一种很好的做法，因为它很容易在其他项目中使用，并且只需要更改一次，如果需要更改，无论如何有多少项目使用它。但是，如果你可以相当肯定你永远不会在其他任何地方使用这些代码，那么可能不值得花时间和精力。

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

4）除非你真的通过在DLL（G22（全局程序集缓存）中注册将DLL作为共享组件而遇到麻烦，否则你不必担心这一点。您的应用程序将始终拥有自己所使用的DLL的副本，并且不会以您想象的方式踩到彼此的脚趾。