Getting a WeekNumber from a Date in SSRS 2005 and 2008

Many reports have to deal with week numbers. Often you'll have a DateTime to work with, either from a dataset or a parameter.

So, how do we convert this lovely little DateTime to a WeekNumber? Search for that online and you'll get some solutions suggesting you change your query to give you a weeknumber, some solutions will do some fancy (and mostly erroneous) math to calculate the WeekNumber and yet others suggest you just don't do that.

Getting the WeekNumber from your DataSet really is what you want, but then again you don't really want your DataSource to calculate the WeekNumber in all instances. The reason for that is related to the reason why DateTime does not have a WeekNumber:

What, really, is a weeknumber? Why, silly, it's the number of the week the day is a part of.

That's true, but how are the weeks numbered? Do they start with week 0 or week 1? If the week numbering starts at week 1 the last week should be week 53, or should it be week 52 (a week with more than 7 days)? How about if the year starts on a non-monday, what week are the first days in (they could be in the last week of the previous year, in the first (0th or 1st) of the new year, or perhaps even week-less).

How about weeks, do they start on Mondays, Sundays, Saturdays, Fridays or some other day? That's kind of important when trying to calculate the first week of the year and counting the weeks until a date.

Calendaring issues get complicated very fast, and the fun thing about them is that there are so many ways people keep track of their measured days. The year could start at wildly differing dates, it's silly to assume that the first of January is the first day of a year, and if it's not you'd better not be DateDiffing that modulus 7 to get a WeekNumber.

I'll just happily ignore systems with weeks of more or less than 7 days. That would get hard.

With all this in mind also consider that your datasource may not be using the same calendaring as your reporting system. If your report may be run in Tehran and your DataSource is a database of some sort in Tel-Aviv they may not be using the same calendar, but it'd be an admirable instance of Persian/Semittic cooperation.

To get your week number you really should defer all the international issues to the people who've researched it and been paid to do a good job of it. Luckilly the .Net framework is produced by just such people, and I just love it when I can let it do the work for me.

The .Net framework (in which you report is running) knows about the locale it's running in, and this information can be used to derive the WeekNumber without ever adding together two days.

You just add this code snippet to your Code tab in your report properties:

Function getWeekNumber(ByVal d As DateTime) As Integer
    dim culture as System.Globalization.CultureInfo
    culture = system.Globalization.CultureInfo.CurrentCulture
 
    dim weekRule as System.Globalization.CalendarWeekRule
    weekRule = culture.DateTimeFormat.CalendarWeekRule
 
    dim firstDayOfWeek as System.DayOfWeek
    firstDayOfWeek = culture.DateTimeFormat.FirstDayOfWeek
 
    return culture.Calendar.GetWeekOfYear(d, weekRule, firstDayOfWeek)
End Function

Explanation:
First we get the current culture the report is running under (this would be the culture of the locale of the server running SSRS in our case). From this culture you extract the rule for starting weeks relative to the year and which day of the week the weeks start on. These two values, together with the date you have are passed into the Calendar of the current culture to get the WeekNumber of the date in that context.

It really is harder than it should be, but with this code (which you can just copy/paste) you make a new Calculated Field on your dataset with the following expression (I assume the Date field you want to convert to a WeekNumber is called Date in this instance):

=Code.getWeekNumber(Fields!Date.Value)

And, as they say, Robert is your mother's brother.

Addendum:

If you don't want to go through adding the WeekNumber to your DataSet you could of course just use the above expression straight in your textboxen or the like.

If you don't want the code you can inline it all as such (this is UGLY, don't do it!):

=System.globalization.CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(Fields!Date.Value, System.globalization.CultureInfo.CurrentCulture.DateTimeFormat.CalendarWeekRule, System.globalization.CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek)

Simpler reference equality on mocks

When mocking with MoQ I find myself regularly setting up the .Equals() method on the mocks. It just makes for more readable code to be able to ask a collection whether it .Contains() the mock than writing out the iteration myself.

