Merging Core Libraries

Question

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.

Answer 1

Methinks this is highly dependent on language, environment, and type of libraries (dynamically / statically linked). What problems do you expect?

• colliding identifiers
• duplicate functionality
• changes to the build process
• integration / unit testing

Answer 2

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.