Posts Tagged ‘ Best Practices ’

ClickOnce Master Build

Previously I have posted about how to publish a ClickOnce release for multiple environments. Whilst this works well there are two reasons (that I can think of) why it is not appropriate or good enough.

First, you or your manager may be a bit of a purist in terms of releasing to Production ‘exactly’ what has been tested, specifically the exact same compiled assemblies.

Second, you may need to create a release for several different customers who each have several of their own ‘environments’ but you do not want to provide them with your source code.

Third…both of the above. 🙂

When you ‘Publish’ with MsBuild it requires the source code and it recompiles your assemblies. So how can we easily create releases for multiple environments but only Publish once? This posting offers one solution which has worked for me in the past, it’s not a complete ‘how to’ guide I just wanted to cover the idea and problems I ran into along the way.

Master Build Environment

Make sure you take a look at my previous posting as this process builds on those ideas.

One of the final steps of this process is to re-sign the setup.exe, however in order for that final step to work you have to change one of your ClickOnce deployment settings in your .csproj file.

<SignManifests>false</SignManifests>

SignManifests must be false! Otherwise the signtool gets confused when re-signing the setup.exe. Check this out for a bit more info on this known issue.

So the first thing to do is create a BuildEnvironment called Master. The configuration details of this (web service addresses or database connnection strings etc) should point to nowhere, i.e. if someone deployed this build then it should not work. Publishing this is easy just follow the steps defined in the multiple environment posting, the process of creating a release with environment specific information that is tricky.

MsBuild Changes for Master Build Publish

When you publish with ClickOnce it creates a folder ‘Application Files’ where it puts the contents of the release. The space in that file name causes a problem with MAGE when re-signing the app. Now the only way I could see to change this was to cut and paste the _CopyFilesToPublishFolder target from Microsoft.Common.Targets and modifying the _DeploymentApplicationFolderName property in my version to remove the space. I think it is a really BAD idea to change the Microsoft.Common.Targets directly so that option was ruled out immediately and as you can see in the code below, Application Files (version below already has the space removed) is a hardcoded value, not a settable property…therefore even though it is ugly, cut and paste seems the only viable solution.

      <!--
	  This Target code has been cut and paste from Microsoft.Common.Targets.
	  Only ONE thing has been changed.
	  Application Files changed to ApplicationFiles (i.e. the space removed)
	  The only other way of changing that value is to modify Microsoft.Common.Targets
	  which is a really bad idea (would have to ensure this was changed on ALL machines.)

	  The space causes a problem when re-signing the app with MAGE
    ============================================================
                                        _CopyFilesToPublishFolder
    ============================================================
    -->
    <Target
        Name="_CopyFilesToPublishFolder">

        <!-- Compute name of application folder, which includes the assembly name plus formatted application version.
             The application version is formatted to use "_" in place of "." chars (i.e. "1_0_0_0" instead of "1.0.0.0").
             This is done because some servers misinterpret "." as a file extension. -->
        <FormatVersion Version="$(ApplicationVersion)" Revision="$(ApplicationRevision)" FormatType="Path">
            <Output TaskParameter="OutputVersion" PropertyName="_DeploymentApplicationVersionFragment"/>
        </FormatVersion>

        <PropertyGroup>
            <_DeploymentApplicationFolderName>ApplicationFiles\$(AssemblyName)_$(_DeploymentApplicationVersionFragment)</_DeploymentApplicationFolderName>
            <_DeploymentApplicationDir>$(PublishDir)$(_DeploymentApplicationFolderName)\</_DeploymentApplicationDir>
        </PropertyGroup>

        <!-- Copy files to publish folder -->
        <Copy
            SourceFiles=
                "@(_ApplicationManifestFinal);
                @(_DeploymentResolvedManifestEntryPoint);
                @(_DeploymentManifestFiles);
                @(ReferenceComWrappersToCopyLocal);
                @(ResolvedIsolatedComModules);
                @(_DeploymentLooseManifestFile)"
            DestinationFiles=
                "@(_ApplicationManifestFinal->'$(_DeploymentApplicationDir)%(TargetPath)');
                @(_DeploymentManifestEntryPoint->'$(_DeploymentApplicationDir)%(TargetPath)$(_DeploymentFileMappingExtension)');
                @(_DeploymentManifestFiles->'$(_DeploymentApplicationDir)%(TargetPath)$(_DeploymentFileMappingExtension)');
                @(ReferenceComWrappersToCopyLocal->'$(_DeploymentApplicationDir)%(FileName)%(Extension)$(_DeploymentFileMappingExtension)');
                @(ResolvedIsolatedComModules->'$(_DeploymentApplicationDir)%(FileName)%(Extension)$(_DeploymentFileMappingExtension)');
                @(_DeploymentLooseManifestFile->'$(_DeploymentApplicationDir)%(FileName)%(Extension)$(_DeploymentFileMappingExtension)')"
            SkipUnchangedFiles="true"
            OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"/>
        <Copy
            SourceFiles="@(_DeploymentManifestDependencies)"
            DestinationFiles="@(_DeploymentManifestDependencies->'$(_DeploymentApplicationDir)%(TargetPath)$(_DeploymentFileMappingExtension)')"
            SkipUnchangedFiles="true"
            OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
            Condition="'%(_DeploymentManifestDependencies.DependencyType)'=='Install'"/>
        <Copy
            SourceFiles="@(_ReferenceScatterPaths)"
            DestinationFiles="@(_ReferenceScatterPaths->'$(_DeploymentApplicationDir)%(Filename)%(Extension)$(_DeploymentFileMappingExtension)')"
            SkipUnchangedFiles="true"
            OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"/>
        <FormatUrl InputUrl="$(_DeploymentApplicationUrl)">
            <Output TaskParameter="OutputUrl" PropertyName="_DeploymentFormattedApplicationUrl"/>
        </FormatUrl>
        <FormatUrl InputUrl="$(_DeploymentComponentsUrl)">
            <Output TaskParameter="OutputUrl" PropertyName="_DeploymentFormattedComponentsUrl"/>
        </FormatUrl>
    </Target>