But it does bloat my test-cases somewhat. Here's an example setting up a mock of a class with the equality set that returns true if it's compared to itself:

[Test(Description = "Mock of equals on an instance succeeds")]
public void MockingEquals_SameInstance_AreEqual() {
 var mocker = new Mock<SomeClass>();
 mocker.Setup(x => x.Equals(mocker.Object)).Returns(true);

 var mockedObject = mocker.Object;

 Assert.That(mockedObject.Equals(mockedObject));
}

That's fine if it's only in one test, but I don't like to repeat that all over my code. My first thought was to make a convenience method which set up the equality for me:

public static Mock<T> ReferenceEquals<T>(Mock<T> mock) where T : class {
 mock.Setup(m => m.Equals(mock.Object)).Returns(true);
 return mock;
}

Sticking this in some public place now allows me to set up my test from before like this:

[Test(Description = "Mock of equals on an instance succeeds")]
public void MockingEquals_SameInstance_AreEqual() {
 var mocker = new Mock<SomeClass>();
 ReferenceEquals(mocker);

 var mockedObject = mocker.Object;

 Assert.That(mockedObject.Equals(mockedObject));
}

That's certainly better. But, we can do better than that, can't we? Let's make it an extension-method, for great success! To use this code the class containing the extension-method must be static.

public static void HasReferenceEquality<T>(this Mock<T> mock) where T : class {
 mock.Setup(m => m.Equals(mock.Object)).Returns(true);
}

And with that our test has been transferred to the (in my opinion) much more readable:

[Test(Description = "Mock of equals on an instance succeeds")]
public void MockingEquals_SameInstance_AreEqual() {
 var mocker = new Mock<SomeClass>();
 mocker.HasReferenceEquality();

 var mockedObject = mocker.Object;

 Assert.That(mockedObject.Equals(mockedObject));
}

Great success!

MoQ with Collections, or equality woes

