Ok, so you’ve got your shiny new mvc3 app up and running. Now, it’s time to bake in some of that SEO goodness. Here’s how you can easily add a sitemap.xml to your new mvc application. The solution specified below not only pumps out the xml file to submit to the search engines, but it is also a System.Web.SiteMapProvider, so you can use it for menus and wherever else you want to use your sitemap.

I’m a big fan of NuGet, so bring up the Package Manager Console and grab MvcSiteMapProvider (or download it from github).

Install-Package MvcSiteMapProvider

Once it is installed there will be a new Mvc.sitemap file added with the following to your solution:

<mvcSiteMapNode title="Home" controller="Home" action="Index">
    <mvcSiteMapNode title="About" controller="Home" action="About"/>
</mvcSiteMapNode>

Now for the easy bit: to get a ~/sitemap.xml to auto-generate for us based on our controller actions we specified in the sitemap file above. All you need to do is simply add the following to your route registration (generally Global.Application_Start()):

XmlSiteMapController.RegisterRoutes(RouteTable.Routes);

Now, like a lot of other people out there my next question was, what about my dynamically generated content from the database (such as Product/Details/1)?  Easy – MvcSiteMapProvider comes with dynamic node support. Just create a class like the following:

public class ProductDetailsDynamicNodeProvider : DynamicNodeProviderBase
 {
     public override IEnumerable<DynamicNode> GetDynamicNodeCollection()
     {
         // Create a node for each product
         foreach (Product product in productService.GetAllProducts())
         {
             var node = new DynamicNode();
             node.Title = product.Name;
             node.RouteValues.Add("id", product.Id);

             yield return node;
         }
     }
     public override CacheDescription GetCacheDescription()
     {
        return new CacheDescription("ProductDetailsDynamicNodeProvider")
        {
            SlidingExpiration = TimeSpan.FromMinutes(60);
        };
    }
 }

Things to note with the above code: you don’t have to override the cachedescription method, but this does allow us to specify how long all our products will be cached for in the sitemap. Then, you can add your dynamic node to the mvc.sitemap files as follows:

<mvcSiteMapNode title="Details" action="Details"
dynamicNodeProvider="Website.ProductDetailsDynamicNodeProvider, Website"/>

Now you are done and have a working auto-generated mvc sitemap. For those of us who are using it to generate breadcrumbs, check out the awesome example of html helpers in the documentation.

Next time, I’ll be looking at creating SEO friendly URLs in MVC.

Now that I’m developing in .NET 4.0 I thought all my covariance problems were behind me. This was until I tried to use the following:

public class  Animal {
    public void AttackOtherAnimals(IList<Animal> animals) { }
}

public class Dog : Animal { }

Dog angryDog = new Dog();
List dogsToAttack = new List<Dog>();
angryDog.AttackOtherAnimals(dogsToAttack);

Turns out, IEnumerable<T> has support for covariance, IList<T> does not. I’d like to thank Marc Gravell for his excellent writeup on this.

One way around this (instead of dogsToAttack.Cast<Animal>().ToList()) is to use generics to accept any IList<T> where T is of type Animal.

public void AttackOtherAnimals(IList<T> animals) where T : Animal { }

I was trying my hand at whipping up some jQuery today and realising the awesome intellisense that is provided, couldn’t wait to get stuck in. Since I do enjoy adhering to the DRY principle wherever possible I decided I needed to use master pages first before I create my example content. I then set out to try and do a basic hello world example but realized my intellisense wasn’t working with jQuery. It was working with vanilla ASP .NET pages, just not content pages.

It turns out, that VS uses -vsdocs javascript files to provide this support. It requires it to be sitting next to your jquery file that you are referencing. Which it was thanks to the MVC Internet Application project template. It seems that ASP .NET doesn’t know at design time that I’m referencing jQuery in the master page.

After asking Professor Google, I stumbled upon a solution. I decided to slap the following bit of code into any content page that I have created and want some good ol’ intellisense.

<% #if (false) %>
<script src="~/scripts/jquery-1.4.4.js" type="text/javascript"></script>
<% #endif %>

