Philip Beadle

SpecFlow, Watin and DotNetNuke

philip.beadle@dnncorp.com — Thu, 14 Jul 2011 00:56:13 GMT

This is a quick note to let you all know about www.specflow.org and to get you to check out the video by Steve Sanderson. I have been investigating using this approach with DNN and have been able to quite easily implement this because we already have hundreds of tests written in the automation project! All I did was drop the DotNetNuke.Tests.UI.WatiN.Common and DotNetNuke.Tests.UI.WatiN.Utilities projects into the solution and then write the same code that is in existing Automation project tests in the Given, When Then methods. Worked a treat, now its really easy to use this style of development with DNN. More soon….

More ...

My Geek Origins

philip.beadle@dnncorp.com — Fri, 08 Jul 2011 00:09:41 GMT

Kordsy or delic8genius as he is known is a DPE for Microsoft Australia and he’s collecting Geek origin stories for some sinister plan at Tech Ed so I thought the best place to write mine up was on my DotNetNuke blog. So where did all this begin for me.

My earliest recollections about being a geek are back in the ‘80s – yes I’m that old. My dad worked for Channel 2 TV in Australia and ran a side business of fixing TV’s for people so our shed was always full of open TV’s. The ones with valves and real wires and knobs and stuff you could work out what it did if your old man showed you. I was always in the shed soldering things together and helping dad with the various TV’s, radios, VHS players and anything else that plugged in to the wall socket. Then one day dad came home with a Texas Instruments home computer that we hooked up the biggest TV we had, so I had a PC with a monster 46” screen in 1982!!! We had a few games like Defender which was a great arcade game at the time which I could now play at home, very cool. Didn’t take long to figure out we could write our own programs so dad and I wrote some maths programs to teach my sisters maths and then we found out about sprites and graphics and off I went for quite a few years.

Teenage years were upon me so computers went out the door for surfing, girls and other distractions. It wasn't until I finished my Chemical Engineering degree that I got back into programming and while running my own web shop I discovered IBuySpy in 2001. At the time I was trying to work out if I should jump from VB 6 to .Net, glad i did and I’m extra glad I found DotNetNuke as that has been the focus of my career for the last 9 years.

Now I get to work on my pet project full time as an Employee of DNN Corp and I love it. Being a geek rocks!

More ...

Removing Projects and TFS Binding from Solution Files

philip.beadle@dnncorp.com — Wed, 04 May 2011 20:35:55 GMT

At DotNetNuke we distribute many different packages each release including source packages for the Community and our Professional and Enterprise customers. Internally we have an overarching solution file that contains all of the projects that we work on each day, this solution file also contains all of the unit tests. When we distribute the source packages we distribute solution files with and without the unit tests as well as a VS2008 formatted sln file and a bunch of variations for Pro and Enterprise customers, that's actually 15 different solution files. Once the packages are created there is also an automated build that actually compiles each of these packages to ensure we have all the right projects and references set up.

Also since we are distributing these solutions to users who do not have access to our TFS setup the TFS bindings are also removed.

All of these various sln files are created from the one solution file so that all of the internal developers only ever have to deal with one sln file.

Ok that sets the scene. The problem is then how to remove the various projects from the solution file such that it will open in Visual Studio and also be buildable from CCNet. Simply removing the text that defines the project is not sufficient because that leaves the Nested Projects section in a mess. Even though Visual Studio can open the file MSBuild dies a horrible death thus making it impossible to do automated compiles.

The custom task i wrote below process the sln files in such a way that both VS and MSBuild can parse the file and do what they need to do.

To use the task you add the following to your MSBuild file

<GenerateSolutionFiles

OriginalFile="$(PackagingFolder)\DotNetNuke_Enterprise_UnitTests.sln"

CreatedFile="$(PackagingFolder)\DotNetNuke_Community_UnitTests_Source.sln"

ProjectNames="@(AllSolutionsProjects); @(EEProjects); @(PEProjects);

@(EETestProjects); DotNetNuke.Professional.HtmlPro"

Replacements="@(CEReplacements)"

RemoveTfsBindings="true"/>

You specify the lists of projects to remove in ProjectNames and you can also do simple text replacements where you specify the test to replace and the the replacement text lie so:

  <ItemGroup>
    <CEReplacements Include="DotNetNuke_Enterprise" />
    <CEReplacements Include="DotNetNuke_Community" />
  ItemGroup>

We use this to manage the website name.

The code for the Task is below. enjoy.

using System;
using System.Linq;
using Microsoft.Build.Utilities;

namespace DotNetNuke.MSBuild.Tasks
{
    using System.IO;

