Today I passed the 70-536 TS: Microsoft .NET Framework – Application Development Foundation exam. I’m happier about this one than I was about the Web-Based Client exam since I barely had time to study due to illness. So, this completes my MCTS: .NET Framework 2.0 Web Applications and gets me yet another step closer to my MCPD: Enterprise Application Developer certification

I use Virtual PC for my desktop virtualisation needs. I love how virtualisation works. I have a set of base images I use to quickly set up any development environment, anywhere (provided the host pc has enough memory, which is pretty much a non-requirement these days).

Today I was getting settled down to do some SharePoint development. I created a desktop shortcut to my Virtual PC image file, double-clicked it to get started and..promptly cancelled the boot process. Why? Because, perfectionist as I am, I noticed the Virtual PC Console fireing up as well.

The Console is undoubtedly very handy when you have multiple VPCs running simultaneously. It shows you which machines are running together with a thumbnail image of the machine’s desktop. But when you are running only a single VPC at any single time, it’s overkill. And it clutters my otherwise pristine desktop.

Google to the rescue (again). After a little searching and some experimenting, I changed the Target property of my shortcut to the following:

"C:\Program Files\Microsoft Virtual PC\Virtual PC.exe" -pc "RI SharePoint Development" -singlepc -launch

The -pc option simply specifies the name of the Virtual PC Image you want to launch. The -launch option tells VPC to, well, launch the specified Image. And last but not least (since that’s why I am writing this in the first place) the -singlepc option tells VPC to forget about the Console and just go ahead and run the Image.

I’m happy again now

Note 1: The -pc option must be the first option specified. If you don’t, this is what you’ll get:

Note 2: If you are using the Save State option it can take a while for the VPC Image to launch. Don’t worry, it’s on it’s way.

Recently I’ve been exploring the possibilities of MSBuild in my projects. MSBuild is a command-line tool so this involved spending a lot of time at the Visual Studio 2008 Command Prompt. And having to change directories every time I started a new instance really started getting on my nerves. So, Google to the rescue!

I found plenty of posts on the subject but none of them seemed to work for me. So, I modified the one I found here (thanks devsuldier!). Here are the steps to add the VS2008 Command Prompt to the context menu:

1. Using Notepad, create a file called “VS2008Cmd.reg”. Mind the extension!
2. Copy-paste the following lines into the file:

Windows Registry Editor Version 5.00 
 
[HKEY_CLASSES_ROOT\Directory\Background\shell\VS2008 Command Prompt]
@="Open VS2008 Command Prompt Here"
"Extended"=""
"NoWorkingDirectory"=""
 
[HKEY_CLASSES_ROOT\Directory\Background\shell\VS2008 Command Prompt\command]
@="C:\\Windows\\System32\\cmd.exe /s /k \"cd \"%1\" && \"C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat\"\" x86 "
 
[HKEY_CLASSES_ROOT\Directory\shell\VS2008 Command Prompt]
@="Open VS2008 Command Prompt Here"
"Extended"=""
"NoWorkingDirectory"=""
 
[HKEY_CLASSES_ROOT\Directory\shell\VS2008 Command Prompt\command]
@="C:\\Windows\\System32\\cmd.exe /s /k \"cd \"%1\" && \"C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat\"\" x86 "
 
[HKEY_CLASSES_ROOT\Drive\shell\VS2008 Command Prompt]
@="Open VS2008 Command Prompt Here"
"Extended"=""
"NoWorkingDirectory"=""
 
[HKEY_CLASSES_ROOT\Drive\shell\VS2008 Command Prompt\command]
@="C:\\Windows\\System32\\cmd.exe /s /k \"cd \"%1\" && \"C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat\"\" x86 "

3. Save the file. Double-click the file to add the entries to the registry.

Now, when you Shift+Right-Click on a folder you can select the Visual Studio 2008 Command Prompt. Sweet!

As a side-note, I ran into the problem that my current workplace resets the registry after rebooting. Annoying as hell, but luckily it’s not difficult to create a little startup script to add the entries to the registry every time I boot up:

1. Create a new file “AddVS2008Cmd.bat”. Again, mind the extension.
2. Copy-paste the following lines into the file:

@echo off
@echo -- Adding Visual Studio 2008 Command Prompt to the Explorer Context Menu
regedit.exe /s "VS2008Cmd.reg"

3. Add a shortcut to the Startup folder. To do this, navigate to Start > All Programs, right-click on the Startup folder and select Explore All Users. Then drag the AddVS2008Cmd.bat file to that folder holding Alt key.
4. Set the shortcut to start minimized. This is purely aesthetics. Right-click on the shortcut, select Properties and change the Run property to Minimized.

