Mapping your Visual Studio Projects and Solutions to Jazz Components
Introduction
In Jazz source control, the fundamental organizational unit for source code is a component. When you create a component, you’d typically put related projects together (for example, projects that are built together or form a subsystem). Projects put into one component can then be re-used in multiple solutions. This promotes not only re-use of common code, but also gives you a mechanism where your are always aware if any changes have happened to these common components.
In the following scenario, we see a C# developer initially start with a single solution and a few nested projects. She later decides that there is some common code that can be moved to its own component, in order to facilitate re-use of this component in other projects. Read on to see the steps she takes to move to this approach.
Cindy Sharp is a Visual Studio developer who wants to try out the Rational Team Concert for Microsoft Visual Studio. She’s working on a project that at present consists of a single solution, Client, with three projects in it – Core, Tests and Library.
Core implements core client functions and Test contains test classes for the client functionality. Library contains a common set of functions that can be used by the Client module or by other modules.
Here is how Cindy’s solution looks, to start with.
And here’s the folder structure on disk.
However, Cindy thinks that, while Core and Tests belong to the Client module architecturally, Library should belong to a Common module that has common utilities which may be used by all modules in the application. She wants to map her modules to Jazz Components so that the Jazz SCM works well with her system’s architecture.
For Visual Studio users, the recommended way to map projects and solutions to Jazz components is to organize the source code into partitioned solutions and map each solution to a Jazz Component. In the partitioned solution approach, groups of related projects belong to a solution, and the same project can be a part of many different solutions. Each project has a “home” solution where it will be created and developed. The project will be included in other solutions that depend on it, as “existing projects”. Each partitioned solution will be mapped to a Jazz component.
In order for Cindy to follow the recommendation, she needs to organize her current sources into two partitioned solutions – Client and Library. “Library” will be shared eventually into a Jazz Component named “Common” and “Client” into a Jazz Component named “Client”.
The “Library” project will be homed in the “Library” solution. “Client” solution will home the “Core” and “Test” projects and will include the “Library” project, on which it depends, as an “existing” project.
As a first step of doing this, Cindy will have to move the “Library” project out of the “Client” solution.
Moving the “Library” project
To do this, Cindy closes the “Client” solution. She navigates to the “Client” folder on the solution explorer moves the “Library” folder up.
Next, she opens the “Client” solution, ignoring the warning about unavailable projects.
The Library project shows up as unloaded, since Visual Studio could not find it at the expected location under the solution folder.
Now Cindy needs to change the properties for the “Library” project, to make it point to the right location. Clicking on the ellipsis (…) in the “Show Properties” View brings up the “Locate Project File” dialog where Cindy can navigate to the current location of Library.csproj.
Cindy double clicks on the csproj file to change the location. Next she reloads the project by right clicking on Library and selecting reload in the Solution Explorer.
The project reloads from the new path, and the solution builds.
Creating the “Library” Solution
Next Cindy closes the solution and navigates to “Library.csproj” on the Windows Explorer. She double clicks on the file and it automatically opens up the project in a solution with the same name.
Cindy saves the solution file in Visual Studio
Voila, she’s done reorganizing the sources into two partitioned solutions, which is what she set out to do.
Here’s the new file layout on the disk.
And here’s the new “Client” solution, which includes the “Library” project homed in the “Library” solution.
Sharing the solutions
Now that Cindy has the source code organized the way she wants, she shares the Client solution into the Client component and the Library solution into the Common component.
She follows the guidelines in https://jazz.net/library/article/117, which discusses the sharing of partitioned solutions.
Once she’s shared the solutions, she browses repository files for the two components.
The Client component contains the sources for the Client solution, while the Common component contains sources for the Library solution.
Cindy can map multiple solutions to each of her components. Now that she’s gotten started, she can create new solutions and map them to new Jazz components as well – based on her module design.
Yes