Still working with the fine mocking-framework MoQ, I came across a somewhat surprising facet (and I don't like surprises).
I'm mocking out a class which should be added to a collection after a method-call, like so:

public class SomeClass{
 
}

public class Container {
 private List<SomeClass>; classes = new List<SomeClass>();
 
 public IEnumerable<SomeClass> Classes {
  get {
   return classes;
  }
 }
 
 public void addSomeClass(SomeClass instance) {
  classes.Add(instance);
 }
}

[Test]
public void ContainerContainsAddedClassAfterAdd() {
 var mockSomeClass = new Mock<SomeClass>(); 
 mockSomeClass.Setup(c => c.Equals(mockSomeClass.Object)).Return(true);
 
 var Container = new Container();
 Container.addSomeClass(mockSomeClass.Object);
 
 Assert(Container.Classes.Contains(mockSomeClass.Object));
}

This works well, the mock is added to the Container's collection and the setup of the Equals method on the mock makes sure the IEnumerable.Contains() return true.
However there's always some complication. The class I'm really mocking out is not as simple as our SomeClass. It's something like this:

public class SomeClassOverridingEquals{
 public virtual Equals(SomeClassOverridingEquals other) {
  return false; 
 }
 
 public override Equals(object obj) {
  var other = obj as SomeClassOverridingEquals;
  
  if (other != null) return Equals(other); // calls the override
  return false;
 }
}

[Test]
public void ContainerContainsAddedClassOverridingEqualsAfterAdd() {
 var mockSomeClass = new Mock<SomeClassOverridingEquals>(); 
 mockSomeClass.Setup(c => c.Equals(mockSomeClass.Object)).Return(true);
 
 var Container = new Container();
 Container.addSomeClass(mockSomeClass.Object);
 
 Assert(Container.Classes.Contains(mockSomeClass.Object)); // fails
}

The class contains an override for the Equals method for its own specific type, and the Setup method for the mock does not seem to be able to mock out that specific method (only overriding the more general Equals(object)). Thus the test fails.

I have so far found no way of working around this quite common pattern, other than rewriting the class not to use the overriding equals.

I don't like that.

Anyone have any ideas?

Mocking expectations on Property setters with MoQ

When mocking out your classes using the fabulous MoQ mocking-framework you may sometimes need to mock out an expectation that a property on your mocked object should be set.

It took me some time to figure out how to do this. The documentation on the MoQ quickstart wiki says to use the following pattern:

// expects an invocation to set the value to "foo"
mock.SetupSet(foo => foo.Name = "foo");

Well, I tried this with an object:

public class SomeClass {
  public string Something { get; set; }
}

[Test]
public void PropertySetupOnMock() {
  const string someString = "Should be set";
  var mocker = new Mock<SomeClass>();

  mocker.SetupSet(x => x.Something = someString); //exception here
  mocker.Object.Something = someString;
  mocker.VerifySet(x => x.Something);
}

This only gave me an error on the line with the SetupSet:

System.ArgumentException: Invalid expectation on a non-overridable member.

Well, that's strange. After some looking around it turns out that MoQ does its magic by extending the class that's being mocked. It cannot extend non-virtual properties, so this Something property cannot be extended and thus cannot be Setup.
What can be done about this? The easiest immediate solution would be to mark the property virtual, like so:

public class SomeClass {
  public virtual string Something { get; set; }
}

But do we really want to decorate every property on the objects as virtual? Not really. A better solution is to push the property up to an interface and mock that interface instead, like so:

public interface IWithProperty {
  public string Something { get; set; }
}

public class SomeClass : IWithProperty {
  public string Something { get; set; }
}

[Test]
public void PropertySetupOnInterfaceMock() {
  const string someString = "Should be set";
  var mocker = new Mock<IWithProperty>();

  mocker.SetupSet(x => x.Something = someString); //no exception here
  mocker.Object.Something = someString;
  mocker.VerifySet(x => x.Something);
}

Thus allowing me to mock it out and test that the property setter was indeed called. Yay!
If anyone has any better ways of doing this I'd love to hear from you!

Listing the properties of an object

Sometimes you just want to print out the state of some reasonably rich object (for logging or GUI mock-up or whatever). This code gives you a PropertyGetter class with two easy-to-use static methods. listProperties returns a name: value string listing of the properties on the input object, for easy logging.

If you want the object's properties as a list of properties you can get that as well.

NB: This simple class does not recurse through complex objects, so you will only ever get the top-level of a property.

Code:

using System.Collections.Generic;
using System.Reflection;
using System.Text;

namespace Code_Examples {
 class PropertyGetter {
  public static string listProperties(object someObject) {
   StringBuilder sb = new StringBuilder();

   List<pair> props = getProperties(someObject);

   foreach (Pair prop in props) {
    sb.AppendLine(prop.Name + ": " + prop.Value);
   }
   return sb.ToString();
  }

  public static List<pair> getProperties(object someObject) {
   List<pair> dic = new List<pair>();

   PropertyInfo[] props = someObject.GetType().GetProperties();
   foreach (PropertyInfo prop in props) {
    Pair t = new Pair {
     Name = prop.Name,
     Value = prop.GetValue(someObject, null)
    };
    dic.Add(t);
   }
   return dic;
  }
 }

 public class Pair {
  public string Name {
   get;
   set;
  }
  public object Value {
   get;
   set;
  }
 }
}

Logging snippets ready to go

My last post was some simple intro to how you can make your own snippets - here are some easy ones I made to make logging with log4net easier.

This first one is one I use simply to get a logger with the name of the current class. I put this in most every class. Nothing fancy here, just type log and press tab to get a logger named log.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Logging
   </Title>
      <Author>Tomas Ekeli</Author>
      <Description>Initializes a logger with the name of the current class</Description>
      <HelpUrl />
      <SnippetTypes />
      <Keywords />
      <Shortcut>log</Shortcut>
    </Header>
    <Snippet>
      <References>
        <Reference>
          <Assembly>log4net.dll</Assembly>
          <Url />
        </Reference>
      </References>
      <Imports>
        <Import>
          <Namespace>log4net</Namespace>
        </Import>
      </Imports>
      <Declarations />
      <Code Language="CSharp" Kind="" Delimiter="$"><![CDATA[protected static readonly ILog log = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); ]]></Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Now you've got a logger up and running you'll be doing a lot of calls to log.debug("somestring") and even more with formatting on that string. So here's a snippet for that:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>logFormattedString</Title>
      <Author>Tomas Ekeli</Author>
      <Description>log formatted string</Description>
      <HelpUrl></HelpUrl>
      <SnippetTypes />
      <Keywords />
      <Shortcut>lsf</Shortcut>
    </Header>
    <Snippet>
      <References>
        <Reference>
          <Assembly>log4net</Assembly>
          <Url />
        </Reference>
      </References>
      <Imports>
        <Import>
          <Namespace>log4net</Namespace>
        </Import>
      </Imports>
      <Declarations>
        <Literal Editable="true">
          <ID>Level</ID>
          <Type />
          <ToolTip>Log level</ToolTip>
          <Default>Debug</Default>
          <Function />
        </Literal>
        <Literal Editable="true">
          <ID>Message</ID>
          <Type />
          <ToolTip />
          <Default>field value: {0}</Default>
          <Function />
        </Literal>
        <div class="youtube-video"><object Editable="true">
          <ID>Field</ID>
          <Type>Object</Type>
          <ToolTip>The field to log</ToolTip>
          <Default></Default>
          <Function />
        </object></div>
      </Declarations>
      <Code Language="csharp" Kind="method body" Delimiter="$"><![CDATA[log.$Level$(string.Format("$Message$", $Field$));]]></Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Finally a very nice thing about logging is when you can push the context on a stack for inclusion. I use this all the time. This snippet can be used as a surrounding snippet as well (mark the text you want to surround in a context and right-click -> Surround-with

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>logFormattedString</Title>
      <Author>Tomas Ekeli</Author>
      <Description>log formatted string</Description>
      <HelpUrl></HelpUrl>
      <SnippetTypes />
      <Keywords />
      <Shortcut>lsf</Shortcut>
    </Header>
    <Snippet>
      <References>
        <Reference>
          <Assembly>log4net</Assembly>
          <Url />
        </Reference>
      </References>
      <Imports>
        <Import>
          <Namespace>log4net</Namespace>
        </Import>
      </Imports>
      <Declarations>
        <Literal Editable="true">
          <ID>Level</ID>
          <Type />
          <ToolTip>Log level</ToolTip>
          <Default>Debug</Default>
          <Function />
        </Literal>
        <Literal Editable="true">
          <ID>Message</ID>
          <Type />
          <ToolTip />
          <Default>field value: {0}</Default>
          <Function />
        </Literal>
        <div class="youtube-video"><object Editable="true">
          <ID>Field</ID>
          <Type>Object</Type>
          <ToolTip>The field to log</ToolTip>
          <Default></Default>
          <Function />
        </object></div>
      </Declarations>
      <Code Language="csharp" Kind="method body" Delimiter="$"><![CDATA[log.$Level$(string.Format("$Message$", $Field$));]]></Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Code snippets

I like anything which makes my day easier. Code snippets are one of these things. You can make your own code-snippets by editing xml directly, using the code snippet schema reference, or you could use a tool. Snippet Editor is just such a tool. With it making and editing snippets is dead simple!

One thing I've noticed with it, though, is that you cannot make a "SurroundsWith" snippet in this tool. To do this you have to edit the xml yourself. It's easy when you know how - just add the following to the header section of your snippet definition:

<SnippetTypes>
   <SnippetType>Expansion</SnippetType>
   <SnippetType>SurroundsWith</SnippetType>
</SnippetTypes>

And in your snippet section you add selected and end fields where you would insert the code you want to surround with the snippet (the following example would surround the selected code with curly braces).

<Code Language="csharp" Kind="method body" Delimiter="$">
   <![CDATA[{ $selected$ $end$}]]>
</Code>