合并核心库
大约一年前，我们公司推出了一个相对较大的软件包，主要由两名高级开发人员编写。 为了便于演示，我将其称为“项目 A”。 从那时起，我们一直在开发一个新的软件包“项目 B”，在它的树中是项目 A 的一个分支。
项目 B 引用了项目 A，但现在我们已接近项目 B 的结束，我们还需要从 A 引用 B。因此，在合并 A 的分支之后，在与 B 一起上线之前，我们希望合并两个项目之间的核心库。
对于这种情况，您有过哪些经历？ 该项目有哪些最佳实践和经验教训？ 我们如何才能最好地合并核心库，同时对项目 A 中的其余源代码影响最小？
编辑： 对于保留项目 A 的命名空间，但将代码放在项目 B 的核心库（最终将成为公司的核心库）中的可行性，您有何看法？ 从那里，只需引用遗留项目中的新公司核心库...
编辑2： 感谢您的回复。 也许需要进行更多的技术澄清。 这两个项目都非常密切相关，但每个项目都有自己的 .NET 类库项目作为核心库。 除此之外，每个库都被其他各种 .NET 项目引用； 内部和外部 Web 应用程序、表单应用程序等。我更多的问题是源代码应该存放在哪里 - 我不认为它们应该保留为两个独立的 .NET 项目，但一个项目包含这两个项目，最初保留现有的命名空间。 随着我们继续开发，我们将重构，组合命名空间，清除重复的功能等。毫无疑问，两个现有库中包含的功能将在即将到来的项目中有用，而且还出现了在两个现有库之间共享的新需求“核心”库。
About a year ago our company rolled a relatively large software package written primarily by two senior developers. For ease of demonstration, I'll call it "project A". Since then, we have been working on a new software package, "project B" and in its tree is a branch of project A.
Project B has a reference to project A, but now that we're nearing the end of project B, we also need to reference B from A. So, after merging the branches of A and before going live with B, we would like to merge the core libraries between the two projects.
What are some experiences you have had with this type of situation? What are some best practices and lessons learned on this project? How can we best merge the core libraries with minimal impact to the rest of the source code in project A?
EDIT:
What is your opinion on the feasibility of retaining project A's namespaces, but locating the code in project B's core library (which will ultimately become the company's core library)? From there, just reference the new company core library in the legacy projects...
EDIT 2:
Thanks for the replies. Maybe a bit more technical clarification is in order. Both of these projects are very closely related but each has their own .NET Class Library project for a core library. Beyond that, each library is referenced by other various .NET projects; internal and external Web Apps, Forms Apps, etc. More of my question is where the source code should live - I don't believe that they should remain two separate .NET projects, but a single project contains both, keeping the existing namespaces initially. As we continue to develop, we'll refactor, combining namespaces, clearing out duplicate functionality, etc. There is no doubt functionality contained in both existing libraries that will be useful in upcoming projects and there is also an emerging need to share between both existing "core" libraries.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的问题是 B 和 A 之间循环引用的可能性吗？
或者更多关于 A 和 BA 之间命名空间冲突的信息？
如果 A 和 BA 都位于同一个项目中完全相同的命名空间 (A) 中，我认为您可能会遇到严重的冲突。
一种可能性是向两个库添加命名空间前缀，然后根据您的需要导入该库？
即
A 变成 V1.A，BA 变成 V2.A（在项目 B 下），
那么如果你想要 V1，你只需导入 V1 命名空间，如果你想要 V2，你导入 V2 命名空间，我认为引用应该对齐？
您仍然会遇到一些问题，因为如果您弄乱了 A 的命名空间，您将破坏任何已将其引用为 A 而不是 V1.A 的遗留代码。
老实说，我认为在项目中你的程序集和命名空间只需要是唯一的。 因此，如果您有两个版本的程序集具有相同的命名空间……则必须删除其中之一。
Is your problem with the possibility of cyclical references between B and A?
Or more about conflicting namespaces between A and B.A?
If both A and B.A are in the EXACT same namespace (A) in the same project, I think you could run into serious conflicts.
One possibility is to add a namespace prefix to both libraries, and depending on which you want you could import that one?
i.e.
A becomes V1.A and B.A becomes V2.A (underneath project B)
So then if you want V1 you just import the V1 namespace, if you want V2 you import the V2 namespace and the references should line up I think?
You'll still run into some problems because if you're messing with the namespace for A, you'll be breaking any legacy code that already references it as A and not V1.A.
Honestly I think in a project your assemblies and namespaces just need to be unique. So if you have two versions of assemblies with the same namespace... one of them has to go.
我认为这高度依赖于语言、环境和库类型（动态/静态链接）。 您预计会出现什么问题？
Methinks this is highly dependent on language, environment, and type of libraries (dynamically / statically linked). What problems do you expect?