Building a Development Environment Part 3: Managing the buildprocess Nant and Visual Studio

This is part 3 in my series on managing the build process.

What have we got till now? Well, we’ve setup a source code repository in Part 1 and setup CruiseControl.NET to monitor it in Part 2. But we wouldn’t need all this if we didn’t want to develop some software and thus have some source code we want to maintain and build.

That is what we will do in this part of the series: Create a simple library written in C# and build it automaticaly.

But first:

Disclaimer

This post is by no means “The Way” of building a development environment. In fact, you will notice that at times I deviate from some of the practices advocated by the referred articles at the end of my articles. It’s our interpretation of the process and how we implement it. If you have any remarks or suggestions for improvement, please post a comment.
Continue reading

Version numbering: solutions to questions remaining

A while ago I posted an entry about version numbering and ended it with two questions:

  1. When is backward compatibility broken? This probably looks like a stupid question, but imagine: A DLL named “SomeFunctionality.dll” uses some other DLL’s, named “Other.dll” and “MoreOther.dll”. But then this ”SomeFunctionality.dll” is changed and doesn’t use “Other.dll” anymore, but uses “Another.dll”. However, the interface of “SomeFunctionality.dll” didn’t change. Is backward compatibility broken or not?
  2. What about customer related changes to old software which breaks backward compatibility? Say for example you have version 1.1.0.1 at a customer site. Meanwhile version 2.x.y.z has already been released. Now the customer with version 1.1.0.1 wants some new feature which breaks backward compatibility. However, major version 2 is already taken. What major version do you use?

After some thought I will present you today with possible solutions.
Continue reading

Give Meaning To Your Code – naming of variables and types

The rule
This probably sounds obvious, but apparently it isn’t. What’s more, if you think about it, it even isn’t that easy to make the difference.

Your variables have a Behaviour and a Role
Behaviour maps to the type of your variable, and the role maps to the name of your variable.

The problem
We’ve had a round of code review today and while looking into the code I saw some classes which where really a packing of the same members into several classes. Those classes where then given different names.

An simple example will make clear what I mean (These are my own samples and not the real code):
(code is C++)

class Person
{
public:
   int GetAge();
   void SetAge(int age);

private:
   int m_age;
}

class Husband
{
public:
   int GetAge();
   void SetAge(int age);

private:
   int m_age;
}

class Wife
{
public:
   int GetAge();
   void SetAge(int age);

private:
   int m_age;
}

The Solution
In the above sample code, the classes Husband and Wife shouldn’t really exist. You should use variables with names husband and wife and with type Person. The role is husband and wife and they have the behaviour of Person.

This requires knowledge of the domain your application is written for because the distinction isn’t always that easy, as you will see in the following caveat’s.

Caveat
You probably think that this is obvious and in the above classes it is. But what if you have a class Person and you want to model “Male” and “Female”. Do you create new classes representing those or do you add a member “Sex” to the above class in which you make the difference between males and females?

Or maby you will have started with a class named Male, and then later you want to model females too. Will you make a class Female, or will you rename your class Male to Person and add the Sex member? The last solution will require you to adapt your code everywhere you use Male to set it’s Sex member.

You may also have two classes which are very common but differ slightly. Should you pack them into one class, or should they stay different. Maybe they must inherit from a common baseclass.

Updates
11 November 2006: original version

A Filenaming convention for C#

The Problem

While experimenting for my series of articles on building a development environment using Visual Studio 2003, I came across the following:

Let’s say you have a software component which implements a particular concern of your application, and this component has a class named MyClass. Thus, in Visual Studio we have a project of type “Class Library” which is contained in a solution and inside this project we have a file MyClass.cs which contains the code for our class. You compile a debug version of this library which gives you a DLL and a PDB file (program debug database).

Next you have your application which also has a class MyClass, but in a different namespace, however also in a file called MyClass.cs. Your application uses the above library, but it references the library DLL itself and NOT the Visual Studio project file. For this you copy the DLL and corresponding pdb file to the debug folder of your application. Also, the source code of the library is no longer available at the location on your harddrive where it was when the library dll got build.

Now, when you start debugging your application and want to step into the code of the MyClass of your library, Visual Studio jumps around in the MyClass.cs file of your application.

What is happening

It is clear that Visual Studio is mixing up the sourcefiles of your library with the ones of your application:
Because the source code is no longer available at the original location, Visual Studio can not go there to look for it. But because the sourcefile in your application has the same name as the one in your library Visual Studio assumes this is the source file of your library and starts jumping around in your applications file as if it where your libraries file.

A possible solutions

Naming conventions
The solution is simple, keep the names of your sourcefiles unique. The easiest way to do this is simply by prepending the namespace to the name of your files.
This code like this:


namespace ClassLibrary
{
public class MyClass
{
// Rest of class ommited
}
}

ends up in a file named ClassLibrary.MyClass.cs

Your environment
I’ve tried the same in Visual Studio 2005 and found no problem there. So you could switch to this IDE. But this will not be possible to everyone of course.

Building a Development Environment Part 2: Setup CruiseControl.NET for continuous integration

In this second installment in a series of posts about building a development environment I will discuss the setup of a continuous integration server.

I will not try convince you of using continuous integration in your process, or discuss the possible benifits of using it. A lot has allready been written about this. If you have decided to use continouos integration and are looking for experiences and practical advice on implementing the process, then this post can be of some help.

Disclaimer

This post is by no means “The Way” of building a development environment. In fact, you will notice that at times I deviate from some of the practices advocated by the referred articles at the end of my articles. It’s our interpretation of the process and how we implement it. If you have any remarks or suggestions for improvement, please post a comment.
Continue reading

Building a Development Environment Part 1: Managing your sourcecode with Subversion

This first installment in a series of posts about building a development environment is about repository lay-out and getting the code out of your source control system.

I originaly was planning on writing a series of articles about how we implemented continuous integration (CI). However, while experimenting and searching the internet for information, I quickly came to the conclusion that this whole CI thing was just to narrow in scope. There is a lot of information and a lot of blogs discussing CI, but most of them are people starting to write a simple application and them being the only one working on it. So, no projects made of multiple subprojects, no projects shared by other projects, no developer interaction, etc…

But in a real company you do have several developers, you do enable reuse and thus use a project in multiple other projects, you do have organisational standards (how projects must be setup, where code must be commited in the source code repository, etc…) that must be applied, etc… Some of this interacts with CI and this is way I made the scope of the series bigger:

How Do I Build An Environment To Develop Software?

Disclaimer

This post is by no means “The Way” of building a development environment. In fact, you will notice that at times I deviate from some of the practices advocated by the referred articles at the end of my articles. It’s our interpretation of the process and how we implement it. If you have any remarks or suggestions for improvement, please post a comment.
Continue reading