The ASP.NET Repeater control is a very useful patten that minimizes code and allows you to use templates to represent repetitive data.

All of you are probably familiar with it and use it quite often.

Yesterday I had a big fight with the repeater control, and since most of the Internet (actually search engines for that matter) is filled with lots of data about the Repeater control and how to use it, I couldn’t find the answer I was looking for.

Apparently it was staring me right in the face.

The problem was that I needed to display a list of words with a comma separator and they should have looked like this:

word a, word b, word c, word d

but what I got was this:

word a , word b , word c , word d

An additional and unwanted extra space before the comma.

That code that I used in the ASPX file was this:



<% #Eval(“Text”) %>


<SeparatorTemplate>, </SeparatorTemplate>


All seems well, right? there is no space before the comma in the separator template, but there was when the whole thing was rendered.

The fix was quite stupid (and is quite fragile):



<% #Eval(“Text”) %></ItemTemplate>

<SeparatorTemplate>, </SeparatorTemplate>


The extra enter which placed the </ItemTemplate> element in a new line was the cause of this problem. That new line was translated in this case into a single space which made everything look weird.

It seem that the Repeater control (and possibly other template based ASP.NET controls) are sensitive to the ASPX formatting. They are not trimming the edges of content that resides inside the template ASPX element, thus making them susceptible for formatting weirdness.

The worst problem of all is that when you use Visual Studio’s auto formating (Ctrl-E, Ctrl-D by default, if I’m not mistaken) it will ruin the layout and you might end up with a Repeater that has an extra space even if you didn’t want it.

I can understand why the edges were not trimmed, so that you can and should be able to enter white spaces as part of your template, but Visual Studio itself when formatting a document to be more clearly read will mess things up and that is the true problem.

While this is not a “real” advanced .NET debugging issue and I didn’t use any cool tools to figure it out it annoying nonetheless 🙂