Note that the space only causes a problem with MAGE.exe, it does not cause a problem with MAGEUI.exe! MAGEUI.exe happily re-signs the release even with the space in the directory name. We cannot use MAGEUI.exe however because this process needs to be automated, if you use MAGEUI.exe someone has to run it and manually set the values…not good enough.

It took a while to figure out that the space in the dir name was causing a problem so I hope this saves someone else some time…

Creating a Release

Ok so now we have a published build that no one can use, the first place we want to release to will be QA, then from there UAT so what we need now is an automated way of creating a release configured for these environments.

Creating a release should be as easy as publishing a build, it should be a one step process.

Create a batch file ‘createRelease.bat’ which performs all of the necessary steps. Those steps are:

  1. Create or clean the ‘working’ directory.
  2. Copy the master build into the working directory.
  3. Run the MsBuild steps.
  4. Create a zip file of the new release. (not necessary just makes it a little easier to move the releases around)

Run the MsBuild Steps

Add a new target in your customized.targets file, ModifyMasterBuildForEnvironment.

<Target Name="ModifyMasterBuildForEnvironment" DependsOnTargets="SetPropertyValues; ConfigureForEnvironment; RecreateManifests" />

SetPropertyValues

There are a few properties which need to be set for the resigning process.

	<Target Name="SetPropertyValues" >
		<Message Text="FullReleasePath $(FullReleasePath)" />

		<MSBuild.ExtensionPack.Framework.TextString TaskAction="Replace" OldString="$(ApplicationVersion)" OldValue="." NewValue="_">
			<Output PropertyName="buildX" TaskParameter="NewString"/>
		</MSBuild.ExtensionPack.Framework.TextString>

		<PropertyGroup>
			<WorkingDirectory>WorkingDirectory</WorkingDirectory>
			<FullReleasePath>$(WorkingDirectory)\ApplicationFiles\$(AssemblyName)_$(buildX)</FullReleasePath>
			<ApplicationManifestName>$(AssemblyName).exe.manifest</ApplicationManifestName>
			<ApplicationManifestPath>$(FullReleasePath)\$(ApplicationManifestName)</ApplicationManifestPath>
			<DeploymentManifestPath>$(WorkingDirectory)\$(DeploymentManifestName)</DeploymentManifestPath>
			<CertFileName>cert\pmsKey.pfx</CertFileName>
			<ProviderFullUrl>$(ProviderBaseUrl)$(DeploymentManifestName)</ProviderFullUrl>
		</PropertyGroup>
	</Target>

