CODEWITHSUNDEEP
c#asp.net.net
Musterknabe
Musterknabe

Reputation: 6081

Best practice for referencing a project or assembly in a solution

I started at a new company which manages multiple projects (around 30). However, all their projects are in one git-repository. I know wanted to split all our projects into one git-repository per project. To achieve that I went ahead and extracted every folder into a new folder, containing it's own git repository.

However, some references were broken. While investigating I found that project referencing was done in multiple ways, dependent on the project

  1. Including the entire solution/project in the current solution.
  2. Referencing the .csproj-file of another solution.
  3. Referencing the built .dll (bin/debug).

In my opinion, the first way should not the way to be, right? This seems like a way too big overhead. So I'm split between 2 and 3, and I would like to hear how you people are doing it?

Looking forward for your input!

Upvotes: 0

Views: 1366

Answers (3)

Holger
Holger

Reputation: 2654

Your question sounds like "How to split a solution into smaller solutions".

30 projects is not that much, At 30 C#-projects it's just the starting point to split your solution.The solution is the base for the Repository also.

If you analyze the dependencies of C#-projects, you certainly can form kind of clusters, are there basics- referenced by everything, and almost front end parts, referenced by nothing.

Basic-Projects (Depends from Nothing, but referenced by many) Tend to be more stable and have less frequent changes, it's also more dangerous to change, more danger of braking changes. It's good to make access to them more complicated (=put it in a different solution). You do not change it frivolously, just because you see the source code and you edit it. The code and architecture becomes more cleaner, since programmers tend to use a wrapper, derived classes or interfaces to do, what they want to do, inside their active solution. They do not change dependent solutions as fast and easy any more. So it stays more stable.

You can consider a Solution as a product of it's own, as a Library or Final Product. So splitting projects in the aspect, what is potentially being used in upcoming projects in the next years, and what is being used as a product for one client only. Suppose you start a new Product next week, what Projects would you most likely include there ? They belong into a library.

It's also simplifying life to new programmers, if you tell them "Just use it, you don't need to dig in the source code", or "get familiar with this solution only" if you group your C# projects into such clusters. They are not so overwhelmed by quantity.

Also the branching is done per solution, you create a branch on one solution per client request, and a branch of another solution to stay up to date with technology. This is much easier to handle with smaller bundles of projects.

Nuget-Server as proposed by others, is a good way to maintain updates. Without a Server you link to DLLs directly. If you do not have many updates, either you invest time in setting up the server, or in copying a few DLL's around, twice a year. One is not more complicated or time consuming as the other. Manual jobs done by different people cause the risk of human errors. But the task "copy all DLL's from one directory to another directory" might still work. Do not reference the output directory from one solution directly to the other solution. Put the "productive DLL" in a separate directory and do your update by saying "yes, I want to update - use it now". "Automated update" just if someone decides to built the other solution might cause trouble.

Upvotes: 0

jjroman
jjroman

Reputation: 653

What I do is to have a nuget server in the company or you can use Azure DevOps to do that: https://learn.microsoft.com/en-us/azure/devops/artifacts/get-started-nuget?view=azure-devops.

After you set the nuget server you can update/import the packages for each project. So, when you update the code of any project, post it to the nuget server and you can update all other projects.

Upvotes: 3

Carra
Carra

Reputation: 17964

It's normal to have code you want to share between multiple solutions.

For this, we use projects like 'Infrastructure' or 'Logging' with their own CI builds. When done, we create a release build which uploads the dll's to a private nuget server.

These projects are than included as dll's in the other projects through nuget and updated when needed. You also don't break other solutions when you change something in your logging, you have to update the logging version first.

Upvotes: 3

Related Questions