At work we are currently developing a suite of applications that are expected to work on Windows XP and, I assume, eventually Windows Vista. The entire development team refreshed their workstations just after Vista went RTM and was available to MSDN subscribers. At the time Visual Studio 2005 wasn't fully supported in Vista and there were too many unknowns so an executive decision was made to stay with XP on the dev machines. I feel it was the right decision at the time.

However, there was one particular reason for staying with XP that I wasn't sure I could agree with. There was a concern that by developing under Vista we might lose touch with XP and find ourselves developing a product that has accidentally used facilities only available in Vista or that differ in Vista. The result, of course, is that we may lose compatibility with XP and discover the problem too late in development to solve it without large time, effort, or cost consequences.

I have decided to use my blog as a place of discussion for reasons why this concern is, or is not, valid. My bias is that the concern is unnecessary but I invite comments on anything I haven't considered.

Acceptance Testing

For each iteration of a product that we produce it goes to our testers to find bugs and usability issues before it can be considering for release. Our testers utilise a clean Windows XP environment inside Virtual PC to perform the suite of tests against the product. Any problems in our software that are specific to XP should be picked up here.

Visual Studio Limitations

Visual Studio 2005 was released well before Windows Vista was close to completion. As a result the IDE itself is not aware of any new features in Vista. In fact, it doesn't even fully support all the features introduced in Windows XP, one aspect that comes to mind is correct rendering of 32-bit icons. Any Vista specific features that are used will have be done so explicitly and presumably with prior consideration.

Framework 3.0

The new .NET Framework 3.0 features are included out of the box in Vista. Updates have been released for Visual Studio 2005 to provide project items and designers for the new WPF, WCF, and WWF components. However, just as we need to ensure that our XP clients need to install .NET Framework 2.0, version 3.0 is supported on XP and Server 2003, and is redistributable via the same methods as 2.0.

Features Lost

One of the primary focuses of Windows Vista has been to improve security. Many popular applications have required (or still require) an update to support Vista due to a change in the operating system's default behaviour. I believe there is a greater risk of utilising a Windows XP feature that will break under Vista because security has been tightened or the feature has been removed altogether (anyone still using WinHelp?).

Practice

With these points in mind I am in the process of building a Vista 64-bit development machine for the home office. With this configuration I intend to experience first hand what issues there are in terms of application compatibility and problems with the development process itself. Anything I find along the way that supports or disproves my beliefs above will help to decide when the development team should migrate to Vista, if at all.

If you have any experiences yourself with this situation I would appreciate your input.

Accessing a Form from inside a Component is surprisingly convoluted in the .NET Framework. I created a new class that inherits from Component that would provide extra functionality to any Form I dropped it on. Ideally, it would search it's parent Form for various types of controls and add handlers to certain control events to provide special behaviour. Unfortunately, neither the Component.Site or .Container properties provide access to the parent Form or ContainerControl.

Some of the components included with the Framework are interacting with their parents so I know it's possible. I dropped a ErrorProvider onto a new Form and checked the designer code to see how it was instantiated. I then opened up Reflector, headed directly for the ErrorProvider component and followed this rather bizarre code path:

1. The designer code creates a private member "components" initialised as a new ComponentModel.Container.  
2. It then creates the ErrorProvider passing the new Container to its constructor.  
3. The ErrorProvider constructor simply calls the Container.Add method passing itself.  
4. The Container.Add method (the trick bit), after extensive validation and array sizing, creates a new ComponentModel.Site and assigns it to the (ErrorProvider) component's Site property.  
5. The ErrorProvider.Site property stores a reference to the incoming Site then proceeds to request a ComponentModel.Design.IDesignerHost via a call to Site.GetService.  
6. The ErrorProvider then retrieves the IDesignerHost.RootComponent property, casts it to a ContainerControl and assigns the value to it's own public ContainerControl property.  
7. The designer then serializes the value of this property to the designer code of the parent Form as "Me.ErrorProvider1.ContainerControl = Me".

The ErrorProvider, and probably many other components included with the Framework, use the behaviour of the designer's code generator to ensure it will have access to it's container at run-time. This feels tightly-coupled yet fragile all at the same time with these odd interdependencies.

Sadly, a Component cannot find trace its roots any other way, so my custom component was forced to borrow this ugly technique. Like the ErrorProvider, my component too must be instantiated differently if created programmatically instead of in the Visual Studio designer.

At least now I, and hopefully you, understand how the Component, Site, and Container classes interact with each other and if you want to access the Form from your own Component, know you can.