Continuous Integration is a development practice that can help improve your company’s ability to deliver quality software. It can reduce the time to market and the deployment cycle from functional complete products to having the solutions deployed on desktop or servers.

Continuous Integration, or CI, can start with a lone developer desktop and mature closer towards production. The ultimate goal is to have a CI environment that can take you from checked-in code to production ready installation packages.

The instructions in this article will help you get started with CI even if you’re a single developer or a small team.

This is a process that takes time, but don’t be afraid of the road ahead, I will walk you through the first baby-steps towards a well-tuned machine. CI-practice is one of many important elements for the software development industry to mature to levels of other types of manufacturing.

Introduction to Continuous Integration

Martin Fowler has written a very good introduction to CI which you can read this on his website: http://martinfowler.com/articles/continuousIntegration.html [1]

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.

The clean and simple essence of CI is to avoid the situation “It works on my machine”. This has caused a lot of pain between developer and users, but also between developers. Most of us have experienced that our projects stops compiling properly after a Get Latest operation on the source control system. Another important aspect of CI is to have a cycles of automatic compilation and testing of your projects. We will get deeper into automatic testing later in this article.

Source Control Systems

If you are not familiar with source control systems (SCM), I suggest reading a good introduction by Eric Sink. While the first CI example I will give in this article doesn’t use SCM, it is an essential piece of the puzzle if you’re doing computer software development. Even as a single developer, it’s advisable to use a SCM. SCM will give you better control and management of your projects, with history and the ability to restore deleted code.

Introduction to SCM: http://www.ericsink.com/scm/scm_intro.html [2]

There are many providers of SCM software; for the purpose of this article we will use Microsoft Visual SourceSafe. When your team grows and you have the finances to purchase licenses, I suggest upgrading to Microsoft Visual Studio Team System, which is a complete Application Life-Cycle Management (ALM) suite.

Setting up your environment

