Be sure to check it out soon (you can preview bits of each course right now for free), as we're offering a limited-time early adopter discount that's good for the life of your subscription. Our online courses are told by the authors themselves, with names that you'll recognize, as many are MSDN Magazine contributing editors and book authors on their topics.

Courses we now offer online include:

WCF Fundamentals by Aaron Skonnard

Windows Workflow Fundamentals, by Matt Milner

WPF Fundamentals, by Ian Griffiths

Silverlight Fundamentals, by Ian Griffiths

ASP.NET 3.5 Fundamentals, by Fritz Onion

ASP.NET Ajax Fundamentals, by Fritz Onion

LINQ Fundamentals by Scott Allen

BizTalk Fundamentals by Matt Milner

BizTalk Server 2006 R2 Fundamentals by Jon Flanders

We'll be expanding this library of content in the months to come, as we continue to grow this online resource. I plan on adding modules on the Geneva family of identity products (Geneva Server, Geneva Framework, Geneva CardSpace) announced at PDC this week.

I've learned a lot of interesting tidbits as I helped to develop the back end infrastructure for Pluralsight On-Demand, and now that I'm not so crammed for time, I'll be sharing those insights here on this blog.

Congrats to all who helped bring this incredible resource to the public!

Aaron has more details if you want to know about pricing, customer feedback, and so on.

I plan to blog about my progress (and share it) if there's not already a built-in solution out there.

We've worked with Kevin in our past lives at a previous training company, and we're glad to say that he's joined us as a Pluralsight instructor. Located in the United Kingdom, Kevin will be helping out in Europe as well as helping to round out our course curriculum, but more on that later!

So I put together a simple class that holds an XmlDocument and implements ISerializable and called it SerializableXmlDocument. I'm sharing the source code here in the hopes that

a) somebody will find it useful, and

b) somebody smarter than I am will point out how I screwed it up and help me make it better.

SerializableXmlDocument includes implicit conversion operators to make it easy to convert to/from an XmlDocument. It holds the actual document in a property called Value. This "isomorph" pattern is one that I picked up from Craig.

While writing this code, I also wrote a helpful extension method for getting a byte array out of a MemoryStream that is exactly the length of the data written to the stream so far (CopyUpToSeekPointer). So don't go looking in the docs for MemoryStream for this method :) This is obviously not the most efficient way to consume bytes written to a MemoryStream since it copies the data into a new byte array, but it's very convenient in many scenarios.

Here is SerializableXmlDocument.cs:

using System;
using System.Runtime.Serialization;
using System.Xml;
using System.IO;

namespace Pluralsight.Samples
{
    [Serializable]
    public class SerializableXmlDocument : ISerializable
    {
        public SerializableXmlDocument() { }
        public SerializableXmlDocument(XmlDocument value)
        {
            this.Value = value;
        }

        public XmlDocument Value { get; set; }

        #region ISerializable implementation
        public SerializableXmlDocument(SerializationInfo info,
                                       StreamingContext context)
        {
            byte[] serializedData = (byte[])info.GetValue("doc",
                typeof(byte[]));
            if (null != serializedData)
                this.Value = Deserialize(serializedData);
        }

        public void GetObjectData(SerializationInfo info,
                                  StreamingContext context)
        {
            byte[] serializedData = null;
            if (null != Value)
                serializedData = Serialize(Value);
            info.AddValue("doc", serializedData);
        }
        #endregion

        #region implicit conversion to/from XmlDocument
        public static implicit operator SerializableXmlDocument(
            XmlDocument doc)
        {
            return new SerializableXmlDocument(doc);
        }
        public static implicit operator XmlDocument(
            SerializableXmlDocument sdoc)
        {
            return sdoc.Value;
        }
        #endregion

        #region Xml serialization helper methods
        private static byte[] Serialize(XmlDocument doc)
        {
            MemoryStream stream = new MemoryStream();
            doc.Save(stream);
            return stream.CopyUpToSeekPointer();
        }
        private static XmlDocument Deserialize(byte[] serializedData)
        {
            XmlDocument doc = new XmlDocument();
            doc.Load(new MemoryStream(serializedData, false));
            return doc;
        }
        #endregion
    }
}

...and here's the CopyUpToSeekPointer extension method for MemoryStream:

using System;
using System.IO;

namespace Pluralsight.Samples
{
    public static class MemoryStreamExtensionMethods
    {
        public static byte[] CopyUpToSeekPointer(
            this MemoryStream stream)
        {
            // copy only the part of the buffer
            // that contains the serialized document
            long length = stream.Position;
            byte[] buffer = stream.GetBuffer();
            byte[] result = new byte[length];
            for (int i = 0; i < length; ++i)
                result[i] = buffer[i];
            return result;
        }
    }
}

