Organizing a Visual Studio Solution for Two Similar Products

We have a VS2010 solution that contains one Windows Forms Application and 4 Class Libraries (DLLs). (Class libraries for things like BusinessTier, DataTier, CommonCode, ControlLibrary). All of this is for the 2.0 environment. It was like that for three years.


So our application has grown to the point where we want to add a big new feature, and marketing wants to deploy it as a separate product. Our product is used to fill out tax forms, and the second product is used to fill in other tax forms.

We want to end up with two exes (two installation MSIs) that will be sold / installed / updated independently and can run on the same computer at the same time. Most of the code is shared between the two applications.

I am trying to find the best way to structure a solution to create the desired result.

1) The first option might be to create a new EXE project and several new DLL projects in the same original solution (say in the solution folder) that have most of the filenames, codes, etc. refers to code files in source similar DLLS. This allows us to have two completely separate systems with unique names for all files, version numbers, etc., but allow any setting for each project / dll. Is this a good idea or overkill?

2) Option two is to create a new exe project in the solution and link it with the same DLLs as the first exe project. It seems straightforward enough, but I don't know if it's a good idea to have two projects that use the same DLLs. I don't want to use the GAC. If we have two exes using the same Dll (even if they are in separate application folders), would it be a problem if the DLLS have the same / different version numbers, name, or GUID?

What are your ideas?

How do I restructure my solution to host a new product?


source to share

1 answer

Go to Option 2

No problem with the same DLLs with the same names. If you deploy exes to individual folders, or keep them in separate folders, it will work either way.

I would even go ahead and see how you can split your application further into more assemblies / dlls, as that will give you even more flexibility. I will also have one file for AssemblyInfo and add it as a linked file to all of your projects. This means you have one version for all your dll / exes.



All Articles