There are various CI solutions available for .NET developers, one of the most popular is Cruise Control .NET (http://ccnet.thoughtworks.com/ [3]).

[Please note that all examples are from a 64-bit system where the Program Files paths includes (x86) for 32-bit applications. If you have a 32-bit environment, please make sure you remove any reference to (x86).]

Cruice Control .NET (CC.NET) comes in various forms, for beginners the setup alternative is the simplest to get you started (CruiseControl.NET-1.4.2-Setup.exe).

After the installation has completed, a new folder will appear in the Windows start menu. From here we can access the main configuration file and launch the console application.

Before we continue with updates to our configuration file, we need to learn a little bit about build tools…

Build Tools

To compile the source code, you will need a tool that does the build for you. One alternative is NAnt, which is a free tool (http://nant.sourceforge.net/ [4]).

With Visual Studio 2005 Microsoft introduced MSBuild, which is a standalone build engine for .NET. This has made it more accessible for third parties and made it simpler to automate and script.

The simplest way to get started with a build process is to utilize MSBuild, which is already installed if you have .NET Framework 2.0. We will configure CC.NET to start the MSBuild process which takes care of the compilation of our Visual Studio Solution.

New Project or Existing Solutions

It is much less effort to include guidance, frameworks, and tools in the beginning of a new project. This applies to CI as well. The further you get in the development process, the harder it gets to make everything work properly in a CI-environment.

Sample Projects

For the purpose of this article, we’ll create a new Visual Studio solution called IntegrationSample. Within this solution we will create 3 projects: IntegrationSample (Windows Forms), Integration.Common (Class Library) and Integration.Test (Class library).

Add a Person.cs class to the Common project with the following code:

This class represents part of our business domain model and has certain business logic applied to it that is important to our business, namely the method that tells us if a person is more than 60 years old. The next step is to apply a test for our domain object.

Automated Testing with Unit Tests

Being able to automate the testing process of your projects is an important feature of a CI-environment. Having source code that works as tests for your application logic will help you when you’re later going back to modify, extend and fix existing code. With good tests you can ensure that your code changes won’t break the whole application. There are different frameworks available for unit testing, the most widely used with .NET is NUnit (www.nunit.org [5]). To learn more about test-driven development, visit Wikipedia: http://en.wikipedia.org/wiki/Test-driven_development [6]

When the installation of NUnit is complete, you can explore the included samples to learn more about writing unit tests. You can use the NUnit GUI to run your unit tests outside of the CI-environment.

To start writing unit tests, you need to add a reference to the following assembly in your Integration.Test project: "C:\Program Files (x86)\NUnit 2.4.8\bin\nunit.framework.dll". Additionally you should create a reference between the Test and the Common project, so we can access our business domain model in the tests project.

When you’re done adding the reference, let’s create a class named PersonTest.cs which will contain all the unit tests for our specific domain object.

Tests are done through assertions. There are many types of assert methods included in the NUnit framework and you should use them to validate your business logic. Writing good unit tests is hard and it’s a practice in which you will continually improve as you get more experienced with it.

You can now begin to run and validate the unit tests on your local machine, open the NUnit GUI application and open the Integration.Test.dll file.

As you can see in my screenshot, both of the tests for the Person object validates. When we later go back to change the business logic, we can use the unit tests as a means to validate that our changes doesn’t break anything.

Bringing it all together

Let’s go back to the CC.NET configuration file and start modifying it so we get our CI-environment up and running. It’s advisable to have a dedicate computer that act as a build-computer, but it’s not a requirement.

The first thing we’re going to do is modify the default configuration file to run NUnit and our tests, here is the script so far:

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
 <project name="IntegrationSample">
  <tasks>
   <nunit>
    <path>C:\Program Files (x86)\NUnit 2.4.8\bin\nunit-console.exe</path>
    <assemblies>
     <assembly>C:\Source\Samples\IntegrationSample\Integration.Test\bin\Debug\Integration.Test.dll</assembly>
    </assemblies>
   </nunit>
  </tasks>
 </project>
</cruisecontrol>

Save the configuration and start the CruiceControl.NET application in the start menu. This will open a console application that will run your configuration. This is useful for beginners and when you’re setting up a new environment. When the configuration is complete, you should use the Windows Service for a more stable runtime.

When you ran the CC.NET installation, it should have created a virtual directory for you on the local Internet Information Services. If you happen to have any problems with this, make sure you create a virtual directory called webdashboard and map it to C:\Program Files (x86)\CruiseControl.NET\webdashboard.

Opening up the web dashboard should show us our IntegrationSample project and hopefully a green status, indicating that our unit tests has completed successfully. With the current configuration, we need to click the Force button to run tests.

This dashboard will be your viewport into the status and history of integration builds. You can drill down into the details of a build and you can have multiple CC.NET projects specified in the configuration file.

Our next step is to make CC.NET compile our source code using MSBuild.exe.

Within the <tasks> element in the configuration, add the following script above the NAnt task, which will tell CC.NET to execute MSBuild.exe with our Visual Studio solution file.

<msbuild>
 <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
 <workingDirectory>C:\Source\Samples\IntegrationSample\</workingDirectory>
 <projectFile>IntegrationSample.sln</projectFile>
 <buildArgs>/noconsolelogger /p:Configuration=Debug /v:m</buildArgs>
 <targets>Build</targets>
 <timeout>720</timeout>
 <logger>C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>

To validate that CC.NET is working correctly, we can go ahead and make a quick modification to the source code. If you reverse the operator for the age method, we should see the IntegrationSample fail on the dashboard. Drilling down into the details, we should see that our unit test fails.

The last and final step is to add support for a source control system. As you have now seen, you can setup an CI-environment without source control, but it makes sense to use source control. A source control system adds history and backup support and the ability to make heavy and local changes and not disrupt the active codebase which is inside the source control database.

Visual SourceSafe 2005

If you don’t have a source control system yet, an easy way to get started is with Microsoft Visual SourceSafe 2005. With an MSDN Subscription, you can download it from the downloads page.

When you go beyond a small team of programmers I suggest upgrading the source control with a more modern provider, like Visual Studio Team System or SourceGear [7].

Going back to Visual Studio and our IntegrationSample project, we will go ahead and add it to our source control provider of choice.

When the solution and all the projects is added to the source control, we can open the Visual SourceSafe Explorer and see how our newly added project is added and we can begin to check-out and check-in code changes.

We’re now ready for the final changes to our ccnet.config file. Open up the configuration file from the start menu and add the following new elements to the top beneath the <project> element.

<triggers>
 <intervalTrigger seconds="60" />
</triggers>

 <sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
 <executable>C:\Program Files (x86)\Microsoft Visual SourceSafe\ss.exe</executable>
 <project>$/IntegrationSample</project>
 <username>build</username>
 <password>Password123</password>
 <ssdir>C:\Source\VSS</ssdir> <!-- Path to your SourceSafe database -->
 <workingDirectory>C:\Source\Samples\IntegrationSample\Build\</workingDirectory>
 <cleanCopy>false</cleanCopy>
</sourcecontrol>

Make sure you use a different working directory than your normal project folder, if you are running CC.NET on the same machine that you’re developing on. You also need to modify the <workingDirectory> and <assembly> elements we created earlier. See the bottom of the article for a full version of our build script.

When you start CruiceControl.NET again, you should see something similar to this output. Please beware that it can take a short while for the process to start.

As you can see, the script finds that there has been modification in the project inside our source control, which triggers a get process of the source code and later compilation and test-run.

You can specify your own trigger interval in the configuration file, depending on the size of your development team and your software, you can tune it to make sure you build often, but not so much that your build server starts having trouble.

You should create a special user account that your build process can run as and access the source control, as you can see in the example above I created a user called build.

Now it’s time to test the whole cycle of editing source code, check-in, watch the build server figure out there has been a modification and trigger a compilation and test-run. Let’s check out the Person.cs file and modify the age check to make our unit tests fail.

When you’re checking code back into the source control system, it’s good practice to add an informative comment. This is useful for historical purposes and for other team members to get an overview of changes in the history view.

After checking in our changes, we only need to wait a few seconds to see that CC.NET discovers our change and runs our script.

Congratulations, you now have a CI-environment up and running!

Going Forward

We have looked at the base tools in a CI-environment, going forward I suggest taking a look at frameworks and tools that works good together with CC.NET. FxCop [8] is a tool from Microsoft that analyzes your assemblies and reports anything that is not according to the industry standards for naming conventions, etc. NCover [9] is a tool which will generate code coverage reports (that means it will highlight which application logic in your application is being covered by unit tests). If you’re a component shop, API documentation is important. Using tools like SandCastle [10] you can automatically generate help files from your XML comments.

There is a whole world to explore and the extension ability to your CI-environment is endless and everything is there to help you improve the process of building good software with high quality.

You should now understand how to setup your own CI-environment using free tools. Best of luck in setting up your own environment!

References:

[1] http://martinfowler.com/articles/continuousIntegration.html

[2]http://www.ericsink.com/scm/scm_intro.html

[3] http://ccnet.thoughtworks.com/

[4] http://nant.sourceforge.net/

[5] http://www.nunit.org/

[6] http://en.wikipedia.org/wiki/Test-driven_development

[7] http://www.sourcegear.com/

[8] http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx

[9] http://www.ncover.com/

[10] http://www.codeplex.com/Sandcastle

Sample Soure Code (includes the ccnet.config build script):

IntegrationSample.zip

Build Script

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
 <project name="IntegrationSample">

  <triggers>
   <intervalTrigger seconds="60" />
  </triggers>

  <sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
   <executable>C:\Program Files (x86)\Microsoft Visual SourceSafe\ss.exe</executable>
   <project>$/IntegrationSample</project>
   <username>build</username>
   <password>Password123</password>
   <ssdir>C:\Source\VSS</ssdir> <!-- Path to your SourceSafe database -->
   <workingDirectory>C:\Source\Samples\IntegrationSample\Build\</workingDirectory>
   <cleanCopy>false</cleanCopy>
  </sourcecontrol>

  <tasks>

   <msbuild>
    <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
    <workingDirectory>C:\Source\Samples\IntegrationSample\Build\IntegrationSample\</workingDirectory>
    <projectFile>IntegrationSample.sln</projectFile>
    <buildArgs>/noconsolelogger /p:Configuration=Debug /v:m</buildArgs>
    <targets>Build</targets>
    <timeout>720</timeout>
    <logger>C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
   </msbuild>

   <nunit>
    <path>C:\Program Files (x86)\NUnit 2.4.8\bin\nunit-console.exe</path>
    <assemblies>
     <assembly>C:\Source\Samples\IntegrationSample\Build\IntegrationSample\Integration.Test\bin\Debug\Integration.Test.dll</assembly>
    </assemblies>
   </nunit>

  </tasks>
 </project>
</cruisecontrol>

—–

Sondre is a Microsoft Regional Director with 11 years of experience in software and web development. He currently works as Technology Leader for the Microsoft department at Capgemini in Oslo, Norway. Sondre is additionally the leader of the Norwegian .NET User Group in Oslo and a speaker at various technology and software development events. Active blogger, writer and technology enthusiast with a special passion for robotics, intelligent systems and open source.

"This tiny program will save up to 70% of your battery by disabling those nice, but greedy Vista features."

When you switch from running on AC power to running on battery, Vista Battery Saver will disable the Windows Sidebar and Aero features and switch to a more conservative power plan (e.g., from High Performance to Power Saver). When you reconnect to AC power, Vista Battery Saver switches everything back to the full Vista experience.

The Vista Battery Saver project was started by Tamir Khason. Listen to our interview with Tamir using the embedded audio player or download the MP3.

—–

CodePlex is Microsoft’s open source project hosting web site. Start a new project, join an existing one, or download software created by the community. Learn More

Be sure to read Donald’s article “Working with Brownfield Code“.

One of the most underutilized productivity features in Visual Studio 2005 and Visual Studio 2008 is Code Snippets. Even though most developers have heard about them, I find when working with consulting customers that there are few developers who use them on a regular basis. Even if they do use them, they vastly underutilize them by only using a couple of them and never create their own. In this article, I give you a quick intro into what code snippets are, how they work, what is available out of the box, and how to go beyond that by quickly creating your own code snippets.

Code Snippets Overview

Code snippets were introduced in Visual Studio 2005 and allow you to emit a chunk of code into your editor by typing a few keystrokes (a shortcut mnemonic). I’m going to use C# for the examples in this article, but just realize that code snippets work in Visual Basic and other .NET languages as well. That chunk of code can just be a static chunk of code, but what really makes code snippets powerful is that they can have placeholders that you can quickly overtype when you invoke the code snippet.

To try them out, the best one to start with is one you can probably use the most often: the prop snippet. Code snippets have both a title and a shortcut, although these will often both just be set to the shortcut value. The prop snippet emits a property with a backing member variable in Visual Studio 2005, or an auto-implemented property in Visual Studio 2008. Code snippets show up in the IntelliSense list as well, so if a snippet has a longer shortcut than a few letters, often you can just invoke it by typing a few of the letters and select it out of IntelliSense.

For example, if I go inside a class declaration and type prop and hit Tab twice (once to dismiss the IntelliSense list, the second time to invoke the code snippet), I get the following in the editor:

public int MyProperty { get; set; }

The type and property name will be highlighted in green, indicating that they are the placeholders defined in the snippet. For this snippet, the type is the first placeholder and will be selected so that if you start typing, you will overtype what is there. So for example, say I want a string property. I type string and hit Tab. Tab moves between the placeholders, and when the focus is placed on the next placeholder, it selects it as well so you can overtype with the value you want. So if I type Name and hit Enter, I leave the placeholder mode and my changes are accepted. If I keep hitting Tab, it revisits the placeholders in order in case you accidently tabbed past one or changed your mind as you were filling things in.

This one may not be stunning in its time savings, but when you add up the keystrokes (4 + 1 + 6 + 1 + 4 + 1) you have 17 versus the 30 for typing out the whole property yourself. Wham! You just became almost twice as fast at writing code! OK, don’t tell your manager just yet, you need to actually get used to doing this all the time first…

Now consider setting a switch case statement for an enumeration with a number of values. For example, say you needed to set up a switch/case on the states for System.Windows.Input.MouseAction. If you had a local variable of that type with something like the following method:

public void HandleMouseInput(MouseAction action)
{

}

If I go inside that method and type switch Tab Tab, I get the following snippet with a placeholder on the variable switch_on.

public void HandleMouseInput(MouseAction action)
{
  switch (switch_on)
  {
    default:
  }
}

If I type in action for the placeholder (the local variable of enum type MouseAction) and hit Enter, the snippet fills in all the enum values as case statements:

public void HandleMouseInput(MouseAction action)
{
    switch (action)
    {
        case MouseAction.LeftClick:
            break;
        case MouseAction.LeftDoubleClick:
            break;
        case MouseAction.MiddleClick:
            break;
        case MouseAction.MiddleDoubleClick:
            break;
        case MouseAction.None:
            break;
        case MouseAction.RightClick:
            break;
        case MouseAction.RightDoubleClick:
            break;
        case MouseAction.WheelClick:
            break;
        default:
            break;
    }
}

That is a huge keystroke savings filling all the tedious structure code! You just need to fill in what to do for each case.

Built-in Code Snippets

The list of built-in code snippets for C# is actually fairly short. There is really only a small number included out of the box. You can find the full list here with a short description of each for the core C# language snippets: (http://msdn.microsoft.com/en-us/library/z41h7fat(VS.80).aspx). There are some additional ones in other categories that ship with Visual Studio 2008, but the list is still fairly short for C#.  Visual Basic actually ships with hundreds. But this shouldn’t make you feel shorted as a C# developer. You can actually find a greatly expanded library of C# code snippets that shipped after VS 2005 here: http://msdn.microsoft.com/en-us/vs2005/aa718338.aspx. You can also find libraries of other code snippets out on CodePlex and other places on the net.  do, while, for, foreach, and a number of other common control structures are all in the basic set, along with everything from data access patterns to file IO patterns in the expanded sets. ctor is another one that is handy for declaring a default constructor for a class.

There is a Code Snippet Manager in the Tools menu of Visual Studio that will let you browse all the built in snippets, import new ones, and search online. However, if you understand what is going on under the covers, it is actually easier to just manipulate them as files.

Inside Code Snippets

Code snippets themselves are nothing more than XML files with a particular schema that reside in some directories that Visual Studio is aware of. Specifically, snippet files end with a (not surprising) extension of .snippet. The built-in code snippets that ship with Visual Studio reside under the folder C:\Program Files\Microsoft Visual Studio 9.0 under VC# or VB respectively. Visual Studio is the default editor for that file type, so you can just browse to those folders and double click on the .snippet files and edit the XML in Visual Studio. If you want to create your own snippets, put them in your Documents folder under Visual Studio 2008\Code Snippets\Visual C#\My Code Snippets (or similar path for VB or 2005). Visual Studio watches this file all the time, so changes or additions to snippets take effect immediately without needing to restart Visual Studio.

There are a lot of elements supported in the schema but the key ones to focus on are Shortcut in the Header element, and the Declarations and Code elements under the Snippet element. Say I wanted to emit a code snippet like the following with a placeholder over the Boo! string so I could overwrite it:

System.Console.WriteLine("Boo!");

To do so, I would have a code snippet that looks like this inside:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Shortcut>cwboo</Shortcut>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>output</ID>
          <Default>Boo!</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[System.Console.WriteLine("$output$"$end$);]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

In this case, the IntelliSense shortcut to invoke it is cwboo. The code snippet declares one literal variable named output with a default value of Boo!. The actual code of the snippet has to be declared inside an XML CDATA section because some legal characters in C #and other languages could cause XML parsing errors. The output literal is a named placeholder in the emitted code which will be replaced with the default value and highlighted for overtyping as discussed earlier. You can see that when you use a literal in the snippet, you enclose it within leading and trailing $ delimiters. Everything else in the snippet (except other variables) is emitted as plain text in the editor when the snippet is invoked. You can see I am also using a built-in literal $end$, which specifies where the input cursor is placed when you hit Enter to leave the placeholder mode of snippets.

Creating Your Own Snippets

By now you are probably emitting some form of "Eeewwww!!!" sound at the thought of editing the XML whenever you want to create your own snippets. The good news is that you don’t have to. There are a couple of free tools out there to help you create and edit snippets without ever needing to touch the XML directly. One I have been using for years as a C# guy is Snippy (http://www.codeplex.com/snippy). It puts a very simple dialog interface on top of the XML schema for you to create your snippets (see Figure 1).

Figure 1: Snippy

A great way to start many custom snippets is to start with an existing one and just edit it. Just remember to do a "Save As…" and save it to your Documents code snippets folder mentioned earlier so you don’t overwrite the built-in ones.

Another choice is the Code Snippet Editor for Visual Basic 2008 (http://msdn.microsoft.com/en-us/vbasic/bb973770.aspx). For those language bigots, you will have to get over the title: it actually supports multiple languages (see Figure 2).

Figure 2: Code Snippet Editor for Visual Basic 2008

Either one of these will allow you to quickly create your own snippets and stop typing the same code over and over again.

Code Snippet Functions

I showed you the switch snippet earlier in the article, and that may lead you down the path of thinking you can pull off anything with a snippet. Unfortunately that is one of the most powerful ones you will find. There is a whopping three functions in the C# library for expanded capabilities in your snippets (http://msdn.microsoft.com/en-us/library/ms242312.aspx). The GenerateSwitchCases function is the one that did the magic for the switch code snippet. The ClassName function will emit the class name of the class in which the snippet is invoked. This is used by the ctor snippet I mentioned earlier to declare a default constructor. And lastly there is the SimpleTypeName function, which will take a fully qualified type name, and will emit both a using statement in C# (Imports in VB) and the root class name so that you don’t have fully qualified types in the emitted code. This is used by the built-in snippet cw, which emits a Console.WriteLine statement. Take a look at that built-in snippet if you want to see the way it is used. Unfortunately there is no way to add your own custom functions. If you want more power to do more custom things in your snippets, you might want to take a look at third party tools such as Developer Express CodeRush (http://www.devexpress.com/CodeRush) or JetBrains ReSharper (http://www.jetbrains.com/resharper/). They have things called templates that are like code snippets on steroids and are also extensible.

Wrap Up

Now you should have a good idea what code snippets are, how they work, and how to go beyond what you get out of the box. Let me share with you my approach to code snippets: If I find myself typing some code and I get that "déjà vu" feeling of "I know I’ve written this little chunk of code before", I stop myself, write it as a code snippet, and then I won’t ever have to write it again. Too often developers take the longer path because they think they will be "wasting time" by going and doing something like authoring a code snippet for the code they are writing. Many times, it is not authoring the code snippet that is the real waste of time.

—-

Brian Noyes is chief architect of IDesign (www.idesign.net), a Microsoft Regional Director and MVP, writer and speaker. He is the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding with Windows Forms 2.0. He is also a frequent speaker at conferences worldwide including Microsoft TechEd, DevConnections, VSLive!, DevTeach and others. You can contact him through his blog at http://briannoyes.net.

Sending email from a .NET application is incredibly simple:

With just these few lines of code, you are sending an email from from@test.com to derek@devshaped.com. Pretty easy stuff.

But what if you need something a little more complicated? The example above assumes the standard SMTP port for email with no authentication and an unencrypted connection. Fortunately these “complications” are quite easy to deal with in .NET.

Different Port

If you need to send email on a different port, simply add the following line:

SMTP Authentication

If you are not sending through a local SMTP server, your app will likely need to authenticate itself. If you need to pass credentials to the SMTP server, use the Credentials property on the SmtpClient class:

Encrypted Connection

Since you are passing credentials to the server, you really should be using a secure connection (many mail providers require you to use a secure connection). In code, it’s just one line:

Sending Email On Behalf of Someone

A final practical consideration when sending email is the distinction between From and Sender. In a simple scenario, you only need a From address. But if you are writing code to send email, chances are good that there is something not-quite-so-simple happening.

Perhaps you have received an email with a header like this in Outlook:

This is an example of one email account sending an email on behalf of someone else. This is often used by automated systems and it is trivial to add to your application. To add a Sender you cannot pass values directly to an SmtpClient object; you must create a new instance of the MailMessage class, set the properties, and then pass the MailMessage object to the SmtpClient object:

Keep in mind that your message is going through an SMTP server that might not let you set arbitrary From and Sender values.

Bringing it All Together

Here is what the final code looks like that incorporates an alternate port, credentials, encrypted transport, and a sender:

—-

Derek Hatchard is the content editor for http://microsoft.com/youshapeit/msdn and http://devshaped.com. He is also the founder of Crowd Space. You can find him online at http://derekh.com, http://ardentdev.com, and http://twitter.com/derekhat.

During our careers as developers we sit in training courses, conference sessions and vendor demos in which we hear about how easy and great technology XYZ is for creating applications. And almost every one of them assumes that we’re working on new development. I’m not sure about you, but I find that new (or greenfield) application development has been fairly rare in my career.

More often than not, we developers are working in companies that already have a suite of custom software. If you’re brought in to work on a specific project, it’s rare that the project hasn’t had something already started on it. As a result, most developers spend a large part of their careers working with or on someone else’s code. I don’t think this is a bad thing. Instead I think that it is something that we should embrace with good practices, strong tooling and a strong desire to succeed.

If these projects aren’t classified as greenfield, how should we refer to them? One of the most common terms in application development is ‘legacy’. In his highly regarded book "Working Effectively with Legacy Code", Michael Feathers defines legacy code as:

"…code from the past maintained because it works"

I completely agree with this definition, but it does leave us with a gap. Partially completed applications fall squarely in between legacy (maintained and working) and greenfield (not inhibited by past technical decisions or debt). They have incurred some amount of technical debt and are probably constrained by some design or architectural decisions. They also are only partially completed so we’re not working with the code base solely to maintain an already functioning application. Heck, none of the application may function at all yet. It’s these applications that we developers often find ourselves working on.

What is Brownfield?

Brownfield is an increasingly common term being used to define application code bases that are neither greenfield nor legacy. My definition of brownfield is:

" a project, or codebase, that was previously created and may be contaminated by poor practices, structure, and design but has the potential to be revived through comprehensive and directed refactoring".

Brownfield applications exist all over the world, at all companies and in most project teams. Unfortunately they’re the norm, not the exception in our industry. The developer across the world, sitting next to you, and even you and I are all creating brownfield applications on a daily basis.

The fact is that as soon as we write a line of code, we have accepted that we are going to maintain it in that form. No matter how well you write code, you are, at the point of finishing that line of code, incurring some level of technical debt and some level of technical constraint going forward. Every single line of code you write is adding to or otherwise modifying the level at which those debts exist.

These statements shouldn’t scare you. With today’s tools (Visual Studio, Resharper, CodeRush and others) modifying code after it has been created is easier than ever. Refactoring code to lessen the debt or constraints that it places on the project and team is something that is actively encouraged in development circles. There are some things that are important to ensuring that you can do this efficiently and effectively.

Confidence

The largest factor that you need to take into account when working with brownfield code is the confidence level that you, your testers and your client will have with the act of modifying code, without breaking functionality. Nothing scares testers and clients more than the prospect of failing regression tests and bugs introduced to already functional code. It’s not just frustrating for them; it’s also very demoralizing for a development team. As soon as defects are being introduced from what should be innocuous code refactorings, the development team starts to lose confidence in their abilities to manage the code, their abilities to work with the code in its current state, and the their ability to deliver a product to the client. Those things are a well baked recipe for disaster.

I have seen this on projects which I’ve joined part way through their completion. In one case I was working with a team where the developers and the business analysts would physically break into cold sweats when there was mention of having to alter one component within the application. They did anything that they could to avoid having to fix bugs or rework that code. That was a team that had completely lost its confidence.

There are some tools that you can use to build or maintain a team’s confidence. One of them is automated testing. Even if your team is currently confident about its ability to refactor code, creating a suite of unit and/or integration tests will prove to them that their confidence isn’t misplaced. When a team is lacking confidence, adding tests prior to making changes and ensuring that they’re still passing after the changes have been effected will work to rebuild that confidence.

I know that some of you will now be saying that you don’t have the time, resources or budget to build a comprehensive test suite for your brownfield application. You’re probably right. Creating tests after the code has been completed is a laborious task, more so if your project has a significant amount of code. Instead of worrying about comprehensive application-wide test suites, let’s think about them in a more localized and granular fashion.

If you’re looking to rework a small portion of an application to increase its maintainability, work first at creating a good test suite for that small portion of the application. This approach of creating confidence-building tests only for the portions of the application that are going to be changed will allow you to minimize the effort required for creating tests while maximizing the confidence the team has in changes it makes. This approach will possibly never see your application have a comprehensive test suite, but any changes that you have made will be covered by tests.

The advice for creating tests prior to refactoring code also stands true when the team is faced with modifying code to fix defects or to add new functionality. In the case of fixing defects, first creating a test that exposes the bug (and fails as a result of that bug) allows you to have full confidence that you’ve fixed it. Likewise creating tests that confirm new functionality prior to creating the code to implement those capabilities within the application will give you a strong understanding of when you’ve completed the required task.

All Shall Build

Confidence in implementing, fixing and refactoring code is only one part of the brownfield project experience. Confidence on projects comes in many forms. For instance, do you have full confidence that anyone on your project team could correctly compile and deploy your application to any of your testing, staging or production environments? My experience is that there is usually one person on the team who can perform this task and it usually involves a combination of black magic, voodoo and chicken sacrifices.

Why not work towards a scenario where any one of the developers on the team can, and does, regularly create a release package? Traditional methods of compiling applications in the .NET sphere have been limited to "Rebuild All" within the Visual Studio IDE. While there can be some automation included through the use of pre- and post-build events, "Rebuild All" is a largely manual process when you include tasks such as test execution and release package construction. While this can work, it doesn’t necessarily offer the consistency, or flexibility, of using a build script. There are many build scripting tools and languages available to .NET developers. Each offers the same fundamental features, but each also offers a twist.

If you create a compilation, testing and release script that is available to every developer on the team, it becomes one of your projects mechanisms for creating confidence in release management. If the script is available to all developers at all times, they should be encouraged, through simple tooling and fast execution, to run it as many times per day as possible. Every time that you run a script like this you are testing a technically complex portion of your release management process. If that process is being executed tens of times per day, the confidence level of the team and its management and clients should soar.

Social Considerations

We could continue this article with a long and detailed discussion on the merits of using fundamental OO code practices to ensure that your code is flexible, decoupled and robust. Instead I’d like to finish with a brief discussion on the social aspect of working with brownfield applications.

Joining an already started project can present interesting issues both in personal and team dynamics. We all join a new project or job thinking that we can bring greatness to the team or job. As a result we often head into these new engagements bringing suggestions about changes to techniques, tools or practices that we’ve had success with in the past. Unfortunately this usually happens without us taking the time to properly and completely assess the current situation. This lack of understanding around past decisions and current situations, combined with the vocal desire to try to improve things, often leads new team members to be seen in a negative light.

When joining a team we also have to be aware that the currently serving team members probably have an emotional attachment to the current code base. While many developers believe that they are able to openly take constructive criticism of their past or present endeavours, often they can’t. When suggesting changes to a code base, new team members need to be cognizant of the potential negative impact that they may be inflicting on the team’s morale. While this is a delicate situation to have to step around while working to improve code, it is one that is vitally important if the team, as a whole, is going to improve productivity, maintainability and quality going forward. Getting team members to believe in the reasons behind the changes that you’re proposing instead of the changes themselves can be an effective technique.

Many projects that we developers encounter should be categorized as brownfield. While each of these projects encounters its own set of unique issues, there are some underlying problems that are seen on many. Projects might suffer from a lack of confidence in code, releases and quality. They can also have severe maintainability issues caused by poor coding practices. Those technical issues can be some of the easiest to solve, but each technical problem can expose a series of potentially debilitating social and team cohesion issues.

Don’t let any of these issues scare you though. You’re probably already working on a brownfield project and having to deal with many of them. Remember that much of what we do in this industry is deal in areas of confidence between developers and management, developers and clients, and developers amongst themselves.

—

Donald Belcham is an independent contractor in Edmonton, Alberta, Canada who specializes in software development with the .NET platform.  With more than 7 years experience delivering Web and Smart Client applications to government and Fortune 100 clients in North America and the South Pacific, he has experience and knowledge in the entire software development life cycle.  Combining that experience with his passion for agile development practices and solid OO fundamentals, Donald works to provide the client with software that works for their business.

Recognized by Microsoft for his technical skill and community contribution with the Microsoft MVP award in C#, Donald is a notable leader in the developer community.  In addition to being a founding member, and current President, of the Edmonton .NET User Group, Donald regularly speaks for .NET User Groups and Code Camps across North America on topics ranging from development practices to the intricacies of different technologies.

His thoughts on software development can be found on his blog at www.igloocoder.com.