内部可重用库 - 作为 dll 或项目重用？
我们在工作中有相当多的可重用代码（这是一件好事）。每当我创建一个使用它们的新项目时，我习惯于将它们的项目作为我的解决方案的一部分包含在内，并且我想知道是否应该将它们重用为已发布的 dll。我包含该项目的原因（或借口）是，如果我发现其中一个项目存在错误，我可以在那里分支并修复它。但这似乎分散了我对手头项目的注意力。
（不确定这是否应该是 CW，因为只有两个答案，我有兴趣了解您的偏好）
We have quite a bit of reusable code at work (a good thing). Whenever I create a new project that use them I am used to include their projects as part of my solution, and I was wondering if I should instead reuse them as published dll's instead. The reason (or excuse) I include the project is that if I find a bug in one of them I can branch and fix that right there. But it seems to be taking my focus from the project at hand.
(Not sure if this should be CW since there are only two answers and I would be interested in learning about your preferences)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这里有一些事情需要考虑。
我对几个月内不会更改的任何代码使用预编译库。如果我需要每月多次更改包中的某些代码，则该包不会被预编译。
我更喜欢预编译来加快主程序的编译速度。但我总是在预编译中包含调试符号，因此如果发生错误，我可以像其他程序一样轻松地单步调试预编译程序集。
There's a few things to consider here.
I use precompiled libraries for any code that doesn't change in months. If I need to change some code more than once a month in a package then that package isn't precompiled.
I prefer precompiling to speed up compilation of the main program. But I always include debug symbols in the precompile so if an error occurs I can step through the precompiled assembly just as easily as the rest.
这实际上取决于您是否属于负责这些问题的团队，或者是否属于将它们添加到源中并随时修复它们的团队。如果您不在该团队中，请将他们视为客户并在发现缺陷时将其归档，否则您可能会对工作范围之外的代码负责。如果您处于一个灵活的环境中，这可能并不重要，但对我来说，突然成为代码更改的所有者可能是一个问题，我没有发言权。
That really depends if you are on the team responsible for them or not if you are on the team add them to your source and fix them as you go. If you are not on that team use them as a customer and file defects as you find them otherwise you may become responsible for code outside of your job scope. If you are in a flexible environment that may not matter but for me it could be a problem to all of a sudden be the owner of a code change I have no say over.
对此的一个考虑因素是所述库的重用频率。如果它们倾向于在完全不同的项目中使用，那么您必须小心，不要让自己陷入困境，您会发现三周前为支持某些新应用程序而对库所做的更改结果是对某些新应用程序的破坏性更改一些其他应用程序。
基本上我想说的是，您不想必须抵制诱惑，不情愿地对库进行更改；您应该这样做。最好一开始就不要把这种诱惑摆在你面前。如果一个库是为了重用而设计的，那么对其进行的任何重大更改都应该非常仔细地设计和实施，并针对所有依赖库/应用程序进行彻底测试。当源代码就在你面前等待修改时，采取严格的方法就会变得相当困难。
我的方法是创建相关库的解决方案；例如，我可能有一个用于核心接口和抽象类的程序集，一些其他用于不同具体实现的程序集，另一个用于单元测试的程序集，等等。如果存在多层依赖的可重用库，那么它们通常都会集中到同一个解决方案中。
但它停留在应用程序层面。任何不总是与核心库一起部署的项目都不会共享解决方案，它只是引用已编译的 DLL。它迫使我对库的更改保持纪律，而不是为了支持某些特定的 UI 功能而开始调整它。
我不知道这是否是“正确”的方法，但我之前曾因在没有正确测试依赖项的情况下对库进行过早更改而受到影响，而且这始终是过于专注于单个应用程序而不考虑侧面的结果-效果。我对此的看法是，当您在库上工作时，您需要关注库本身，而不是它在特定场景中的使用方式。
One consideration for this is just how frequently said libraries are reused. If they tend to be used across completely different projects, you have to be careful not to paint yourself into a corner, where you find out that changes you made three weeks ago to the library to support some new app turned out to be breaking changes for a few other applications.
Basically what I'm saying is that you don't want to have to resist the temptation to make changes to a library willy-nilly; better to not put that temptation in front of you in the first place. If a library is designed for reuse, any significant changes to it should be designed and implemented very carefully, and thoroughly tested against all dependent libraries/apps. It becomes considerably more difficult to take a disciplined approach when you literally have the source right in front of you, waiting to be modified.
My approach is to create solutions of related libraries; for example, I might have one assembly for the core interfaces and abstract classes, a few other assemblies for different concrete implementations, another for unit tests, and so on. If there are layers of dependent reusable libraries then they will often all get lumped into the same solution.
But it stops at the application level. Any project that's not always going to get deployed with the core libraries does not share a solution, it simply references the compiled DLL. It forces me to be disciplined about library changes and not start tweaking it in order to support some specific UI function.
I don't know if this is the "right" approach, but I have been bitten before by making premature changes to libraries without properly testing dependencies, and it's always been a result of being too focused on a single app and not thinking about side-effects. My take on this is that when you work on a library, you need to be focused on the library itself and not how it's being used in a particular scenario.
对于库被多个独立解决方案重用的情况，或者当库由使用它的团队之外的另一个团队管理时，我认为要记住的最重要的规则是解决方案的特定版本通常应该是与该库的特定版本相关。
问自己以下问题：当我查看六个月前的解决方案的源代码时，我会得到哪个版本的库？如果答案是：“始终是库的最新版本”，这可能会出现问题。
我参与的一个项目中，开发人员自动在本地网络上发布其 dll 的新版本。我们正在研究的解决方案只是引用了该特定位置的 dll。问题在于，我们永远不知道我们正在编译哪个版本的库，并且不止一次，在测试之后，我们发布了一个应用程序版本，该版本由于突然发布了该库的新版本而崩溃（我们没有不测试）。
但是，当您开发应用程序的版本 2，但仍必须维护应用程序的已发布版本 1 时，这一点会变得更加明显。您希望使用最初发布时使用的相同库版本来发布版本 1 的补丁（当错误不在该库中时），否则您将不得不再次重新测试整个应用程序。
因此，我通常将我使用的所有库（默认情况下不在 GAC 中）添加为我的解决方案的一部分，并将它们签入源代码管理。这样我就可以完全控制解决方案在任何给定时刻使用的版本。
For the situation were a library is reused by multiple independent solutions, or when the library is managed by another team than the team who uses it, I think the most important rule to keep in mind is that a particular version of a solution should normally be related to a specific version of that library.
Ask yourself the following: which version of the library do I get when I checkout the source code of the solution from six months ago? If the answer is: “Always the newest version of the library”, this could be problematic.
I worked on a project where the developers automatically published new versions of their dlls on the local network. The solution we were working on just referenced the dlls from that particular location. The problem with this was that we never knew to which version of the library we were compiling against and more than once, after testing, we released a version of our application that broke because suddenly a new version of that library was released (that we didn’t test).
But it will get even more obvious when you’re developing a version 2 of your application, but still have to maintain a released version 1 of your application. You want to release patches of version 1 with the same library version it was initially released with (when the bug is not in that library) because otherwise you will have to retest the whole application again.
Because of this I normally add all the libraries I use (that are not in the GAC by default) as part of my solution and check them in into source control. This way I have full control over the versions the solution uses at any given moment in time.