.Net Programming - Financial independence

Software Design of Multi-Solution Applications

Note: this topic is a bit more advanced compared to the tutorials so if you don’t feel comfortable enough, you can proceed to the next tutorial.

I must say that I’ve seen a lot of them in the last few months and I am still wondering why people keep designing multi-solution applications.

What is a multi-solution application?

A multi-solution application is an application that works in more than one solution containing one or more projects each. It can be used in a desktop as well as in a Web environment. I found a really good post about it and why it should not be used commonly.

Some examples?

Here are three different design ideas of the same project. The goal is to load information from a flat file (text) and transfer it into a database. Remember that design is an extension of the way you think, you might have a different point of view of this problem and it might change depending on the actual data we have to move and other considerations. Let’s just keep it simple!

Single Project

Single Project





I will point out a few issues I’ve been experiencing with the multi-solution pattern and try to launch a discussion about it.

Things get messy!

Learning a multi-solution application

Things can indeed get complicated when you try to learn how the application works. Depending on how it has been built in first place. I’ve seen a few cases where one solution was referencing multiple things in a few others. This can grow into a monster if you’re having a bug somewhere and try to figure out where it comes from.

Also, in a Web environment in particular, some parts of the application might be on the server already so as you are trying to debug one part, the problem can come from another section that is referenced by the current solution you’re testing and that is currently hosted on the server.

They are hard to learn especially if they are not well separated. One DLL or project should be, from my experience, completely separated from the others. Let’s say my current solution uses a DLL to read HTML language. The purpose of this solution should not be blended or ambiguous with the purpose of the DLL file, useless to say that they should be tested separately as well. In other words, all solutions should have a goal of their own.

In my opinion, the less amount of solutions and references, the better, unless it logically makes sense to separate things that way which is rare.

Dependency hell

If there is sort of a master solution in the application which shares a lot of things with the other solutions, that might have been a potential client for a project in a single solution instead of dividing everything into multiple solutions.

Also, given a Web application with multiple solutions on the same or different servers, pushing one of these solutions into a production or test environment with changes might create issues that were not present in local testing because of the dependencies involved. Sometimes, on the client side of a Web application, some .js files might be contained in another solution which will force you to build and publish two solutions instead of one and start to manage both at the same time.

Another thing I came across is that it can be more complicated to set up the different environments and Web.config to make sure the right connections and dependencies are applied.

One to one project/solution relationships

From my experience, any one to one is a case for revision because it might not be needed or can be combined. A solution should contain all the required files to work well on its own like .js and .css files. I am not talking about external dependencies here like other projects in the same solution.

Never too big

No common project is big enough for using this in my opinion, why? Because, from my experience, people tend to design applications in a far too extensible way now. In other words, they want to be able to add stuff easily in the future for an application in which the future goals might not be clearly stated, therefore this can add a lot more work than needed for the designers and the programmers. Especially if they decide to renew the application completely just a few years later because the needs have changed or because of the pace of technology. Maintenance time and costs might be impacted too.

Why not create multiple projects?

I would say, unless there really is a huge difference in solutions, it can fit into one solution by adding multiple projects to it. Projects should have a clear distinction as of why they should not be part of the main project.

Use of folders/namespaces

Visual Studio automatically create new namespaces according to the folders you add in your project (C#), that can be used to make divisions between modules. From what I’ve seen, some people tend to create new projects and then dependencies between these projects instead of simply creating namespaces for separating things that are clearly related to the same project.

Here is an example: an application is used to create reports from a database. It has three modules, a user interface, a report processor and a data access layer. In some hardcore cases, I’ve seen one project for each module which is clearly overkill unless you plan on creating a few other applications using one module or the other. This application can be divided into 3 namespaces or even only one according to its simplicity and the situation.

As a rule of thumb, knowing if you should not divide would be: if you need to modify a component of another solution to fit your needs in the current one would mean that these two components should probably be in the current solution. Remember that both solutions should be detached completely yet one(or multiple) using the other.


Why create multi-solution applications? In my opinion it depends on the situation, but I have yet to see a situation on which it applies. Again, this is just my opinion on the subject and is based on my work experience, you might have another point of view that you would like to share, feel free to comment!

Next article What Are Utility Classes (And Why I Hate Them)
Previous article A closer look at Windows Forms (Part 2) - Visual Basic/C#

Related posts


No Comments Yet!

You can be first to comment this post!

Leave a Comment

Your data will be safe! Your e-mail address will not be published. Also other data will not be shared with third person. Required fields marked as *