When you try to install SQL Server 2005 Reporting Services on Windows Vista, the installer apparently fails to recognize that IIS7 is installed (assuming that you have installed it). The error message is misleading and is due to the fact that IIS7 components required by Reporting Services are not installed. IIS7 has been much more componentized than IIS6 and there is a magical list of IIS7 features that must be installed in order for Reporting Services to install successfully. The required IIS7 features are documented in KB article 920201.

Component Folder
Static Content Common HTTP Features
Default Document Common HTTP Features
HTTP Redirection Common HTTP Features
Directory Browsing Common HTTP Features
ASP.Net Application Development
ISAPI Extension Application Development
ISAPI Filters Application Development
Windows Authentication Security
IIS Metabase Management Tools
IIS 6 WMI Management Tools

Once you have SQL Server installed, you will need to install SQL Server 2005 SP2 November 2006 CTP or later as it addresses some Vista-compatibility issues. You can find the latest SQL Server 2005 service pack information here. You should now have a working Reporting Services install on Vista.

On a recent project, I was trying to return an object (with child objects) from an ASMX Web Service and was using the XmlSerializer for serialization. (When doing ASMX Web Services, you really have no choice but to use the XmlSerializer.) The child objects contained a circular reference, which ended up being the bane of my existence because the XmlSerializer can’t handle circular references. The XmlSerializer reports, “Circular reference detected” and gives up. It just can’t serialize it. The amount of code (and changes to the domain model) to work around this limitation was just plain stupid, not to mention the subtle bugs that needed to be fixed when object identity wasn’t respected in other areas of the object graph.

So what does this have to do with Windows Communication Foundation (WCF)? Given how excited I’ve been about WCF, my fellow developers (and the PM) asked if WCF would have avoided the XmlSerializer problems that we had experienced. My curiosity was piqued and I had to find out. As it turns out, WCF can handle circular references and preserve object identity. Or more correctly, the DataContractSerializer can. This would have saved me untold effort if I had been able to use WCF on the project. (Unfortunately release dates didn’t match up. Ironically the project released into production the day before WCF went RTM.) Just a pronouncement that WCF can handle circular references wouldn’t make for a very interesting blog entry. The reality is that out-of-the-box, WCF cannot handle circular references even though the DataContractSerializer can. With a bit of digging, I was able to configure WCF to serialize circular references and properly preserve object identity.

Let’s take a deeper look… Consider a simple object graph with a circular reference. The simplest is a parent-child relationship where the child has a back-reference to the parent. (My situation was more complex, but this example suffices.) Here is a Person class, which has a list of Children, as well as a reference to its parent.