Please note that the above paths are only applicable if you are running an English language OS and if you have installed VS to the default location. If you are either running an other language OS or have installed VS to a different location you’ll need to update the paths above. Thank you very much Fritz for pointing this out.

That’s all there is to it. I hope you’ll find this as much of a time-saver as I have.

I’ve just found out that all the sessions of the Professional Developers Conference (PDC) 2008 that took place end of Oktober are available on Channel9. Sadly, I wasn’t able to attend but this makes up for a lot!

The videos can be found here: http://channel9.msdn.com/pdc2008/. Also, keep an eye on the official PDC website here: http://www.microsoftpdc.com/.

Enjoy!

There is an -imho-  disturbing tendency amongst developers when it comes to applying coding and style standards, unit testing, duplication analysis and the like. The typical mindset seems to be “if my colleagues don’t do it, I won’t, either”. I know, I’ve been there as well. In fact, I am still there. But if you consider that most, if not all, of the tools we use for the abovementioned tasks can run perfectly fine on any workstation, why not set up a NAnt script? Or even your own local buildserver? The benefits seem obvious but for completeness’ sake, here are a few:

• Creating and running Unit Tests allow you to be more confident in the quality of your code and therfor more productive. In addition, if your colleague changes anything, you will be able to catch possible errors before getting slowed down by them at a later stage.
• Running analysis tools and acting upon their results will guide your development effort so you produce cleaner, leaner and better code.
• Running integration tests before you check anything in will cause fewer merge conflicts and fewer errors caused by your code.

In conclusion, the code you check in will be of higher quality, practically bug-free and unobstrusive (that is, your colleagues will barely know it’s there..not from errors popping up anyway).

Chances are high that your efforts (or lack thereof, as you tend to spend far less time in fixing bugs) will be noticed. If your colleagues ask, give them your most enticing smile as you fire up your favorite browser and show them the build and analysis reports you create. Bask in the glory, enjoy the admiration.

Then, get everyone else to do it.

Personally, I have taken up the task of following my own advice by setting up a build and reporting “server” on my own workstation. If there will be any “broken windows” in the codebase, they won’t be my fault. Mostly.

Erik

P.S. The “broken windows” reference comes from the excellent book The Pragmatic Programmer by Andy Hunt and Dave Thomas. Yes, this is a blatant advertisement, but the book is more than worth it’s cost. It’s changed the way I look at software development and I’d strongly suggest getting your own copy.

For an internal project we were creating a number of custom List Definitions by editing the schema.xml files. When we opened an instance of the List Definition in SharePoint, the fields we had added did not show up in the View, New and Edit forms. Only the Title field was visible.

As it turned out, the schema.xml file contained the following xml:

<List xmlns:ows="Microsoft SharePoint" ... >
  <MetaData>
   <ContentTypes>
      <ContentTypeRef ID="0x01">
        <Folder TargetName="Item" />
      </ContentTypeRef>
      <ContentTypeRef ID="0x0120" />
    </ContentTypes>
  ...

According to Microsoft, the ContentTypeRef element “specifies a reference to a content type to associate with lists that are created through the list definition”. In this case the Content Types are Item and Folder. For a list of the default Content Types included in Windows SharePoint Services 3.0, and their content type IDs, see here. For some more information on Content Types, see the Introduction to Content Types in the MSDN Library.

Obviously (in retrospect) the Item and Folder Content Types do not contain our custom Fields, only the Title Field. Removing the ContentTypes element altogether solved the problem and made all Fields visible in the View, New and Edit forms.

Hope this helps.

Sometimes you discover a little gem that you just know you will be using over and over again. My latest discovery is implicit type conversion. Implicit type conversion basically allows you to convert any object to any other type. Note that not all conversions make sense.

As an example, let’s assume the following Field and FieldList classes:

public class Field<T>
{
  public string InternalName { get; set; }
  public string DisplayName { get; set; }
  public T Value { get; set; }
 
  public Field(string name, string displayName, T value) 
  {
    this.InternalName = name;
    this.DisplayName = displayName;
    this.Value= value;
  }
}
 
public abstract class FieldList
{
  public static readonly Field<string> Title = new Field<string>( "Title", "Title", "An Example" );
  // ... and so on  
}

Somewhere in your application, you are basing the flow of your logic on whether the internal name of a field matched the Title field:

string internalName = "Title";
if ( internalName == FieldsList.Title )
{
  // ...
}

However, this will not compile with the error: Operator ‘==’ cannot be applied to operands of type ‘string’ and ‘ExampleApp.Field‘. A solution would be to change the code as follows:

if ( internalName == FieldsList.Title.ToString() )

But that’s pretty ugly. Implicit type conversion to the rescue.

What we want is for the Field type to be able to behave as a string. Adding the following code to the Field class will do just that:

public static implicit operator string( Field<T> f )
{
  return f.InternalName;
}

What this tells the compiler is that “if there is a need to convert the type Field to string, use the InternalName property”. Now your code will compile.

The following code will also work:

Field<string> f = new Field<string>( "Title", "Title", "An Example" );
Console.WriteLine( f );

Something interesting happens when we use formatting strings. Let’s execute the following code:

Field<string> f = new Field<string>( "Title", "Title", "An Example" );
Console.WriteLine( "The title is: {0}", f );

This will not print ‘Title’ as you would expect. Instead, it outputs ‘ExampleApp.Field`1[System.String]‘. So in this case, we’ll need to override the ToString() method:

public override string ToString()
{
  return this; // Invokes implicit type conversion
}

Now everything works exactly as we’d expect it to.

Today I passed the 70-528 TS: Microsoft .NET Framework 2.0 – Web-Based Client Development exam. One more step towards my MCPD: Enterprise Application Developer certification

Recently I’ve been working a lot with the SharePoint standard templates. A client wanted us to build a Web Part that had the look and feel of a standard SharePoint Web Part and the easiest way to achieve that was using templates. Using these, we didn’t have to worry about custom fields, save buttons, validation and all the other goodness that SharePoint has to offer.

The project was progressing nicely. We inherited from some of the standard SharePoint controls to extend their behavior, like the Save button. Everything worked absolutely fine until we send the first version of the Web Part to our customer. Within a few hours a response came back; the Web Part did not work. Attached to the bug report was a screenshot with the “error message”: a NullReference exception. If there’s any exception I hate with all that is in me it is this one. It just doesn’t provide any information at all about what went wrong. Is it truly that hard to tell me just which object was null?

Anyway, it took us a while to figure out that the customer was using a Dutch language pack, and this was what was tripping up our Web Part. If he installed it on an English instance of SharePoint everything worked fine. Weird. We weren’t using any localization that was not part of the standard SharePoint template we had used as the basis of our work (for those interested, we used the UserListForm).

I will spare you the gory details of what we went through trying to figure out what was wrong. Eventually I simply started commenting out every control in our custom template one by one. If the error went away, I would have found the culprit. Crude, but it worked. The fault turned out to be in a single line of the template:

<SharePoint:CompositeField FieldName="Name" ControlMode="Display" runat="server" />

The why was just as elusive. The template used by the CompositeField didn’t lead us anywhere, nor did .NET Reflector‘s help in looking at the source code. Again, we were mystified.

Until inspiration struck. Looking at the line of code I started wondering why there was a hard reference to a field called “Name” in there. Usually, these keys are put into resource files so a different language can use a localized version of the key. So I figured I’d give it a try. I changed “Name” to “Naam” (which is the Dutch translation). And lo behold! The Web Part worked in the Dutch instance of SharePoint and crashed gloriously in the English instance, giving us the exact same error. For kicks, we installed the French language pack and changed the key to “Nom”. Same result.

The solution to the problem was surprisingly easy. We changed the above line to:

<SharePoint:CompositeField FieldName="<%$Resources:wss,viewlsts_title%>" ControlMode="Display" runat="server" />

The choice of the viewlsts_title was somewhat arbitrary (you’d be surprised how many resource keys have the value “Name”) but it seemed the most appropriate. After this, the Web Part worked great in any language we threw at it.

I still don’t know if this is a bug in the SharePoint code or in the language packs, or anywhere else. I do hope that our explorations will spare you the same.

In his excellent post on How SharePoint 2007 Renders Its Content Geoff McElhanon shows how to programmatically load SharePoint-based templates. The code he shows us is as follows:

1
2
3
4
5
6
7

// Initialize template container with our custom template
templateContainer = new TemplateContainer();
templateContainer.Template = 
    SPControlTemplateManager.GetTemplateByName(RenderingTemplateId);
 
// Add the container to the webpart control hierarchy
Controls.Add(templateContainer);

However, I ran into a problem when I tried to load in a custom template of my own. The default location SharePoint searches in when you provide it with a template ID is C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES. My template was deployed in a subdirectory of this folder and although SharePoint is set to look in those as well, for some yet-to-be-defined reason it didn’t. So I needed an alternative. The solution is not rocket science but it did take me a while to figure it out:

1
2
3
4
5
6
7
8

// Initialize template container
templateContainer = new TemplateContainer();
Control ctl =
    (Control)Page.LoadControl( "~/_controltemplates/MyControlTemplates/MyControlTemplate.ascx" );
templateContainer.Template = ((RenderingTemplate)ctl.Controls[0]).Template;
 
// Add the container to the webpart control hierarchy
Controls.Add(templateContainer);

I hope this helps you out.