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.

OK

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?