ConfigureForEnvironment

Add your own target(s) here that does the work to configure the release for a given environment. e.g. update the config file setting database connection strings or web service urls.

RecreateManifests

Now that you have modified the published release it is no longer a valid ClickOnce release. Try to install it and it will fail. What you need to do is update and re-sign the manifests (the Application Manifest and the Deployment Manifest). You also need to update and resign the Setup.exe!

	<Target Name="RecreateManifests">

		<!-- Application manifest update and resign -->
		<Message Text="Removing .deploy suffix..." />
		<RenameFiles DirectoryPath="$(MSBuildProjectDirectory)\$(FullReleasePath)" RemoveSuffix=".deploy" IncludeSubDirectories="True" />
		<Message Text="Updating application manifest" />
		<Exec Command="mage -Update $(ApplicationManifestPath) -FromDirectory $(FullReleasePath) -ToFile $(ApplicationManifestPath)" />
		<Message Text="Adding .deploy suffix..." />
		<RenameFiles DirectoryPath="$(MSBuildProjectDirectory)\$(FullReleasePath)" AppendSuffix=".deploy" IncludeSubDirectories="True" ExcludedFiles="$(ApplicationManifestName)" />
		<Message Text="ApplicationManifestPath $(ApplicationManifestPath)" />
		<Exec Command="mage -Sign $(ApplicationManifestPath) -CertFile $(CertFileName)" />

		<!-- Deployment manifest update and resign -->
		<Message Text="Updating Deployment manifest (ProviderFullUrl=$(ProviderFullUrl))" />
		<Exec Command="mage -Update $(DeploymentManifestPath) -AppManifest $(ApplicationManifestPath) -ProviderUrl $(ProviderFullUrl)" />
		<Message Text="DeploymentManifestPath $(DeploymentManifestPath)" />
		<Exec Command="mage -Sign $(DeploymentManifestPath) -CertFile $(CertFileName) " />

		<!-- Setup.exe update and resign -->
		<Message Text="Updating $(WorkingDirectory)\Setup.exe..." />
		<Exec Command="$(WorkingDirectory)\Setup.exe /url=$(ProviderBaseUrl)" />
		<Message Text="Signing $(WorkingDirectory)\Setup.exe..." />
		<Exec Command="signtool sign /v /f $(CertFileName) $(WorkingDirectory)\Setup.exe" />

	</Target>

Note that before Updating the Application Manifest we have to remove the .deploy extension from the file names, then add the .deploy extension back onto the file names before Signing. (if you have configured ClickOnce to NOT append .deploy then obviously just remove these steps).

RenameFiles Task