...and here's a sample object that uses SerializableXmlDocument:

using System;

namespace Pluralsight.Samples
{
    [Serializable]
    public class Item
    {
        public string Name { get; set; }
        public SerializableXmlDocument Data { get; set; }

        public void Print()
        {
            Console.WriteLine("Name: {0}", Name);
            Console.WriteLine(Data.Value.OuterXml);
        }
    }
}

...and here's a sample program that creates an instance of Item, serializes it, then deserializes it, printing diagnostics along the way to show that it's working properly.

using System;
using System.Xml;
using System.Runtime.Serialization.Formatters.Binary;
using System.IO;
using Pluralsight.Samples;

class DemoProgram
{
    static void Main(string[] args)
    {
        XmlDocument doc = new XmlDocument();
        doc.LoadXml("<root><child>text</child></root>");

        Item item = new Item
        {
            Name = "Testing 123",
            Data = doc,
        };

        // print object before serialization
        item.Print();

        BinaryFormatter formatter = new BinaryFormatter();
        MemoryStream stream = new MemoryStream();
        formatter.Serialize(stream, item);

        byte[] serializedItem = stream.CopyUpToSeekPointer();

        Console.WriteLine("Serialized data (base64): {0}",
            Convert.ToBase64String(serializedItem));

        item = (Item)formatter.Deserialize(
            new MemoryStream(serializedItem, false));

        // print object after deserialization
        item.Print();
    }
}

Here's the output of the previous sample program:

Flame away!

http://mercury.pluralsight.com/tools.aspx

Sorry for any inconvenience!

My goal is to fix the width of each column at design time, and any field that contains text that may be longer than my fixed width should wrap around, taking up more vertical space in the table. If you are trying to accomplish this goal, you might find these tips helpful.

1) Set up a CssClass for the GridView itself and include the table-layout:fixed style. This tells the browser that you're going to specify the width of each cell. You may also want to include the overall width of the grid here as I mention in (3).

2) The first row of the table sets the width for each cell, and that's usually the HEADER row, not the item row, so use either HeaderStyle-CssClass or HeaderStyle-Width to set the width of the cell. I wasted a lot of time trying to set the width using the ItemStyle.

3) Make certain the table itself is wide enough to hold all of the cells. I added up all of my cell widths and used that to set the width via the CssClass attribute on the GridView.

Using these guidelines, I'm having much better luck controlling the layout of my GridView controls. I hope this simple advise helps someone else!

David Starr is one of those people. I've seen him in action, and not only does he have a lot of very practical experience from the trenches, but he also has a clear ability to convey his knowledge and experience to his students. It's clearly important to David to connect with his students, and he does so in a way that lets them know that it's all about them - he's not there just to show off his mad skillz (which he has in abundance!) So I'm very excited to welcome David on board as our newest Pluralsight instructor. I apologize for not writing this sooner - we've all been really busy getting the new website out the door.

Here's what David had to say.

Welcome!

My root script defines a bunch of properties, like where the output directories for the overall build live, where the tools live, and so on. And that works fine when I run the build from the root. The properties get defined, all the child scripts are run with <nant/> tasks, and they see those properties. But if I want to drill down into the tree and run one of the build scripts lower down, suddenly there's problems because it depends on properties that are only defined in the root script. I really like being able to run builds from anywhere in the tree for perf - if I'm trying to fix a particular project, I don't necessarily want to wait for unit tests on the entire tree to run in order to see if mine passed.

Craig made a great suggestion. Put the properties into a separate script (we named it properties.nant) and <include/> that script. Then to enable hierarchical builds, we'd create a properties.nant file for each folder in the tree, which would <include/> its parent. That way I could define properties anywhere in the tree, and they would be "inherited" by anything below it.

I took that idea one step further, because I didn't want to maintain a bunch of property scripts with nothing in them but an <include/> for the parent. I wrote an <includefromparent/> nant task that walks up the directory tree looking for the target file. So now I can do this:

<includefromparent buildfile="properties.nant"/>

This worked great! But now I ran into a problem. Many of my properties are defined like so in the root properties.nant file:

<property name="libraryOutputDir" value="${project::get-base-directory()}\artifacts\libraries"/>

Do you see the issue? If I run the build with the root script, everything works fine, because it's the root nant project I'm building, and get-base-directory() refers to the root of the project, where the artifacts folder lives. But if I run from lower in the tree, it's a different project, and get-base-directory() refers to a subfolder, where the artifacts folder definitely should NOT be.