    public class GenerateSolutionFiles : Task
    {
        public string OriginalFile { get; set; }
        public string CreatedFile { get; set; }
        public string[] ProjectNames { get; set; }
        public string[] Replacements { get; set; }
        public bool RemoveTfsBindings { get; set; }

        public override bool Execute()
        {
            if (ProjectNames == null)
            {
                return true;
            }
            try
            {
                var tr = new StreamReader(OriginalFile, true);
                tr.Peek();
                var fileEncoding = tr.CurrentEncoding;
                var content = tr.ReadToEnd();
                tr.Close();
                var globalIndex = content.IndexOf("Global");
                var globalSection = content.Substring(globalIndex, content.Length - globalIndex);
                var globalSections = globalSection.Split(new string[] { "GlobalSection(" },

                  StringSplitOptions.RemoveEmptyEntries);
                var projectsSection = content.Substring(0, globalIndex);
                projectsSection = projectsSection.Remove(0, projectsSection.IndexOf("Project("));
                var projects = projectsSection.Split(new string[] { "Project(" }, StringSplitOptions.RemoveEmptyEntries);
                var nestedProjectsSection = string.Empty;
                if (RemoveTfsBindings)
                {
                    //Remove the TFS section.
                    content = globalSections.Where(glb => glb.Contains("TeamFoundationVersionControl")).

                      Aggregate(content, (current, glb) => current.Replace(string.Concat("GlobalSection(", glb), string.Empty));
                    content = content.Replace("SAK", string.Empty);
                }
                foreach (var glb in globalSections.Where(glb => glb.Contains("NestedProjects")))
                {
                    nestedProjectsSection = string.Concat("GlobalSection(", glb);
                }
                var nestedProjects = nestedProjectsSection.Split(new char[] { '\r', '\n', '\t', '\t' },

                 StringSplitOptions.RemoveEmptyEntries).ToList();
                foreach (var projectName in ProjectNames)
                {
                    foreach (var project in projects)
                    {
                        if (project.Contains("ProjectSection")) continue;
                        var projectEntry = project.Replace("EndProject", string.Empty).Replace("\"", string.Empty).

                     Replace(" ", string.Empty).Replace("\r", string.Empty).Replace("\n", string.Empty);
                        var indexFirstEquals = projectEntry.IndexOf("=") + 1;
                        projectEntry = projectEntry.Remove(0, indexFirstEquals);
                        var projectNameGuid = projectEntry.Split(',');
                        if (projectNameGuid[0] == projectName)
                        {
                            content = content.Replace(string.Concat("Project(", project), string.Empty);
                            var nestedProject = nestedProjects.FirstOrDefault(l => l.StartsWith(projectNameGuid[2]));
                            if (nestedProject != default(string))
                            {
                                nestedProjects.RemoveAll(l => l.StartsWith(projectNameGuid[2]));
                            }
                        }
                    }
                }
                var filteredNestedProjects = string.Concat(string.Join("\r\n\t\t", nestedProjects.

                    ToArray()), "\r\n\t").Replace("\tEndGlobalSection", "EndGlobalSection");
                content = content.Replace(nestedProjectsSection,filteredNestedProjects);

                if (Replacements != null)
                {
                    for (var index = 0; index <= Replacements.Length - 1; index = index + 2)
                    {
                        content = content.Replace(Replacements[index], Replacements[index + 1]);
                    }
                }

                if (CreatedFile.Contains("_VS2008"))
                {
                    //Convert a copy to VS2008
                    content = content.Replace("# Visual Studio 2010", "# Visual Studio 2008");
                    content = content.Replace("Microsoft Visual Studio Solution File, Format Version 11.00",

                     "Microsoft Visual Studio Solution File, Format Version 10.00");
                    content = content.Replace("vbproj", "VS2008.vbproj").Replace("csproj", "VS2008.csproj");
                }

                var newSolutionFile = new StreamWriter(CreatedFile, false, fileEncoding);
                newSolutionFile.WriteLine(content);
                newSolutionFile.Close();
            }
            catch (Exception ex)
            {
                var file = new StreamWriter("F:\\Builds\\log.txt");
                file.WriteLine(ex.StackTrace);
                file.Close();
                return false;
            }
            return true;
        }
    }
}

More ...

MSBuild task to Increment the Build Number

philip.beadle@dnncorp.com — Wed, 04 May 2011 20:08:48 GMT