To get the renaming behaviour I wanted I had to create my own MsBuild task. You will need to do the same, it’s a little crude as I had limited time but this is the simple little task I created….

    public class RenameFiles : Task
    {
        public override bool Execute()
        {
            var directory = new DirectoryInfo(DirectoryPath);
            if(directory == null)
                throw new ApplicationException(string.Format("Directory path is invalid: {0}", DirectoryPath));
            Console.WriteLine(string.Format("DirectoryPath:{0}", DirectoryPath));

            ProcessDirectory(directory);

            return true;
        }

        private void ProcessDirectory(DirectoryInfo directory)
        {
            RenameAllFiles(directory);
            if(! IncludeSubDirectories)
                return;

            var subs = directory.GetDirectories();
            foreach (DirectoryInfo sub in subs)
                ProcessDirectory(sub);
        }

        private void RenameAllFiles(DirectoryInfo directory)
        {
            var files = directory.GetFiles();

            if(files.Length == 0)
                return;

            foreach (FileInfo file in files)
            {
                string fileName = file.Name;
                if (ExcludedFileList.Exists(name => name.Equals(fileName, StringComparison.InvariantCultureIgnoreCase)))
                {
                    Console.WriteLine(string.Format("{0} is excluded from renaming.", file.Name));
                    continue;
                }
                Console.WriteLine(string.Format("Renaming {0}", file.Name));
                RemoveExtensions(file);
                AppendExtensions(file);
            }
        }

        private void RemoveExtensions(FileInfo file)
        {
            if (string.IsNullOrEmpty(RemoveSuffix))
                return;
            file.MoveTo(file.FullName.Replace(RemoveSuffix, string.Empty));
        }

        private void AppendExtensions(FileInfo file)
        {
            if (string.IsNullOrEmpty(AppendSuffix))
                return;
            file.MoveTo(string.Format("{0}{1}", file.FullName, AppendSuffix));
        }

        public string DirectoryPath { get; set; }
        public string RemoveSuffix { get; set; }
        public string AppendSuffix { get; set; }
        public string ExcludedFiles { get; set; }
        public bool IncludeSubDirectories { get; set; }

        private List<string> ExcludedFileList
        {
            get
            {
                if (excludedFileList == null)
                    excludedFileList = CommonFunctions.CreateListFromCommaSeparatedString(ExcludedFiles);
                return excludedFileList;
            }
        }
        private List<string> excludedFileList;
    }

Summary

There are a number of other little steps we do to make this release process work here but these are really specific to how we want it to work. What I have outlined above is the core steps involved including some problems you will face and their solutions. I hope this posting helps you get over the most challenging of the hurdles you will face in setting a smooth ‘Master Build’ release process but there is still alot of extra steps you will need to create yourself to get it working end to end.

One thing I would recommend is, once you have a working createRelease.bat (note it doesn’t have to be a batch file, could be an exe or powershell or whatever works best in your situation) then create a createReleaseALL.bat file. In there make n calls to createRelease.bat…one for each environment you need to create releases for. That way if you have a dozen environments you can still create a release for all of them with a one step process 🙂

I have had to do this fairly quickly so if something is not clear please let me know and I will see if I can improve the post over time.

Final note – It does take time to set this up and get it working correctly, but it is so worth it! Over time you will save much more time than you spent setting it up, guaranteed!

Additional Resources

A few links which helped me to piece this puzzle together…

ClickOnce with bootstraper setup.exe need to change URL without any build

packaging-a-clickonce-server-deployment

Advertisements

Software Project Failure

A How-To Guide

This is a posting for all software development or project managers who cannot stand their job, detest their company, hate their life or any combination of all three and who are actively seeking revenge against all who have made their life so miserable.

One simple means of getting the revenge you crave, of exacting pain and torment on those around you is to guide your development project to failure and I’m here to tell you some simple little things you can do to your developers that will almost guarantee your failure…

Cast Them Into a Dark Dingy Dungeon

The first thing you need to do to your developers is the worst thing you can do to your developers.

Restrict internet access.

Simply claim to your manager that your team wastes too much time on the internet so a restricted policy is required. Tell them to lock down access to all sites except those authorized by you personally.

Then don’t authorize any except Google…that way your team may still search for answers to their technical question but never get to the actual answers (evil laugh). Of course, tell them you are talking to your management to have this restriction removed.

If that is not possible, simply ensure that your team has the exact same restrictions as the rest of the company, that is usually enough to cause major frustration, especially if they cannot download anything (they like to download all sorts of helpful things).

Gouge Their Eyes Out With a Stick