I needed a way to find the root of the project tree. So I build a second really simple nant task:

<findmarkeddir markerfile="filetolookfor.txt" property="root"/>

This task simply looks up the directory hierarchy until it finds the specified marker file, then puts the name of that directory (the "marked" directory) into a designated property (here I've called it root). With that in place, I rewrote my property definitions in terms of the base directory:

<property name="libraryOutputDir" value="${root}\artifacts\libraries"/>

Voilà! I can now run builds from any of my build scripts. They inherit properties hierarchically like you'd expect, and the system is quite easy to maintain. If you'd like to use these tasks, I've included the code for them below (not much code, really). And if you've never written a nant task yourself before, here's the article I used to figure out how it's done (it's super easy). Here's what you should read to learn about the various options for deploying your custom task assembly so nant recognizes it.

Enjoy!

Here is FindMarkedDirTask.cs

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using System.IO;

namespace PluralsightNantTasks {

[TaskName("findmarkeddir")]
public class FindMarkedDirTask : Task {

  [TaskAttribute("markerfile", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string MarkerFileName { get; set; }

  [TaskAttribute("property", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string PropertyName { get; set; }

  protected override void ExecuteTask() {
    string searchDir = this.Project.BaseDirectory;
    do {
      if (MarkerFileExistsIn(searchDir)) {
        this.Project.Properties[PropertyName] = searchDir;
        return;
      }
      searchDir = ParentOf(searchDir);
    } while (!IsRootDirectory(searchDir));
  }

  private bool IsRootDirectory(string path) {
    return Path.GetPathRoot(path) == Path.GetFullPath(path);
  }

  private string ParentOf(string directory) {
    return Path.GetFullPath(Path.Combine(directory, ".."));
  }

  private bool MarkerFileExistsIn(string directory) {
    return File.Exists(Path.Combine(directory, MarkerFileName));
  }
}
}

And here is IncludeFromParentTask.cs (note I derive from the built-in include task):

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using NAnt.Core.Tasks;
using System.IO;
using System.Globalization;

namespace PluralsightNantTasks {

[TaskName("includefromparent")]
public class IncludeFromParentTask : IncludeTask {

  protected override void Initialize() {
    string fileName = BuildFileName;
    if (fileName.Contains("/") || fileName.Contains(@"\\"))
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "buildfile attribute must only be a filename"));

    string relativePathToFoundFile = SearchParentDirectory(
      Project.BaseDirectory, fileName, 0);
      
    if (null == relativePathToFoundFile)
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "Couldn't find a file named {0}" +
        " in a parent directory of {1}",
        fileName, Project.BaseDirectory));

    // have to use a relative path here
    // because  task uses
    // Path.Combine(projectDir, BuildFileName)
    // to get the full path
    BuildFileName = relativePathToFoundFile;

    base.Initialize();
  }

  private string SearchParentDirectory(string directory,
                        string fileName, int searchDepth) {
    ++searchDepth;
  
    // see if we've traversed all the way to the root
    string currentPath = Path.GetFullPath(directory);
    if (currentPath == Path.GetPathRoot(currentPath))
      return null;

    // recurse until we find the file
    string parentDir = Path.GetFullPath(
      Path.Combine(currentPath, ".."));
    string path = Path.Combine(parentDir, fileName);
    if (File.Exists(path)) {
      StringBuilder sb = new StringBuilder();
      for (int i = 0; i < searchDepth; ++i)
        sb.Append(@"..\");
      return Path.Combine(sb.ToString(), fileName);
    }
    else return SearchParentDirectory(parentDir,
                          fileName, searchDepth);
  }
}
}

My root script defines a bunch of properties, like where the output directories for the overall build live, where the tools live, and so on. And that works fine when I run the build from the root. The properties get defined, all the child scripts are run with <nant/> tasks, and they see those properties. But if I want to drill down into the tree and run one of the build scripts lower down, suddenly there's problems because it depends on properties that are only defined in the root script. I really like being able to run builds from anywhere in the tree for perf - if I'm trying to fix a particular project, I don't necessarily want to wait for unit tests on the entire tree to run in order to see if mine passed.

Craig made a great suggestion. Put the properties into a separate script (we named it properties.nant) and <include/> that script. Then to enable hierarchical builds, we'd create a properties.nant file for each folder in the tree, which would <include/> its parent. That way I could define properties anywhere in the tree, and they would be "inherited" by anything below it.

I took that idea one step further, because I didn't want to maintain a bunch of property scripts with nothing in them but an <include/> for the parent. I wrote an <includefromparent/> nant task that walks up the directory tree looking for the target file. So now I can do this:

<includefromparent buildfile="properties.nant"/>

This worked great! But now I ran into a problem. Many of my properties are defined like so in the root properties.nant file:

<property name="libraryOutputDir" value="${project::get-base-directory()}\artifacts\libraries"/>

Do you see the issue? If I run the build with the root script, everything works fine, because it's the root nant project I'm building, and get-base-directory() refers to the root of the project, where the artifacts folder lives. But if I run from lower in the tree, it's a different project, and get-base-directory() refers to a subfolder, where the artifacts folder definitely should NOT be.

I needed a way to find the root of the project tree. So I build a second really simple nant task:

<findmarkeddir markerfile="filetolookfor.txt" property="root"/>

This task simply looks up the directory hierarchy until it finds the specified marker file, then puts the name of that directory (the "marked" directory) into a designated property (here I've called it root). With that in place, I rewrote my property definitions in terms of the base directory:

<property name="libraryOutputDir" value="${root}\artifacts\libraries"/>

Voilà! I can now run builds from any of my build scripts. They inherit properties hierarchically like you'd expect, and the system is quite easy to maintain. If you'd like to use these tasks, I've included the code for them below (not much code, really). And if you've never written a nant task yourself before, here's the article I used to figure out how it's done (it's super easy). Here's what you should read to learn about the various options for deploying your custom task assembly so nant recognizes it.

Enjoy!

Here is FindMarkedDirTask.cs

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using System.IO;

namespace PluralsightNantTasks {

[TaskName("findmarkeddir")]
public class FindMarkedDirTask : Task {

  [TaskAttribute("markerfile", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string MarkerFileName { get; set; }

  [TaskAttribute("property", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string PropertyName { get; set; }

  protected override void ExecuteTask() {
    string searchDir = this.Project.BaseDirectory;
    do {
      if (MarkerFileExistsIn(searchDir)) {
        this.Project.Properties[PropertyName] = searchDir;
        return;
      }
      searchDir = ParentOf(searchDir);
    } while (!IsRootDirectory(searchDir));
  }

  private bool IsRootDirectory(string path) {
    return Path.GetPathRoot(path) == Path.GetFullPath(path);
  }

  private string ParentOf(string directory) {
    return Path.GetFullPath(Path.Combine(directory, ".."));
  }

  private bool MarkerFileExistsIn(string directory) {
    return File.Exists(Path.Combine(directory, MarkerFileName));
  }
}
}

And here is IncludeFromParentTask.cs (note I derive from the built-in include task):

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using NAnt.Core.Tasks;
using System.IO;
using System.Globalization;

namespace PluralsightNantTasks {

[TaskName("includefromparent")]
public class IncludeFromParentTask : IncludeTask {

  protected override void Initialize() {
    string fileName = BuildFileName;
    if (fileName.Contains("/") || fileName.Contains(@"\\"))
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "buildfile attribute must only be a filename"));

    string relativePathToFoundFile = SearchParentDirectory(
      Project.BaseDirectory, fileName, 0);
      
    if (null == relativePathToFoundFile)
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "Couldn't find a file named {0}" +
        " in a parent directory of {1}",
        fileName, Project.BaseDirectory));

    // have to use a relative path here
    // because  task uses
    // Path.Combine(projectDir, BuildFileName)
    // to get the full path
    BuildFileName = relativePathToFoundFile;

    base.Initialize();
  }

  private string SearchParentDirectory(string directory,
                        string fileName, int searchDepth) {
    ++searchDepth;
  
    // see if we've traversed all the way to the root
    string currentPath = Path.GetFullPath(directory);
    if (currentPath == Path.GetPathRoot(currentPath))
      return null;

    // recurse until we find the file
    string parentDir = Path.GetFullPath(
      Path.Combine(currentPath, ".."));
    string path = Path.Combine(parentDir, fileName);
    if (File.Exists(path)) {
      StringBuilder sb = new StringBuilder();
      for (int i = 0; i < searchDepth; ++i)
        sb.Append(@"..\");
      return Path.Combine(sb.ToString(), fileName);
    }
    else return SearchParentDirectory(parentDir,
                          fileName, searchDepth);
  }
}
}

My root script defines a bunch of properties, like where the output directories for the overall build live, where the tools live, and so on. And that works fine when I run the build from the root. The properties get defined, all the child scripts are run with <nant/> tasks, and they see those properties. But if I want to drill down into the tree and run one of the build scripts lower down, suddenly there's problems because it depends on properties that are only defined in the root script. I really like being able to run builds from anywhere in the tree for perf - if I'm trying to fix a particular project, I don't necessarily want to wait for unit tests on the entire tree to run in order to see if mine passed.

Craig made a great suggestion. Put the properties into a separate script (we named it properties.nant) and <include/> that script. Then to enable hierarchical builds, we'd create a properties.nant file for each folder in the tree, which would <include/> its parent. That way I could define properties anywhere in the tree, and they would be "inherited" by anything below it.

I took that idea one step further, because I didn't want to maintain a bunch of property scripts with nothing in them but an <include/> for the parent. I wrote an <includefromparent/> nant task that walks up the directory tree looking for the target file. So now I can do this:

<includefromparent buildfile="properties.nant"/>

This worked great! But now I ran into a problem. Many of my properties are defined like so in the root properties.nant file:

<property name="libraryOutputDir" value="${project::get-base-directory()}\artifacts\libraries"/>

Do you see the issue? If I run the build with the root script, everything works fine, because it's the root nant project I'm building, and get-base-directory() refers to the root of the project, where the artifacts folder lives. But if I run from lower in the tree, it's a different project, and get-base-directory() refers to a subfolder, where the artifacts folder definitely should NOT be.

I needed a way to find the root of the project tree. So I build a second really simple nant task:

<findmarkeddir markerfile="filetolookfor.txt" property="root"/>

This task simply looks up the directory hierarchy until it finds the specified marker file, then puts the name of that directory (the "marked" directory) into a designated property (here I've called it root). With that in place, I rewrote my property definitions in terms of the base directory:

<property name="libraryOutputDir" value="${root}\artifacts\libraries"/>

Voilà! I can now run builds from any of my build scripts. They inherit properties hierarchically like you'd expect, and the system is quite easy to maintain. If you'd like to use these tasks, I've included the code for them below (not much code, really). And if you've never written a nant task yourself before, here's the article I used to figure out how it's done (it's super easy). Here's what you should read to learn about the various options for deploying your custom task assembly so nant recognizes it.

Enjoy!

Here is FindMarkedDirTask.cs

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using System.IO;

namespace PluralsightNantTasks {

[TaskName("findmarkeddir")]
public class FindMarkedDirTask : Task {

  [TaskAttribute("markerfile", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string MarkerFileName { get; set; }

  [TaskAttribute("property", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string PropertyName { get; set; }

  protected override void ExecuteTask() {
    string searchDir = this.Project.BaseDirectory;
    do {
      if (MarkerFileExistsIn(searchDir)) {
        this.Project.Properties[PropertyName] = searchDir;
        return;
      }
      searchDir = ParentOf(searchDir);
    } while (!IsRootDirectory(searchDir));
  }

  private bool IsRootDirectory(string path) {
    return Path.GetPathRoot(path) == Path.GetFullPath(path);
  }

  private string ParentOf(string directory) {
    return Path.GetFullPath(Path.Combine(directory, ".."));
  }

  private bool MarkerFileExistsIn(string directory) {
    return File.Exists(Path.Combine(directory, MarkerFileName));
  }
}
}

And here is IncludeFromParentTask.cs (note I derive from the built-in include task):

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using NAnt.Core.Tasks;
using System.IO;
using System.Globalization;

namespace PluralsightNantTasks {

[TaskName("includefromparent")]
public class IncludeFromParentTask : IncludeTask {

  protected override void Initialize() {
    string fileName = BuildFileName;
    if (fileName.Contains("/") || fileName.Contains(@"\\"))
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "buildfile attribute must only be a filename"));

    string relativePathToFoundFile = SearchParentDirectory(
      Project.BaseDirectory, fileName, 0);
      
    if (null == relativePathToFoundFile)
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "Couldn't find a file named {0}" +
        " in a parent directory of {1}",
        fileName, Project.BaseDirectory));

    // have to use a relative path here
    // because  task uses
    // Path.Combine(projectDir, BuildFileName)
    // to get the full path
    BuildFileName = relativePathToFoundFile;

    base.Initialize();
  }

  private string SearchParentDirectory(string directory,
                        string fileName, int searchDepth) {
    ++searchDepth;
  
    // see if we've traversed all the way to the root
    string currentPath = Path.GetFullPath(directory);
    if (currentPath == Path.GetPathRoot(currentPath))
      return null;

    // recurse until we find the file
    string parentDir = Path.GetFullPath(
      Path.Combine(currentPath, ".."));
    string path = Path.Combine(parentDir, fileName);
    if (File.Exists(path)) {
      StringBuilder sb = new StringBuilder();
      for (int i = 0; i < searchDepth; ++i)
        sb.Append(@"..\");
      return Path.Combine(sb.ToString(), fileName);
    }
    else return SearchParentDirectory(parentDir,
                          fileName, searchDepth);
  }
}
}