[DataContract(Namespace=“http://jameskovacs.com/Examples/WcfCircularRefs”)]

public class PersonDTO {

    [DataMember]

    public string Name {

        get { return m_name; }

        set { m_name = value; }

    }

 

    private string m_name;

    [DataMember(Name=“Parent”)]

    private Person m_parent;

    [DataMember(Name = “Children”)]

    private List<Person> m_children = new List<Person>();

 

    /* Additional constructors/properties/methods elided. */
    /* I’ve also omitted the Order and IsRequired DataMember parameters above. */

    /* Full source can be found in the linked zip file at the end. */

}

<Aside>One of the nice things about the DataContractSerializer is that serialized members are opt-in. If you don’t decorate a member with the [DataMember] attribute, it is not serialized. For instance, m_name is not decorated and is therefore ignored by the DataContractSerializer. This is in stark contrast to the XmlSerializer where all public read/write properties are serialized unless they are marked with [XmlIgnore]. Another point to note is that I can serialize both properties and fields, which allows me to have read-only properties, such as m_parent and m_children, while still serializing them at the field level. (N.B. You can still configure WCF to use the XmlSerializer for compatibility, though the preferred serializer is the DataContractSerializer.)</Aside>

Now why can’t WCF handle circular references out-of-the-box. The reason is that there is no industry-accepted, interoperable way of expressing anything but parent-child relationships in XML. You can use the ID/IDREF feature of XML or the key/keyref feature of XML Schema, but a lot of serializers don’t respect these attributes or handle them properly. So if you want to serialize circular references, you need to stray out of the realm of safe interoperability. I found some very intriguing information in Aaron Skonnard’s MSDN article about the DataContractSerializer, Serialization in Windows Communication Foundation. When instantiating the DataContractSerializer, you can tell it to respect object identity (and thus handle circular references) by passing true for preserveObjectReferences constructor parameter.

DataContractSerializer serializer = new DataContractSerializer(typeof(PersonDTO), null, int.MaxValue, false, true /* preserveObjectReferences */, null);

serializer.WriteObject(memStream, person);

The resulting XML looks like this:

<PersonDTO z:Id=1 xmlns=http://jameskovacs.com/Examples/WcfCircularRefs xmlns:i=http://www.w3.org/2001/XMLSchema-instance xmlns:z=http://schemas.microsoft.com/2003/10/Serialization/>

    <Name z:Id=2>Sam Spade</Name>

    <Parent z:Id=3>

        <Name z:Id=4>Unknown</Name>

        <Parent i:nil=true/>

        <Children z:Id=5 z:Size=0/>

    </Parent>

    <Children z:Id=6 z:Size=2>

        <PersonDTO z:Id=7>

            <Name z:Id=8>Jane Spade</Name>

            <Parent z:Ref=1 i:nil=true/>

            <Children z:Id=9 z:Size=0/>

        </PersonDTO>

        <PersonDTO z:Id=10>

            <Name z:Id=11>Bobby Spoon</Name>

            <Parent z:Ref=1 i:nil=true/>

            <Children z:Id=12 z:Size=0/>

        </PersonDTO>

    </Children>

</PersonDTO>

You’ll notice that references to other objects are encoded using the z:Id attribute. So the DataContractSerializer can handle circular references, but how do we tell WCF to pass true for the preserveObjectReferences parameter when creating a DataContractSerializer? We can’t, but what we can do is do it ourselves and wedge our code into the WCF pipeline. Is that cool or what? All the details can be found in Ingo Rammer’s MSDN Library Article, From .NET Remoting to the Windows Communication Foundation (WCF). We create a class derived from DataContractSerializerOperationBehaviour, which we’ll call PreserveReferencesOperationBehavior. Here’s the important overload:

public override XmlObjectSerializer CreateSerializer(

  Type type, XmlDictionaryString name, XmlDictionaryString ns,

  IList<Type> knownTypes) {

    return new DataContractSerializer(type, name, ns, knownTypes,

        0x7FFF,

        false,

        true /* preserveObjectReferences */,

        null);

}

So we’ve wedged in the preserveObjectReferences = true. We then create an attribute, PreserveReferencesAttribute, which implements IOperationBehavior, to inject the PreserveReferencesOperationBehavior.

public void ApplyDispatchBehavior(OperationDescription description,

  DispatchOperation dispatch) {

    IOperationBehavior innerBehavior =

      new PreserveReferencesOperationBehavior(description);

    innerBehavior.ApplyDispatchBehavior(description, dispatch);

}

Finally, we apply this attribute to the OperationContract in our ServiceContract.

[ServiceContract(Namespace=“http://jameskovacs.com/Examples/WcfCircularRefs”)]

public interface IPersonService {

    [OperationContract]

    [PreserveReferences]

    PersonDTO GetDefaultPerson();

}

Our service is now able to serialize circular references, as well as preserve object identity. If we need to transmit objects with circular references back to the service, we could make similar changes to inject PreserveReferencesOperationBehavior into the client-side proxy.

To summarize, WCF is a very extensible framework for distributed communication. We were able to make some small modifications to the WCF pipeline that allowed us to return an object graph with circular references from a service. With the release of WCF, the life of the distributed application developer just got a whole lot easier. Full source code can be found here (16 KB).

N.B. The HTTP transport in WCF relies on http.sys for hosting HTTP ports outside of IIS. Opening up arbitrary HTTP ports cannot be done by non-admins unless they have been granted permission by an administrator. This means an administrator must run httpcfg to grant non-admin users permission to open these ports.

The .NET Framework 3.0, formerly known as WinFx, has gone gold. You can download the release bits now. Congrats to everyone involved in this release!

If you have a previous version installed (CTP or Beta), you’ll want to read the uninstall instructions found below the download link for the uninstall tool. (The uninstall tool is there in case Add/Remove Programs fails in a horrible way.)

I am now a card-carrying member of the MSDN Canada Speakers Bureau*. (OK, maybe they don’t issue cards, but it’s still a great honour.) The long and short of it is that user groups from across Canada can invite me to speak and Microsoft Canada will cover the expenses.

Here are some possible topics:

  • Enterprise Architecture for Mere Mortals: Authentication
    • Discussing advantages/disadvantages of different authentication models and how to make them work, including trusted subsystem, full delegation, constrained delegation, and protocol transition.
  • Tools of the Trade: Must-Have .NET Utilities
    • An overview of .NET tools that should be in your toolbox.
  • ASP.NET Kung-Fu: Advanced Techniques and Idioms
    • Solving problems in ASP.NET using techniques such as HttpHandlers and HttpModules.
  • Introducing Windows CardSpace
    • Looking at the technology, its architecture, and why you should care.

I’ll be adding more presentations in the coming months. So if you are looking for someone to present on a particular topic, don’t hesitate to ask. I might have something in my back pocket…

* Please note that the public page is horribly out-of-date. Some people have incorrect information. Others, such as Jean-Paul Boodhoo, are not yet listed. User Group leaders have up-to-date information on all speakers. Talk to them about inviting one of us to come speak at your user group.

BTW – If you’re looking for a fantastic presenter to talk about TDD, Agile, and patterns, I would highly recommend inviting Jean-Paul out to your user group.

A few months ago, Joanne Cummings of Redmond Magazine interviewed me regarding my thoughts on Microsoft Virtual PC and how it compares to VMWare Workstation. The article was recently published and you can find it here. Joanne did a good job capturing my thoughts on the overall advantages and disadvantages of the two products. While I’m overall quite favourable toward Microsoft software (I honestly think Microsoft does a good job in most cases and a great job in many), desktop-based virtualization is one area where they fall short. Read the article to find out more. Thanks, Joanne, for the opportunity to share my thoughts on VPC and VMWare.

Show Notes

I must bid a fond farewell to a fellow plumber, Dan Sellers. Today was Dan’s last day in the Big House. He is stepping into a well-deserved, early retirement. Dan and I have worked together many times over the years especially on Plumbers @ Work and more recently on the Canadian Developer Security Virtual Team. (I’ve got some posts and content coming up soon.) The developer scene in Canada will not be the same without him. Congratulations, Dan. You’ll be missed.

Finally published. You can grab it here.

Show Notes

  • Introduction
  • NDoc and Sandcastle
  • CodePlex
  • CTPs and You
  • www.netfx3.com
  • Charging for Office 2007 Downloads
  • Virtual PC is Free
  • TFS Administration Tool & TF Sidekicks
  • SharePointKicks.com
  • Microsoft Acquires Sysinternals
  • Windows Vista, Build 5472 Available
  • Security and Windows Vista
  • BlackHat Conference
  • Edmonton Code Camp
  • Upcoming MSDN Events

Comments, as always, are welcome here

When I went independent, I bought a developer-grade desktop box based around the AMD Athlon64 X2 4800+. (I built the computer myself from components purchased at MemoryExpress. Highly, highly recommended. These guys know their stuff when it comes to hardware.) The CPU is a fantastic dual-core 64-bit chip. With a 64-bit chip, I figured that I might as well run Windows XP Pro x64 Edition. Overall it’s a been a pleasant experience. Software and driver support has been excellent for 64-bit Windows. I was able to get 64-bit drivers for everything, including the sound card – a Creative Sound Blaster X-Fi Platinum. The one downside was no 64-bit driver for my Logitech QuickCam Orbit MP. The webcam works great on my Centrino-based laptop (32-bit Windows). I bought a Logitech webcam because Logitech is a well-known company and has 64-bit support for their mice, keyboards, and even joysticks. I figured that they would support 64-bit Windows for their webcams too. Anyway, I have given up waiting for Logitech to provide a 64-bit driver and bought a Microsoft LifeCam Vx-6000, which was just released and supports 64-bit Windows. Very nice, high-res webcam and very inexpensive.

Most 32-bit applications run unaltered on 64-bit Windows thanks to the WoW layer – Windows on Windows. WoW provides a 32-bit to 64-bit translation layer for system calls. Amusingly, the 64-bit Windows DLLs live in c:\Windows\System32. The 32-bit DLLs live in c:\Windows\SysWOW64. There are a few problem areas to watch out for. Although WoW allows 32-bit programs to run on 64-bit Windows, you cannot run 32-bit DLLs in a 64-bit process. For example, Explorer Shell Extensions (such as TortoiseSVN or HardLinkShellExt) must be compiled for 64-bit, otherwise they won’t work. (You can always run a 32-bit version of Explorer to get to your 32-bit extensions.) Same thing with Internet Explorer, which is available on Win64 as both 32-bit and 64-bit. WoW works by intercepting 32-bit system calls (like a Win32 CreateFile) and translating them into their 64-bit equivalent. Drivers however run in the kernel. There is no interception layer to translate between 32-bit and 64-bit system calls. This is why you need native 64-bit drivers.

Advantages

So what are the advantages of 64-bit Windows?

IIS6 – XP Pro x64 is actually derived from the Windows Server 2003 codebase with relevant portions of Win XP ported over. This is a big plus for ASP.NET and web services developers, who will be deploying to Windows Server 2003. Running IIS6 puts you much closer to your intended deployment environment, including having your applications run under the Network Service account rather than ASPNET.

Potentially Improved Performance – Applications that do a lot of 64-bit integer arithmetic run faster when compiled for 64-bit. (e.g. Half-Life 2) If the application is compiled for the .NET Framework 2.0 using “Any CPU” (the default), it will automatically run on the 64-bit Framework and gain the performance improvement without requiring a re-compilation. (e.g. Paint .NET) If an application does not use very much 64-bit math and is recompiled for 64-bit, it could actually run slower because your pointers are all 64-bit and thus take up more space in your CPU caches. This is generally not a problem and if it became a problem, you could always run the 32-bit compiled version on XP Pro x64 via WoW64.

Larger Memory Space – This is probably the biggest bonus for developers. Each process is no longer limited to 4 GB of virtual memory. If you want to haul 100 GB of data into memory (and you’ve got the physical memory to back it up), you can do it. Crazy stuff, but possible if you’re writing crazy apps. Another advantage is, once mainstream motherboards support greater than 4 GB of physical RAM, we will be able to run more and larger virtual machines.

Disadvantages

So what are the disadvantages of 64-bit Windows?

Drivers

Although driver support is very good for new hardware, older hardware is more of a challenge. Most notable in this area is printers. A lot of printers simply lack 64-bit drivers and the printer vendors seem uninterested in writing 64-bit drivers for discontinued products. Hopefully Microsoft will step in and plug this gap. Until then, you have to be careful about which printers you buy. Also note that even a network printer requires a locally installed printer driver. So you won’t be able to print to any printer that doesn’t have a 64-bit driver. This sucks big time.

Less Testing Done

XP Pro x64 is much less common than the ubiquitous XP Home/Pro. So software/hardware vendors are doing less (or no) testing on XP Pro x64. Although the WoW64 layer is excellent, it is by no means bulletproof. For example, Office 2007 RC1 had a problem where the old-style window border would bleed through. For whatever reason, Office 2007 RC1 wasn’t always properly refreshing the top invalidated window border on XP Pro x64. I never saw this problem on 32-bit XP Pro. Since the Technical Refresh (RC1TC), I haven’t seen this problem on XP Pro x64 either. Another example is Windows Live Messenger. On x64, there is a spurious line through the icons beside your photo. Minor visual glitch, but livable.

Unsupported Software

There are some applications that cannot run on XP Pro x64 because they integrate too tightly with the OS. Examples include:

Windows Live OneCare: Currently only supports 32-bit OSs. Hopefully Microsoft releases a 64-bit enabled version soon. Windows Desktop Search was in this category for awhile, but Microsoft released a 64-bit version not too long ago.

Virus scanners: Support for XP Pro x64 is a bit spotty with anti-virus vendors (including OneCare above). Anti-virus is available for XP Pro x64, but typically from the smaller (though reputable) players in the field, rather than from the large well-known names.

Virtualization: Microsoft Virtual PC 2004 does not run on XP Pro x64. Microsoft Virtual PC 2007, which is not yet available, will support XP Pro x64 as a host, though not as a guest. You can always run Virtual Server 2005 R2, which supports 64-bit hosts. Unfortunately the UI is web-based and not ideal for desktop use. (i.e. You can’t drag & drop and you can’t share your clipboard. Adding new devices or mounting ISOs is very cumbersome.) If you don’t mind paying for software, VMWare Workstation is the way to go. It supports 64-bit hosts and guests and has better virtual networking, USB, and snapshotting support.

Conclusion

Do I regret installing and running XP Pro x64? Absolutely not. It’s a great OS and it works well as my primary OS. On the other hand, I’m glad that I’ve still got 32-bit XP Pro running on my laptop as there have been times (mostly wanting to print) when XP Pro x64 just couldn’t do it. Running XP Pro x64 has also been a good experience for development as I’ve learned the intricacies of the 64-bit Windows OSs. Would I recommend XP Pro x64 (or Windows Vista x64 for that matter) to a friend? It all depends on what they’re planning to do. If they’re a developer and don’t mind the odd incompatibility, absolutely. I think it’s a great OS. For your average person, I don’t think that 64-bit OSs are quite ready for prime time. Although software and driver support is very good, it’s still not as good as 32-bit Windows.

My fellow plumber, TechEd roomie, and Notepad MVP, Bil Simser will be talking about Windows SharePoint Services (WSS) 3.0 at the Calgary .NET User Group on Tuesday, October 17, 2006 from 5 to 8pm. Full details and registration can be found here. If you want to find out what’s new and cool in SharePoint Land, Bil’s the man to talk to!