DLL引用 - 多个相关项目和库最佳实践C＃ [英] DLL referencing - multiple related projects and libraries Best Practices C#

问题描述

我有一个包含2个DLL的第三方客户端库。

我有两个我正在创建的应用程序，带有一个业务对象库。



一个应用程序是与需要第三方库的特定工业设备通信的服务。我的服务和我的应用程序都需要这些库 - 它们本身需要一些功能，使它们更容易使用（而不是编写20或30行代码，我希望能够写一个或两个） - 所以这意味着我已经实现了一个库[有点像包装但不是真的]让我这样做 - 所以它引用了第三方dll - 我试图不必在我的其他两个应用程序中引用这些dll - 而只是有那些两个引用BizObjects和包装器 - 我认为这将使我的代码更容易遵循，也更容易维护。我想知道这是否是一个合理的模式，正常或错误，这里的最佳做法是什么，因为这两个应用程序都需要与这些第三方库相同的访问权限？

任何有用的见解，尤其是现实世界的体验知识都将受到高度赞赏。我不是C＃专家，而不是我全职工作，我会说我在某个生锈的中间水平附近程序员。

I have a 3rd party client library which encompasses 2 DLL's.
I have two applications that I am creating , with a business object library.

One application is a service which communicates with a specific industrial device requiring the 3rd party libraries. My service and my application will both require these libraries - which in themselves need some finessing to make them easier to work with (instead of writing 20 or 30 lines of code I would like to be able to write one or 2) - so this means I have implemented a library [kind of like a wrapper but not really] to enable me to do this - so it references the 3rd party dlls - I am trying to not have to reference these dlls in my other two applications - and simply have those two reference the BizObjects and the "wrapper" - I am thinking this will make my code easier to follow and also easier to maintain. I would like to know if this is a sound pattern to follow , something normal or wrong, what is the best practice here since both applications will require the same kinds of access with these 3rd party libraries?
Any helpful insights and especially real world experiential knowledge will be greatly appreciated .. I am not a C# expert and it is not what I do full time , I would say I am somewhere around a rusty intermediate level programmer.

推荐答案

首先，你没有引用DLL，你只引用程序集。你认为没有区别吗？有一个程序集通常有一个模块，可以是.DLL，.EXE（你可以通过.EXE模块自由引用程序集 - 你知道吗？在某些情况下，相当异国情调的那些，它甚至具有很大的实际意义;这不是一个技巧）或其他任何东西。但这不一定是这样。 .NET允许每个程序集使用多个模块，并且在物理上，这些模块中只有一个具有程序集清单。同时，可以在多个程序集中重用相同的模块。这由编译器的命令行支持，但不是由Visual Studio直接支持。让我们把它放在一边。在这里，引用程序集而不是模块是很重要的。组件对模块的使用类似于引用，但是有些不同。



现在，你应该明白组件之间的界限不是很强。您的类型和它们之间的依赖关系更为重要。因此，从使用主类设计代码开始，当您遇到问题时，可以更改程序集之间的类型分布。如果你犯了一些错误，你可以相对容易地将一个类从一个程序集移动到另一个程序集。在最坏的情况下，您必须将一些内部访问说明符更改为 public ，反之亦然。所有其他访问说明符保持不变。当您查看下面引用的过去答案时，请为以粗体支付特别注意。



现在，我建议主要不要将代码划分为主题（网络，用户界面等），但首先是按层。这里解释了这些原则：如何正确划分我的代码？ 。



另请参阅我对更高级架构的说明，包括插件：项目和DLL：如何保持它们可管理？。



最后，一个实用建议：将输出目录合并为一个，每个配置单独。它可以自动完成：

管理输出文件和文件夹（调试/发布）在VS C＃。，

VB.net。编译时使用引用的.NET dlls文件将所有文件结束。。

-SA

First of all, you don't reference DLL's, you only reference assemblies. Do you think there is no difference? There is… An assembly usually has one module, which can be .DLL, .EXE (you can freely reference an assembly by an .EXE module — did you know that? in some cases, rather exotic ones, it even makes big practical sense; and this is not a trick) or anything else. But this is not necessarily so. .NET allows multiple modules per assembly, and, physically, only one of those modules has an assembly manifest. At the same time, the same module can be reused in more than one assembly. This is supported by compiler's command line, but not directly by Visual Studio. Let's set it aside. Here, it's only important that you reference assemblies, not modules. And the use of the module by an assembly is similar to referencing, but is something different.

Now, you should understand that the boundaries between assemblies are not very strong. Your types and dependencies between them are more important. So, start with the design of your code with main classes, and, when you come to something, you can change distribution of types between assemblies. If you make some mistake, you can relatively easily move one class from one assembly to another. In worst case, you will have to change some internal access specifiers to public, and visa versa. All other access specifiers remains the same. When you look at my past answer referenced below, pay special attention for my words in bold.

Now, I recommend to divide your code primarily not by "topics" (networking, UI, and so on), but first, by layers. These principles are explained here: How Do I Divide My Code Appropriately?.

See also my notes on more advanced kinds of architectures, with plug-ins: Projects and DLL's: How to keep them managable?.

Finally, one practical advice: merge your output directories to one, separately per configuration. It can be done automatically:
Manage output Files and Folders (Debug/release) in VS C#.,
VB.net. Bring all files over with referenced .NET dlls files when compiling..

—SA

这篇关于DLL引用 - 多个相关项目和库最佳实践C＃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！