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.


Figure 1 : Cindy Solution Structure Initial

And here’s the folder structure on disk.


Figure 2 : Initial Folder Structure

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.


Figure 3 : Moving Up Library Folder

Next, she opens the “Client” solution, ignoring the warning about unavailable projects.



Figure 4 : Project Not Loaded Warning

The Library project shows up as unloaded, since Visual Studio could not find it at the expected location under the solution folder.


Figure 5 : Library Unavailable Solution Explorer


Figure 6 : Library Unavailable Solution Exp Core

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.



Figure 7 : Locate Project File

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.


Figure 8 : Reloading Library

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.



Figure 9 : Creating Library

Cindy saves the solution file in Visual Studio



Figure 10 : Save Library As


Figure 11 : Library In Solution Explorer

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.




Figure 12 : New File Layout

And here’s the new “Client” solution, which includes the “Library” project homed in the “Library” solution.



Figure 13 : New Client 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.



Figure 14 : Sharing The Solution


Figure 15 : Sharing In Jazz

Once she’s shared the solutions, she browses repository files for the two components.



Figure 16 : Repository Files

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.

Feedback
Was this information helpful? Yes No 3 people rated this as helpful.