Whenever a team member asks for an additional monitor or even just a larger monitor, be ready with your new favourite saying (you will be using this alot);

“sorry, there’s nothing in the budget for things like that”.

Larger monitors and especially dual (or triple) monitors often lead to increased productivity and worse, makes the developers job more enjoyable so you must be very vigilant in keeping them restricted to one monitor…preferably  a 14 inch number.

If anyone ever asks you:

“may I bring in my own monitor from home then?”

immediately ask them to pack their things and be on their way. This kind of ‘go the extra mile’ behaviour can be infectious and may allow a thread of work enjoyment to seep into the team which, naturally, is intolerable.

Strap a Giant Ship Anchor to Their Waist

Developers think they are special. They are not. As such they should have the same machines as everyone else in the company. If they say they need a more powerful machine, tell them if they were a half way decent developer they should be able to work with any old machine, even a 386 just like you used to do back in the day…

Ensure any servers you have are maxed to capacity, especially the database server, there are few enjoyments in life that beat watching a developer lose more hair because the database server has run out of disk space…again. Crying, “I have more disk space on my mobile phone than this stupid server…which century are we living in here!”, they will beg for a new machine or at the very least a bigger hard drive. Enjoy the show and once they’ve cleared some space and got things working again, copy a massive file onto the server and watch the spectacle again.

Oh yeah!

Oh and of course if they happen to have a build machine, make sure it is the slowest machine you can find. A slow build is a frustrating build and a frustrating build is easier to get rid of (you want to stop any continuous integration which may be going as this kind of setup takes away ALOT of developer pain).

The beautiful thing about this is you will be seen as a genius by upper management because of the vast amounts of $$$ you appear to be saving them! Secretly laugh at them behind their backs because the reality is very different, though they are saving money on better machines, developers are taking 2-3 times as long to complete their tasks…and developers are expensive…much much more expensive than ‘decent’ machines.

Start planning an amazing holiday, your bonus should be huge this year!

Divide and Conquer

If your team gets together on Monday mornings for a coffee and a chat about the week ahead, it may seem like a good time waster to you but don’t be deceived! Such meetings are great for morale and team building, making your team happier and therefore more productive.

They must be stopped at all costs.

Watch your bonus grow as you put a stop to these ‘meetings’, putting an extra twenty minutes of work back into each developers Monday. Senior management will be talking about your genius.

Bore Them to Tears

Documentation, Documentation, Documentation!

Reams of it!

Any new feature request demands at least a few pages to fully describe the change…and that is just to fix some spelling.

As for the developers. Insist on a tech spec for every piece of work. Then insist that spec must be approved by the team lead…before it goes to the architect for approval…which then must finally be approved by you. Make a point of rejecting at least half.

Ensure the documentation gets done in something like MS Word. The business (and senior management) will be happy with your choice and developers will grumble.

They do complain alot, developers.

They will grumble and tell you that a Wiki would be a better place to document things because it’s easier to search, keep updated, manage change history and ensure that the latest version is easily available to everyone. Indeed they are right but that would involve change and who wants change? Change means risk and you have a bonus you are working towards.

Drive Them Insane

Say things like, ‘ok, to improve productivity we are going to be doing daily SCRUMs’ (developers love SCRUM’s, well good ones do anyway).

But then in each meeting YOU do all the talking, dish out tasks, berate people for taking too long, tell them how poorly the team is perceived by the rest of the company then finish the meeting with a (contrasting) positive and resounding, “OK team, Let’s go GUYS”.

This is so completely not how SCRUM works. Your good developers will point this out…make sure you keep calling the meetings a SCRUM and they will slowly (but very surely) go insane. Eventually they won’t be able to stand it any more and will leave.

Tell senior management the deserters couldn’t handle the new tighter controls you have placed on the project and replace any good developer that leaves with one that is half the salary.

Get an extra bank account, one is not going to be big enough to fit your bonus!

Give Them Enough Rope

WARNING this is pure evil…so read very carefully.

