Jazz in the Real World – .NET usage

I recently spent a day on site with a customer and one of the smart people that I work with, Jean-Michel Lemieux.  Jean-Michel is one of our development managers, he knows what he is doing, and he knows RTC and Jazz better than most of the people that I know.  We went to visit a customer that was having issues in using Rational Team Concert in their .NET environment.  This customer was not able to put their code under Jazz SCM control in a way that was convenient for the development team to work with.

For those of you looking at deploying Jazz technology, and RTC in particular, try doing a review of our Jumpstart Jazz Deployment Guide.  For those of you looking to deploy Jazz to support .NET development with Visual Studio, start with Jean-Michel’s article, Source Controlling Projects and Solutions in Team Concert, which is referenced in our guide.  Sreerupa Sen has a wiki entry on Mapping VS Projects and Solutions to Jazz, that is also informative.    I wanted to share this blog entry with people because many people are unaware of these resources, and I figure that an overview of the issue and solution might help make these things more clear to our customers.

The biggest complaint of our customer was that they could not find an effective way to put their .NET code under Jazz control.  The developers for this project liked to keep their own versions of the solutions (.sln) files, and did not want to put these under Jazz source control.  They did want to put the code and the various .NET project (.csproj) files under Jazz source control.  They knew how to place things under source control, but were struggling with how to architect the directory structures and organization of the projects to best meet their needs, and their usage patterns.

Our first step was to get the creation of NEW solutions and projects to work properly.  With only the source code and the Visual Studio project (.csproj) files under Jazz source control, whenever we tried to add a new project or solution to the environment, we would get an error.  The reason for this is because when creating a new Visual Studio project, the source control bindings for the project are inherited from the “parent” solution.  So we decided to go out and create a solution at the top of the directory structure. We then put this high level solution under Jazz Source Control.

Once we created this solution, any solutions or projects created underneath this directory level picked up the proper source control bindings, and were visible in the Visual Studio IDE.

Visual Studio Lesson #1 – Place a “default” solution at the top directory level of your file structure.  This will ensure that you pick up the proper source control bindings, and get consistent behavior in the Visual Studio IDE.

Visual Studio Lesson #1A – Make the directory structure within your Jazz components the same as what you see on your local disk.  Your Jazz local sandbox will then have the proper directory structure for use with the Visual Studio IDE.

Sample Directory Structure for .NET Environments

This worked fine for the case where people were sharing solutions, and wanted these solutions to be under Jazz Source Control.  This particular customer had developers that did NOT want their solutions under source control, and instead wanted to have their own solutions.  How do we make sure that they are able to change these solutions, and not have their own private changes overwritten any time a new update for the top level solution file is checked in?

The key here is to use the .jazzignore file properly.  The .jazzignore file has a list of file types that should be ignored for a particular directory.  These files are not considered as candidates for updates to the repository, and so even if you change them, they do not get checked in (or delivered) to the Jazz SCM repository.  They also will not show up in your Pending Changes view.  A typical ,jazzignore file is just a text file, can be edited with a simple text editor, and might have an entry that looks like this:

core.ignore.recursive= \
{*.class) \
{*.user} \
{Debug} \
{TempPE} \
{obj} \

What this tells the Jazz SCM client is that it should not consider any of the files that have these patterns, and that it should do so recursively (core.ignore.recursive) so all subdirectories will follow these visibility rules as well.  Be careful with this, and make sure that you don’t add solutions and project files in to ignore recursively.  You may just want to ignore those file types in PARTICULAR directories.  If you get unexpected behavior, you can always recover from these changes.  Just check out this entry on how to share changes to ignored resources, from the Jazz article on Jazz Source Control FAQs.

One thing that you need to keep in mind is that you will need to update these “default” high level solution files any time you add a new Visual Studio project, or a lower level solution.  Make sure that you share the addition of these new resources by making sure that you DO NOT ignore the high level default solution when initially adding these new resources.  Failure to do this may result in some unexpected behavior.  Once the new project or solution has been added, you can then safely ignore that high level solution file again.

Visual Studio Lesson #2 – Understand how .jazzignore files work, and if you want your own “personal” solutions, you might want to add an entry or two to your .jazzignore file.

In the situation where we wanted to ignore that “default” solution file at the top directory level, and have our own solution file, we would add an entry like this:

core.global.ignore= \
{*.suo) \

Finally a word of caution for users out there.  It is always best to model your proposed environment in Jazz before making the leap.  Create a small component and then bring in some files and put the high level solution in place.  Run through some basic developer use cases to make sure that things build properly, that you are able to properly add solutions and projects, and that you are able to deliver changes to a shared stream of development.  Once you are satisfied that you can do all of these things, then proceed ahead with your move to using Jazz technology to help bring some order and transparency to your Visual Studio development activities.

And ALWAYS look out on Jazz.net for new information and best practices.  That is one resource that has the answers to 95% of my questions, and it will for your questions as well.  Don’t forget to check the forums, because they will often have valuable information as well.  You can even post your questions out to the forums, and often get answers to your questions on how to best use Jazz in the real world.

One thought on “Jazz in the Real World – .NET usage

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.