Maximum number of projects in .net/VS solution
-
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
-
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
I have a solution with about 50 - 60 projects in it. I have never explored the maximum, if there is one at all beyond reasonable memory limitations. The whole thing compiles to several executables, services and server components and many shared libraries for every tier/layer.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
Well i for my self separate as much as possible, my main project now counts 27 project in one solution. CUrrently Testing Projects are in there but i'll change that later on. Every time i use a .dll from this main project in another i copy it to the new solution / project because the software does something else but needs some basic .dll's. (by copy i mean integrate it from the main .dll folder and set local copy true) On the CI / deploy machine everything is linked therefore. Another benefit is, changes to your mainproject do not necessarily effect your other applications using the changed .dll. Sure you have to keep track of things and manage a bit but i'd say it's worth the effort on long term since if you have a CI server and you configure it correctly the magic just happens and it works fine. And it just looks awesome when builds run through their stages on the CI and you can just watch how it fluently goes through every section. :)
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
} -
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
Vunic wrote:
How many projects you could afford to keep on the same solution?
Probably only two - the application and the unit tests.
Vunic wrote:
If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare.
Perhaps only is you have a commit, unit testing and broken build fixing strategy that creates this nightmare.
Vunic wrote:
How this is usually handled?
There seem to be a number of strategies.One is to go more towards microservices if you are developing web based and not desktop applications. You can also make use of nuget to ensure you have the most recent dlls. Also unit tests help detect issues early on. Add to this having an agreed on strategy to checking in changes among devs - so if you check in a new dll and you break the build it's your responsibility to fix the issue or roll back the checkin so that everything is green. You could also think about doing trunk based development, if you are currently on branch based development, so that the build breaks earlier rather than later.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
My current solution has 74 projects in it. Not something that is either practical or recommended, but in my defense, I didn't create the project structure. Microsoft did, so that explains that! :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain -
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
I prefer to keep it as few as possible. Every application gets its own separate solution. Shared libraries get their own solution and go in a NuGet repository. The most projects in a single solution I currently have is like 10. Most I've ever had is probably more like 15-20, as you say. With microservices the number of projects in a single solution has gone down even further. The pros are, of course, faster loading and building times and smaller and faster pulls from source controls. The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time, especially with microservices where one is dependent on the other.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I prefer to keep it as few as possible. Every application gets its own separate solution. Shared libraries get their own solution and go in a NuGet repository. The most projects in a single solution I currently have is like 10. Most I've ever had is probably more like 15-20, as you say. With microservices the number of projects in a single solution has gone down even further. The pros are, of course, faster loading and building times and smaller and faster pulls from source controls. The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time, especially with microservices where one is dependent on the other.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time
To develop multiple solutions, what I do is add a temporary project in one solution change the reference to the temp dll and develop there. After the development is complete I just report the changes to the other solution and change the reference back to the original dll. 30 mins of extra work reduce a considerable amount of cuss words.
-
I have a solution with about 50 - 60 projects in it. I have never explored the maximum, if there is one at all beyond reasonable memory limitations. The whole thing compiles to several executables, services and server components and many shared libraries for every tier/layer.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
CodeWraith wrote:
I have a solution with about 50 - 60 projects in it.
:wtf:
-
I prefer to keep it as few as possible. Every application gets its own separate solution. Shared libraries get their own solution and go in a NuGet repository. The most projects in a single solution I currently have is like 10. Most I've ever had is probably more like 15-20, as you say. With microservices the number of projects in a single solution has gone down even further. The pros are, of course, faster loading and building times and smaller and faster pulls from source controls. The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time, especially with microservices where one is dependent on the other.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
:thumbsup::thumbsup: Exactly.
-
I prefer to keep it as few as possible. Every application gets its own separate solution. Shared libraries get their own solution and go in a NuGet repository. The most projects in a single solution I currently have is like 10. Most I've ever had is probably more like 15-20, as you say. With microservices the number of projects in a single solution has gone down even further. The pros are, of course, faster loading and building times and smaller and faster pulls from source controls. The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time, especially with microservices where one is dependent on the other.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I have a solution with about 50 - 60 projects in it. I have never explored the maximum, if there is one at all beyond reasonable memory limitations. The whole thing compiles to several executables, services and server components and many shared libraries for every tier/layer.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Well i for my self separate as much as possible, my main project now counts 27 project in one solution. CUrrently Testing Projects are in there but i'll change that later on. Every time i use a .dll from this main project in another i copy it to the new solution / project because the software does something else but needs some basic .dll's. (by copy i mean integrate it from the main .dll folder and set local copy true) On the CI / deploy machine everything is linked therefore. Another benefit is, changes to your mainproject do not necessarily effect your other applications using the changed .dll. Sure you have to keep track of things and manage a bit but i'd say it's worth the effort on long term since if you have a CI server and you configure it correctly the magic just happens and it works fine. And it just looks awesome when builds run through their stages on the CI and you can just watch how it fluently goes through every section. :)
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
} -
My current solution has 74 projects in it. Not something that is either practical or recommended, but in my defense, I didn't create the project structure. Microsoft did, so that explains that! :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain -
I guess Nuget would be a solution as said by Sander Rossel?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
Probably not. Except for the usual .Net framework stuff, there is only one single external library. The rest is my own code. Two applications, a graphics engine and a UI for the graphics engine, a web application for user management and login, six services, modules with entities, modules of application logic or data access 'behind' the services... It sums up very quickly, but some of the older stuff (like the webpages for the actual applications) are on their way out once everything has been ported to the clients.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Sander Rossel wrote:
The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time
To develop multiple solutions, what I do is add a temporary project in one solution change the reference to the temp dll and develop there. After the development is complete I just report the changes to the other solution and change the reference back to the original dll. 30 mins of extra work reduce a considerable amount of cuss words.
Yeah, I do that too sometimes :thumbsup:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
At my previous job we merged with another company and their solution had over 120 projects in it. And the plan was to merge their main product with our product. Needless to say I'm glad I'm not there anymore.
Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
-
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
I've spent years working (with others) on a product, with VS 2005 through the current 2017, that has grown to 80 projects so or. No instance of VS during that time has ever choked on it. It's not terribly fast, but it probably works as well as one can reasonably expect with something like this.
-
Probably not. Except for the usual .Net framework stuff, there is only one single external library. The rest is my own code. Two applications, a graphics engine and a UI for the graphics engine, a web application for user management and login, six services, modules with entities, modules of application logic or data access 'behind' the services... It sums up very quickly, but some of the older stuff (like the webpages for the actual applications) are on their way out once everything has been ported to the clients.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
How many projects you could afford to keep on the same solution? Some blogs say it's 15-20. But this would be too little for large projects. If I have to keep separate solution for different groups of projects (for the same product) Then managing the dependency dlls breakage would be a nightmare. How this is usually handled? Lets say I have a Common.dll that's being used by 30 projects. This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?) (I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy :|, but these are freshers) So I'm trying to heap the projects under single solution. And to keep the build process easy, I'm thinking to: 1. un-check the projects that are not involved in current build, in solution build settings. 2. Unload project itself if it's a POC, tester or something completely not needed for current build. Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
Vunic wrote:
This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?)
Ugh, no. Each of the 30 projects is its own solution with a reference to the Common project (note, the project, not the DLL). And use a build automation took to build all the different solutions. And hopefully you have some decent unit tests so that when you change something in Common, you know when you've broken something in the other projects.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Vunic wrote:
This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?)
Ugh, no. Each of the 30 projects is its own solution with a reference to the Common project (note, the project, not the DLL). And use a build automation took to build all the different solutions. And hopefully you have some decent unit tests so that when you change something in Common, you know when you've broken something in the other projects.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Yes, I'm referencing the common dependencies as projects. But we can really reference a project directly in TFS? I'm yet to figure this out. Common Dep. projects used to live in their own solution folder in TFS directory, with their own unit testers. When two solutions utilize this dll, I have to down the 3 solutions separately (which means 3 VS instances), & manually ADD the common dll project to both the application solutions. I felt its a bit messy. When I do this, the solution files unnecessarily checks-out , assuming I'm going to add the Dll project into the solution. I cannot do it , as it becomes a duplicate in every application solution that's using this dll project. Some devs in team have mistakenly done this too. After referencing the Dll project, they accidentally checked it in along with the app solution, creating an independent copy. :| Ideally, if App solutions can add a shared dll project virtually, from the TFS & share across multiple solutions , it'd would be awesome. But that's where Nuget is doing it's job, but with binaries. In other words, Just like how Nuget is working for sharing binaries, if the same could be done for common projects, it'll be great. Please excuse me if I've typed something stupid. I'm still trying to figure things out with TFS & common projects mapping. :) By far, Private-Nuget repo sounds clear & usable.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