Allow on the fly changes to production servers.

Grant full access to production databases, i.e. so developers can run any kind of script at any time.

Like a spider in a web, you just sit and wait…disaster will happen.

Throw Them to the Lions

If senior management approach you about problems they have been hearing about the system, always direct all blame to the best developer on your team (if he/she was so good the problem should have never arisen).

Deny all suggestions that your team has been doing many extra hours (with no overtime paid) to stay on top of things, suggest that even if that were true, once again, if they were half way decent developers extra hours would not be needed.

You are doing the best you can with the limited abilities which exist in your team.

If you start to feel uncomfortable with how you are treating your staff (what the!), just remember…your bonus.

The Perfect Team

Do all of these things and over time you will find that strangely not all of the developers leave! Some stay on enduring the pain, walking the tightrope over the raging river of suffering. No matter what you do they keep coming back for more and the great thing is this, they do not leave because they are rubbish, they have as much talent at software development as you do at managing projects, are entirely in it for the pay packet and are slowly but surely turning your codebase into a festering cesspool of ick.

So keep up all the good work you have been doing and your team will soon be full of these blundering fools and you will have complete success at total failure!

Authors Comment

I just wanted to be clear here, this is not a rant about a place I have worked and most certainly not about any individual manager. Just a bit of fun exaggerating some of the frustrations we have all experienced as developers.

you need to immediately put a stop to

SVCUTIL and ServiceContracts

Shared ServiceContract Library

I had what I thought was a simple plan, create a server side (WCF) sln and a client side sln then from both of them reference the same BusinessObject (Biz) library and ServiceContract library.

What I wanted to do was use svcutil.exe to generate the client side implementation of the contract for me, so when any of the service contracts changed all I had to do was run a batch file which basically ran svcutil.

The Problem

So when you do a ‘right click, add service reference’, tick the box to re-use the Biz and ServiceContract libraries, what happens is the Biz objects are not generated (good, that was expected) but the contracts ARE still generated (am I missing a simple check box somewhere??).

I don’t want the contracts to be generated as it means I now have two versions of the same contract.

If you use svcutil.exe to generated the metadata and then the proxy code, by providing a few of the right switches you get the same result as ‘add service reference’. Ok good, now that I’m using the cmd line utility I will now have the power to tailor the generated code to my exact measures….not quite. Unless I’m missing somethings obvious (which is likely I’ll admit) there is not any switch to tell svcutil to NOT generate the ServiceContracts. Yes I am using the /r: switch to provide the assembly that contains the contracts…

So I’m thinking, unless you are willing to accept and allow there to be two versions of your service contract (which actually is very common, anyone using VS right click, ‘add service reference’ will have this setup…thus the need to regularly update service reference) then really it is not possible to use svcutil.exe.

The Solution

Well I hope to come back and update this in the near future with the approach we end up choosing. For now though, this post looks like a good ‘leg up’ and is certainly worth a read. I’ll be exploring that idea and a few others and report back….

Why Bother?

Why go through the hassle, why not just use the old, ‘right click add service reference’? Well, every WCF ‘expert’ I know of says that approach is the beginners way of creating your WCF service proxies, either in their blogs or .net rocks episodes etc. It is certainly very quick but the generated code is overly verbose and as it is generated code you have less control over the way it works.

Share your interfaces
Extreme WCF

WCF the manual way…The RIGHT way
WCF Standards from iDesign

Determine if Internet Connection Available

Smart Client

Be careful with your logic when using

NetworkInterface.GetIsNetworkAvailable()

This tells you if any network is available…which doesn’t necessarily mean that you can connect to the internet!

For example if in my app if I unplug my network cable the method returns false…until I plug in my mobile device and suddenly (and accurately) it returns true. Plugging my mobile in does not mean I have internet access BUT IT MIGHT. 

The best way to check for an internet ready connection is to make some call out to the internet and see what happens, there’s a few suggestions for which approach, I like this one:-

Getting Started With Continuous Integration