Yes, this is a bit of hack to get it working and yes, I would like Microsoft to fix it. In the mean time, I will be egarly awaiting the intellisense support to be released for the latest 1.5 version.

UPDATE: I’ve just found that somebody has generated a new vsdoc for jQuery 1.5

UPDATE 2: If you reference your jQuery from the Microsoft CDN, you get intellisense since they also host the vsdoc files. Sadly, the Google CDN does not.

I think most of you can agree that we are advocates of Entity Framework here. But sometimes things can get a little hairy (as with all ORM solutions). So I just thought I’d post a quick solution to a problem that had me tearing my hair out at work to solve the other day.

Given the following two queries using Entity Framework one would assume the generated sql would the same?

string country = null;
var query = context.Orders.Where(o => o.Customer.Address.Country == country);
var query2 = context.Orders.Where(o => o.Customer.Address.Country == null);

Further to Gerrod’s post on selecting an item in a treeview, I found myself scratching my head on how to find a treeviewitem’s parent item. Here I was expecting a TreeViewItem.Parent property. Unfortunately after scouring the dark depths of the internet, I found that using the VisualTreeHelper class was the answer:

private static TreeViewItem GetParentTreeViewItem(DependencyObject item)

{
if (item != null)
{
  DependencyObject parent = VisualTreeHelper.GetParent(item);
  TreeViewItem parentTreeViewItem = parent as TreeViewItem;
  return parentTreeViewItem ?? GetParentTreeViewItem(parent);
}

return null;
}

I’m sure this can be easily converted into an extension method for those of you expecting the Parent property like I was.

I’m sure alot of you have come across a method that uses DateTime.Now at some point in your lives. Normally this is fine and nobody blinks an eyelid… until we need to unit test it.

Consider the follow code:

public class MyEntity
 {
   public DateTime Created { get; set; }
 }

 public class MyRepository
 {
   public void UpdateMyEntity(MyEntity entity)
   {
     entity.Created = DateTime.Now;
   }
 }

Unless you are one of one of those fancy pants with TypeMock and the ability to fake DateTime.Now, the rest of use must look elsewhere for a solution. Here are three different ways to solve this.

1. Wrap your DateTime calls with another class

Some people prefer using a static “Clock” class to handle this which can be easily faked out during your unit testing.

public static class Clock
{
    public static Func<DateTime> Now = () => DateTime.Now;
}

This approach, while decoupling your dependency on System.DateTime is a bit of overkill and requires all developers on the project to be aware of it and to use it.

2.Use an Interface and your favourite Isolation Framework

public interface IClock
{
  DateTime Now {get;}
}

public class SystemClock : IClock
{
  public DateTime Now { get { return DateTime.Now; } }
}

You can now use an isolation framework such as Rhino.Mocks to fake the call to Now();

3. Use a DateTime Comparer that accepts a range

While not 100% accurate to the millisecond, this approach is my prefered approach as you don’t have to change to your code just to unit test it. No littering your code with IClock dependencies or using a delegate to return the current DateTime.Now (although one could argue that DateTime.Now shouldn’t be a property to begin with). This approach asserts that the Created property that is set in MyRepository.Update is within a certain range.

 /// <summary>
 /// Helper class to compare 2 values are within a certain range.
 /// </summary>
 public class DateComparer : IComparer<DateTime>
 {
 public TimeSpan MarginOfError { get; private set; }

 public DateComparer(TimeSpan marginOfError)
 {
   MarginOfError = marginOfError;
 }

  public int Compare(DateTime x, DateTime y)  // x = expected, y = actual
   {
     var margin = x - y;
     if (margin <= MarginOfError)
       return 0;
     return new Comparer(CultureInfo.CurrentUICulture).Compare(x, y);
   }
 }

You can now write the follow test:

public void MyRepository_UpdateTest()
 {
   var repository = new MyRepository();
   var entity = new MyEntity();
   repository.UpdateMyEntity(entity);
   var comparer = new DateComparer(new TimeSpan(0, 0, 0, 5));
   Assert.IsTrue(comparer.Compare(entity.Created, DateTime.Now) == 0);
 }

