Duplicate Visual Studio Solution as Starting Point

As a programmer, you often find yourself in a situation where you want to create a new solution (or just a project in the solution), but it has many similarities to an existing solution. Visual Studio itself does not offer a duplicate or clone function. Of course, you could now go and make a new empty solution, and at least take over the elements from the other solution by "Add->Existing Item..." into the new one. But after that you still have to deal with a considerable amount of settings, which you would have to set all the same as the old one. A tedious and mindless task. But with String Hunter™ of Mighty Desktop it's much easier:

1. Make a duplicate of the entire solution directory (or the project directory).
   
   
2. Go into the String Hunter™ tab, specify the directory and start a search for the name of the old project, in filename and content. The 'Case sensitive' and 'Whole word' boxes should be checked.
   
   
3. At the end you are in the tab 'Matches'. There you run the replacement function to replace all finds to the name of the new solution. Unlike in other product's replacement functions, the files will be renamed as well in String Hunter™ of Mighty Desktop.
   
   
4. Now you have to assign new GUIDs for all projects in the solution. To do this, double-click on the files "*.sln" and ".csproj" in the finds, which will display them in your preferred text editor (we recommend Notepad++). Up to now it has proven as good practice to make notes of the replacements in the form "old -> new" in a new window in Notepad++.
   
   
5. In "*.csproj" one assigns a new GUID in the tag <ProjectGuid>. This can be done e.g. with Mighty Desktop in the tab Toolbox. Attention, only in <ProjectGuid>, but not in <ProjectTypeGuids>.
   
   
6. In the "*.sln" you replace the old GUIDs of the projects with the new ones (the last GUID on the line).
   

Attention: You have to check the Solution- and Projectfiles whether they contain other GUIDs. If so, it's a bit difficult to decide if this is a variable GUID, because also the constant enumeration values are represented by GUIDs in COM (which is in charge here). If in doubt, you can simply search online for a GUID. Usually constant GUIDs will be found in a Microsoft text. As a test you can also search for the old GUIDs in the *.sln and *.csproj by full text search to not miss any. Unfortunately this step is a bit tedious and if you do something wrong, or even forget something, you may end up with some subtle problems later on. For example, in the case of Visual Studio AddIn solutions, remember that each menu and menu function MUST get a new GUID, otherwise it may overlap with another solution's AddIns when loaded.

Now finally comes the big tadaaaa moment: You open the Solution in Visual Studio. If Visual Studio throws error messages, you did something wrong. You should then double check everything that was described above. If the worst comes to the worst, just start over and work through it meticulously. For testing you can compile the solution once and start it.

Even if this procedure seems complicated, after a few times you will have it under control. In any case it saves a lot of time, because now all the settings, of which there are hundreds, are correct and don't provoke time consuming searches for the cause of different behavior. You should always be aware of the fact that these settings were the result of long and time-consuming fine-tuning work. That's why a duplication makes perfect sense.

Every programmer should actually learn this duplication procedure in class, or Microsoft should add a duplicate function to Visual Studio.