In Less than Ten Minutes!

This article is all about how you can easily get up and running with CI in less than 10 minutes!

There are really two separate parts to gettings started with CI (and therefore two parts to this article).

  1. Setting up the build server and
  2. Creating the build (e.g. Nant files)

Then there are the issues you will face and need to find some form of resolution for.

First you need to download and install these tools:-

  1. Cruise Control
  2. CCTray (same location as CruiseControl)
  3. NAnt
  4. NAntGenie

And Add the path to these exe files in your Environmental Variables

  1. NAnt
  2. msbuild (something like ‘C:\Windows\Microsoft.NET\Framework\v3.5’)
add path to NAnt and msbuild

add path to NAnt and msbuild

Presumed Knowledge

These are demo notes from a ‘lightning talk’ I gave at the Sydney Alt.Net user group in February.

In the talk I had only 10 minutes, so I made the presumption that all in attendance knew what CI was, if you don’t then check out these links, they will get you started:-

Martin Fowler

Extreme Programming Rules

The Build Server

I’ve always used Cruise Control as it has always met my needs, is free, simple to get up and runnning and pretty much trouble free. For the demo I used version 1.4.2, when you download it, make sure you also get CCTray.

There are a number of other build servers out there that are definately worth looking at and comparing, I’m especially keen to try out Jetbrain TeamCity…when I find some time. It doesn’t matter which one you choose.

Setup CCTray

  1. Install Cruise Control (keep all of the default settings)
  2. Install CCTray (start it)
  3. Ok so now open CCTray settings and add (try to) a new build server.

ci_cctraysetupbuildserver2

Connect directly using .Net Remoting is the default, change it to Via the CruiseControl.NET dashboard (just a recommendation).

Click OK and you should see at the bottom a message saying, ‘Failed to connnect to server….’. We going to fix that right now.

Configure The Server

First thing we need to do is configure the service.

  1. Go here [C:\Program Files\CruiseControl.NET\server] or wherever you chose to install it.
  2. Open ccnet.config
  3. This is where things get personal. The example below is a basic configuration to point to an SVN Repository. The documentation on the Cruise Control website is concise and easy to follow so if your needs are different you’ll have no problems figuring out what you need to do.
  4. Add a ‘Project’ with the follow config sections:
    1. Trigger
    2. Source Control
    3. Labeller
    4. Build Task
    5. Publishers
  5. Save and double click on ccnet.exe
  6. You now have a working automated build! (well sort of…we still need to do the second part of the process, THE BUILD!)


TIP: Don’t forget to change the verbosity of the output to INFO (it’s currently DEBUG). Don’t worry CC will remind you every time it starts and tell you where the config file is that you need to change.

This is the contents of the config used in the demo, change it to suit your environment and save. Make sure:-

  • The path to NAnt.exe is correct.
  • The trunkURL for your repository is correct (or replace with appropriate section for your repository)
  • Working directory and publish from directories are the same.
  • You may need to make sure the SuccessfulBuilds directory exists before running…

Create the Build Files

The other big piece of the puzzle is the master.build file and the associated myProject.build files.

My tool of choice here is NAnt and I use (wrote) this generator to automatically create my build files and the master.build.

To create these use NantGenie (be sure to read the Notes section)…or you can write them from scratch.

RUN

That’s it you should be good to go. Start ccnet, checkin a change to your source, the build should start and run your new master.build file!

White Lie

Ok so here’s where I have to come clean. It may have been a little white lie when I said that you could get CI up and running in less than 10 minutes. You are going to run into some other issues that is going to make it take….longer.

I discuss some of these issues in this article. But in a nutshell these will be the biggest thorns in your side:-

1. Database changes

Ideally when you check your code in, you are checking in a ‘unit of work’. This could include some app code changes AND some database changes, e.g. a new column and some data. Your tests rely on the database being up to date, so how do you ensure that the database on the build server DOES get updated when you checkin?