As part of our internal build process we increment the last number on the build number by one each time the CI build runs. Sounds simple right but I couldn’t find anywhere that did this simple task so I wrote one myself. The code below works for VB and C# files and simply takes the AssemblyVersion number out of the provided AssemblyInfo.cs file and increments the last number. It also provides formatted build numbers, the revision and the new build version as outputs. You can also specify what you want the version to be, this is useful when you have multiple Assemblyinfo.cs files that you want to keep synchronised as we do with DotNetNuke.

To use the task add this to your MSBuild file

    <IncrementBuild FilePath="$(RootFolder)\Library\AssemblyInfo.cs" AutoIncrementVersion="true">
      <Output TaskParameter="BuildVersion" PropertyName="BuildVersion">Output>
      <Output TaskParameter="FormattedBuildVersion" PropertyName="FormattedBuildVersion">Output>
      <Output TaskParameter="Revision" PropertyName="Revision">Output>
    IncrementBuild>
    <IncrementBuild FilePath="$(RootFolder)\Professional\AssemblyInfo.cs" DefaultVersion ="$(BuildVersion)"/>

You can see here that the first use of the task increments the build number and then the second use uses that output to set the version.

The code for the task is below and is getting better exception logging soon.

using System;
using System.IO;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

namespace DotNetNuke.MSBuild.Tasks
{
    public class IncrementBuild : Task
    {
        private const string VbVersionStart = ";
        private const string VbVersionEnd = ")>";
        private const string CsVersionStart = "[assembly: AssemblyVersion";
        private const string CsVersionEnd = ")]";
        private string _versionStart = CsVersionStart;
        private string _versionEnd = CsVersionEnd;

        private string _filePath;
        public string FilePath
        {
            get
            {
                if (_filePath.EndsWith("cs"))
                {
                    _versionStart = CsVersionStart;
                    _versionEnd = CsVersionEnd;
                }
                else
                {
                    _versionStart = VbVersionStart;
                    _versionEnd = VbVersionEnd;
                }
                return _filePath;
            }
            set { _filePath = value; }
        }

        public bool AutoIncrementVersion { get; set; }
        [Output]
        public string DefaultVersion { get; set; }

        [Output]
        public string BuildVersion { get; set; }

        [Output]
        public string FormattedBuildVersion { get; set; }

        [Output]
        public string Revision { get; set; }

        [Output]
        public string ErrorCode { get; set; }

        public override bool Execute()
        {
            try
            {
                if (_filePath == null)
                {
                    return false;
                }

                var content = File.ReadAllText(FilePath);
                var indexStart = content.IndexOf(_versionStart) + 28;
                var indexEnd = content.IndexOf(_versionEnd, indexStart);
                var versionNumber = content.Substring(indexStart, indexEnd - indexStart - 1);
                if (DefaultVersion != default(string))
                {
                    versionNumber = DefaultVersion;
                }
                var values = versionNumber.Split(".".ToCharArray());
                ErrorCode = versionNumber;
                int main;
                int minor;
                int version;
                int revision;
                int.TryParse(values[0], out main);
                int.TryParse(values[1], out minor);
                int.TryParse(values[2], out version);
                int.TryParse(values[3], out revision);
                if (AutoIncrementVersion)
                {
                    revision = revision + 1;
                }

                BuildVersion = String.Format("{0}.{1}.{2}.{3}", main, minor, version, revision);
                FormattedBuildVersion = String.Format("{0}.{1}.{2}", main.ToString("00"), minor.ToString("00"), version.ToString("00"));
                Revision = revision.ToString();
                if (AutoIncrementVersion || DefaultVersion != default(string))
                {
                    var projectFileInfo = new FileInfo(FilePath) { IsReadOnly = false };
                    content = content.Replace(versionNumber, BuildVersion);
                    var newProjectFile = new StreamWriter(FilePath);
                    newProjectFile.WriteLine(content);
                    newProjectFile.Close();
                    var projectFileInfo2 = new FileInfo(FilePath) { IsReadOnly = true };
                }

                return true;

            }
            catch (Exception ex)
            {
                var file = new StreamWriter("F:\\Builds\\log.txt");
                file.WriteLine(ex.StackTrace);
                file.Close();
                return false;
            }
        }
    }
}

Enjoy.

More ...

Adventures with NDepend on the DotNetNuke Codebase–baseline comparisons

philip.beadle@dnncorp.com — Mon, 07 Mar 2011 00:23:57 GMT

One of the first reasons we decided to start using NDepend was to be able to compare the public API from version to version so we could try to stop any breaking changes. To do this you need to compare a previous build’s NDepend analysis with the current build. I created a baseline analysis on the released 5.6.1 code base. I then set my current build’s baseline analysis to the 5.6.1 one and reran the analysis as part of the CI build.

