How to Refactor a Visual Studio 2012 Solution under Source Control

Introduction

A Visual Studio 2012 solution can contain an unlimited number of folders and projects.

The development environment manages the binding between the logical and the physical project structure.

This topic will demonstrate a possible way to refactor a VS 2012 solution.

Background

A minimal VS 2012 solution is described as follow:

• .sln: The solution file which contains the bindings to projects, item and configuration
• .suo: The user options solution file which contains VS 2012 preferences like breakpoints

But it can also contain the following items:

• .csproj: project file Folders : logical and physical folder used to structure the solution

The logical folders are the folders visible in Solution Explorer of VS 2012, the physical folder are the folders visible in file system.

Solution File

Projects Section

That file is composed of 2 sections, Projects and Global. The global section contains the link to the projects and folders with the following format:

Folders

Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}")
= "01 ProductionCode", "01 ProductionCode", "{EBE6E272-7E8D-45B5-83D5-5C435C78DA35}"EndProject

Projects

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ConsoleApp",
"Src\ProductionCode\Application\ConsoleApp\ConsoleApp.csproj", 
"{6CB95162-8FE1-40D2-87BA-CD70750859E9}" EndProject   

The first GUID defines the type identifier of the resources (Folder, Project, Resource file). Every folder in the project has the same identifier hash.

The second GUID defines the folder identifier.

The path defines the location of the item.

Global Section

The global section is generally divided in 4 sub-sections:

• SolutionConfigurationPlatforms: defines solution’s configuration (Debug/Release)
• ProjectConfigurationPlatforms: defines project’s configuration (Debug/Release)
• SolutionProperties: defines the solution’s properties
• NestedProjects: define the solution’s tree (only GUID key are used)

How to Structure the Solution

We will use the terms “Internal structure” to define the structure of the “source” folder and “External structure” to define the structure of the whole project hierarchy (including external libraries, compiled code etc…).

The internal structure of a solution depends of the application architecture. For example, a client/server application will not have the same structure as a web application. In this example, we separated the production code from the test code.

The external structure meanwhile is architecture independent. Here, a possible way to structure a project is as follows:

• Main: contains the main branch of the project
• Src : folder containing source code
  • ProductionCode: folder containing production code
  • Tests: folder containing prototypes, tests app
• Lib: folder containing externals
• librariesSolutionName.sln: the solution file
• Development: contains a branch for each delivered package

An advantage of this solution is that the “Src” and the “Lib” folder are separated. In this way, all needed libraries are referenced from “Lib” folder avoiding references’ problems through team work.

Physical Refactoring

First of all, get the last version of the project from source control. If we are getting the project for the first time, we’ll need to choose a mapping folder.

Once done, the whole project has been copied to your local source control folder.

There are many ways to make a physical project refactoring. In this topic, we will use the “source control” view to do it.

As the source control is mapped with a local folder, all changes made in source control view will be passed to the local folder after TFS synchronization.

The source control view allows creating, moving or removing folder. Make the necessary steps to reach the desired structure.

Note: If we need to remove a folder, we need to “check in” the structure in source control to see the effect of the remove. Do not hesitate to “check in” multiple times during physical structure refactoring.

Once the physical structure of your project is fixed, we can take a look at the logical structure.

Logical Refactoring

The changes made in source control view are not synchronized with the .sln file.

Depending on your changes in source control, your project’s structure should display some loading errors. To fix up that problem, we need to correct the .sln file.

As already said above, the logical structure is defined in the .sln. As long as the project is under source control, the changes made on the files are not seen by source control.

To allow the modifications on the solution file outside the environment, right-click on the root of the solution and select the “Checkout for edit” option.

It’s important to close the solution in VS2012 before editing the solution file.

Open the .sln file from Windows explorer with an application like Notepad++.

Edit each path containing .csproj files (in Project section) with the new physical path (red) like in the example below:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}")
= "ConsoleApp", "Src\ProductionCode\Application\ConsoleApp\ConsoleApp.csproj",
"{6CB95162-8FE1-40D2-87BA-CD70750859E9}" EndProject  

Once all the paths have been fixed, you can try to open the solution. If your application loads every project correctly, your job is done!