One thing that I find myself doing all the time is creating some type of base class for my windows/controls in WPF:

namespace Editors {
    public class EntityEditorControlBase<TModel> : UserControl
        where TModel : class, IEntityEditorModel {

        public TModel Model {
            get { return DataContext as TModel; }
            protected set { DataContext = value; }
        }
    }
}

Since this is a generic control you need to specify the concrete type arguments when you subclass it. You can do this in your WPF markup via the x:TypeArguments attribute:

<Editors:EntityEditorControlBase
    x:Class="ConcreteEntityEditorControl"
    x:TypeArguments="Models:ConcreteEntityEditorControlModel"
    xmlns:Editors="clr-namespace:Editors">

    <UserControl.Resources>
        <ResourceDictionary Source="../Resources/EditorResources.xaml" />
    </UserControl.Resources>

    <!-- control content here -->

</Editors:EntityEditorControlBase>

Two important things to note:

• When you want to attach a resource dictionary to the class, you need to do so using the <UserControl.Resources> tag
• In your base class control, make sure you include the [ContentProperty("Content")] and [DefaultProperty("Content")] tags on your class to avoid the horrible “The type ‘{0}’ does not support direct content” error.

I have to admit that I much prefer WPF over Windows Forms (but prefer ASP.Net to either). However, the programming model is still a bit immature (in my opinion), and sometimes things that you wish were simple just aren’t. Case and point: trying to programmatically select an item in a TreeView control; it just ain’t easy!

Anyway, after scrubbing the web and finding a few solutions that really didn’t appeal (e.g. using reflection; surely it’s not that hard!) I came up with this extension method which does the trick quite nicely.

/// <summary>
/// Walks the tree items to find the node corresponding with
/// the given item, then sets it to be selected.
/// </summary>
/// <param name="treeView">The tree view to set the selected
/// item on</param>
/// <param name="item">The item to be selected</param>
/// <returns><c>true</c> if the item was found and set to be
/// selected</returns>
static public bool SetSelectedItem(
    this TreeView treeView, object item) {

    return SetSelected(treeView, item);
}

static private bool SetSelected(ItemsControl parent,
    object child) {

    if (parent == null || child == null) {
        return false;
    }

    TreeViewItem childNode = parent.ItemContainerGenerator
        .ContainerFromItem(child) as TreeViewItem;

    if (childNode != null) {
        childNode.Focus();
        return childNode.IsSelected = true;
    }

    if (parent.Items.Count &gt; 0) {
        foreach (object childItem in parent.Items) {
            ItemsControl childControl = parent
                .ItemContainerGenerator
                .ContainerFromItem(childItem)
                as ItemsControl;

            if (SetSelected(childControl, child)) {
                return true;
            }
        }
    }

    return false;
}

(Forgive formatting; the code window is only so-wide.)

The trick, you see, is to use the ItemContainerGenerator on the ItemsControl – which TreeView and TreeViewNode both inherit from – to try to find the container for the item you are selecting. This will only work for the immediate children of the control that you’re calling it on – so asking your root node for the container for an item which is three nodes deep is fruitless; hence, you have to walk down the tree asking each branch node if it contains the item.

It’s possibly not the fastest executing code in the world – walking a tree rarely is – but you could speed things up if you knew where the parent node was; then you could just call the recursive method directly.

Enjoy!

I’ve been focusing a lot (read: “learning”) on WPF lately, and one thing that crops up all the time is StaticResource and DynamicResource. I had tried to infer their usage/differences from the context of where I’d seen them used, but I could never quite get it right. Anyway, I just read a nice definition which makes it all rather clear:

Static resources are resolved at compile time, whereas dynamic resources are resolved at runtime.

Use DynamicResources when the value of the resource could change during the lifetime of the Application.

Use StaticResources when it’s clear that you don’t need your resource re-evaluated when fetching it – static resources perform better than dynamic resources.