This of course broke the build! The build broke because the rules on the API were marked as critical and set to return a false to the build if the rules was broken. The public API for DNN has some parts of it that even though they are marked as public are not really part of the API, these methods are typically inside the provider pattern and not for external consumption. I’ll have to figure out how to restrict the analysis to only the real API methods. but that’s a job for later, for now I’m just trying to get the reports showing all of the information we need to start the great refactoring of 2011 .

Here you can see that the analysis is now comparing against the 561EEBaseline

And here you can see the results of clicking the Code Diff tab, the results below show the Public API methods and types that have changed and will need to be investigated to see if they really are public.

NDepend is providing valuable information about our codebase allowing us to concentrate efforts to improve the codebase.

More ...

Adventures with NDepend on the DotNetNuke Codebase–Integrating with NCover Community

philip.beadle@dnncorp.com — Fri, 04 Mar 2011 01:00:41 GMT

I was trying to use the free NCover version but I keep getting stuck with this issue that appears to have been fixed in the paid for versions.

http://www.ncover.com/forum/show_topic?id=717

If anyone knows how to get around this issue I’d love to hear.

More ...

Adventures with NDepend on the DotNetNuke Codebase–Integrating with CruiseControl.Net

philip.beadle@dnncorp.com — Thu, 03 Mar 2011 05:08:12 GMT

Next task was to get a NDepend report done for each CI build. Sounds easy enough and it was once i figured out how to stop breaking the build with NDepend. We had 3 critical rules breaking that had been marked to break the build. To get a report out I needed to turn off the breaks. Once I had that done a nice HTML report is now right in the CruiseControl.Net interface for each build.

The next task is to monitor the amount of unit testing done so getting NCover Community Edition going is next. Once I have that Ill hook it up to NDepend and start to look at the amount of unit test coverage we are getting. Then we can start to use this information to drive the code quality.

More ...

Adventures with NDepend on the DotNetNuke Codebase–Build mistake found

philip.beadle@dnncorp.com — Thu, 03 Mar 2011 04:06:20 GMT

Recently Patrick Smacchia from NDepend graciously gave DotNetNuke Corp a pro license of NDepend whic I have been investigating how to use it to achieve some of the engineering teams goals such as reducing cyclometric complexity. One of the immediate benefits was that NDepend showed that one of the projects was not building correctly according to how we have the build setup. The UI shows a red alert symbol next to the DotNetNuke.Professional.FileIntegrity.dll indicating that the version of the dll in the bin folder of the website is not the same as the one in the bin folder of the project. This means that the logic in the .csproj file was not correct where it copies the latest dll from the project to the website bin folder.

So I investigated and found the relative path was one set of “..\” fixed it and

now the UI shows all greens. This type of error is normally quite difficult to find and makes debugging difficult as well.

I’m liking NDepend a lot so far. If you have any experience with NDepend and feel like education me please feel free to drop me a line.

More ...

Powershell script to speed up getting started–Update

philip.beadle@dnncorp.com — Mon, 21 Feb 2011 05:25:42 GMT

I have updated the script a bit (thanx Rob Chartier) so it works more reliably on the read only attribute.

Here’s the script.

$folder = "C:\DotNetNuke\Team Foundation Server Projects\DotNetNuke\src\Branches\DotNetNuke_5.6.2"
cd $folder

attrib -r *.* /s

$connectionString = "Server=(local);Database=DotNetNuke;Integrated Security=True"
$webConfigPath = "$folder\website\web.config"
$xml = [xml](get-content $webConfigPath)
$root = $xml.get_DocumentElement()
$root.connectionStrings.add.connectionString = $connectionString
foreach($n in $xml.selectnodes("/configuration/appSettings/add"))
    {
    switch($n.key)
            {
            "SiteSqlServer" { $n.value = $connectionString }
            }
    }
$xml.Save($webConfigPath)

Having just written this i reckon Ill some more to it to delete and create the DotNetNuke db as well.

More ...

How to trigger Sandcastle from MSBuild

philip.beadle@dnncorp.com — Wed, 10 Nov 2010 21:23:43 GMT

This is a quick note to show you how to build your MSDN style docs using Sandcastle and MSBuild.

You will need a Sandcastle Help File Builder Project (DotNetNuke_Documentation.shfbproj ) and MSBuild. Check out the blog post by Ernst Peter Taminga here.

Once you have that created you can call MSBuild and build the Sandcastle project with the following line.

I call this task from Cruise Control.Net to autoamte the creation of the docs each release now.

More ...