Managing Internal Third-Party Dependencies

Question

We have many different solutions / projects that are managed by different teams. Our solution should refer to several projects owned by another team. We do not want to add these dependencies as references to projects, because we do not intend to modify this code, we just want to use it. We also already have many projects in our solution, and we do not want to add even more, as this will slow down the work of Visual Studio. Therefore, we build these projects in a separate solution and add them as file links for our solution.

My question is, how do people manage these types of dependencies? Should I just have some kind of automated process that looks for changes in these projects, builds them and checks the DLL in our original control, after which we consider them as other dependencies from third-party developers? Is there a recommended way to do this?

Answer 1

One solution, although this may not be what you are looking for, is for each dependent subsystem to issue. This release can be in the form of an MSI installation or just a network assembly resource. When significant changes occur, this command will inform you of this, and you can run the installation or script to copy the files.

Once you get the release, you can put it in the GAC, so you don’t have to worry about copying them to the folders with the project folders.

Another solution, assuming you are using a build server or some kind of continuous integration, is to create a post-step or file processing process. Then, at any time, developers of other teams can capture new files or have a script or bat file that pulls them locally.

EDIT - ANOTHER DECISION It is better to ask why you have these dependencies? Do you really need them locally when creating your part of the application? Could you mock dependencies in your solution by letting you program, build, and run unit tests? The actual application will connect to them in the DEV / Test / Prod environment. Keeping your decision untied and dependent for free may be the best solution for an individual team. Leave the integration and connection when the application is running in real setup.

Answer 2

( ^{Not a complete answer, but still :)}
Any delivery is better stored in a file / binary repository, unlike the VCS used to manage source history.

We prefer to manage these deliveries in a repo, such as Nexus , and we use maven to return the correct dependencies.
Even if these tools can be more Java-oriented, Nexus can store anything, and maven is only there to read pom.xml each artifact and calculate the correct dependencies.