I’ve created an automated Db updater and put it on codeplex, it works for me. Check it out and I recommend looking at what other alternatives might work in your unique environment.

2. App.Config changes

So what is the best way to ‘manage’ the app.config files?

I don’t have a definitive answer for this one but I think that the following conditions are ‘desirable’ when planning how to manage your app.config.

  1. Like other code, you don’t want to have duplicates (including cross project).
  2. You only want data in there that is relevant to the project.
  3. Must be under source control.
  4. You want to be able to define what the variable contents should be in one place only. (where doesn’t matter too much as long as it is only one place)
  5. When you make changes to your App.Config, you want to make them whilst you are working on your relevant code change and then forget about it once it has been checked in. By ‘forget about it’ I mean you don’t have to remember to update the file on the UAT box when promoting a new build there and then remember to do the same change to Production…

All of this is tricky with an automated build and multiple environments.

3. People

Probably your biggest hurdle will be convincing people that CI helps and that they need to CHANGE their habits a little (sometimes alot) in order to make it work.

Tips

  • If you’re struggling to figure out why the damn build is broken, the best place to look is here [C:\Program Files\CruiseControl.NET\server\YourProject\Artifacts\log].
  • Also, don’t forget you can also turn the verbosity of the CC server back to DEBUG.

Conclusion

Hopefully this article will help reduce the time it takes to get some CI action happening in your team. Yes it is going to take more than 10 minutes but I guarantee you it is worth the effort and once you start using an automated build you simply refuse to go back to the chaos that preceded it!

WCF Concurrency Mode Tip

Don’t Keep the Default Setting!

When you mark your WCF endpoints with the ServiceBehaviour attribute, are you setting the ConcurrencyMode to Multiple?

The default is Single, meaning only a single thread will invoke the instance method on the reciever object. This may be desirable in certain situations however if you want your service to be scalable then Multiple would be the recommended choice.

Checkout this great article that offers a great explanation of the differences…this is an excerpt from the ‘thoughts’ at the end of the article

ConcurrencyMode should be set to Multiple. In my view, if a receiving application is going to scale, it must set concurrency mode to Multiple. If single or Reentrant are used, messages stack up as they wait to be processed, and that is badness.”

Team Training

Learn From Teaching…

A few months ago we started doing some of our own in team training. Inspired by doing a couple of 10 minute demo’s for the ‘demos happen here’ competition I devised a new (well I’ve never done anything like it before) approach to training the guys in my team (and myself).

Nothing will reinforce your own knowledge about a subject that trying to teach someone else.

So with that in mind, Once per week we get together for 15 minutes only and one person has to deliver a 10 minute (ish) lesson about a specific topic. Instructions are to research on the internet, not just refer to MSDN which offers dry matter of fact details about the subjects, we want lessons from the real world.

A lesson should include (but is not limited to):-

  1. What is it
  2. Why is it cool…or useful
  3. Simple example of use (definately)
  4. Example of misuse (preferably)
  5. Alternatives (other techniques, features etc that could be used instead or in the case of a new language feature what had to be done previously)
  6. Any other ‘interesting’ things you discovered whilst researching the topic
  7. An IDE tip! Can be something native to VS2008 or can be something in resharper…

Topic can also be anything but must be of limited scope given the lesson cannot exceed 10 minutes, some of our topics have included Value vs Reference type, boxing and unboxing, auto properties, lessons specific to implementations in our project. I think it’s good to cover new ground but also what you would expect people to already understand….when you dig deeper into any topic you always find some hidden gems!

The guys enjoy it and come away from each lesson having learnt something. From management perspective it takes guaranteed less than 30 mins a week and their team is constantly improving as a result of it…plus they’ve not had to pay for expensive external training!

One more thing I would suggest, make sure you book in the time in your calenders weeks in advance, otherwise you’ll find that weeks pass when other priorities force the training to be put off till next week…and before you know it it’s Christmas!

Let me know if you try (or have tried) something similar, I’d be interested in hearing your results and opinions 🙂