Say Goodbye to Courier New within Visual Studio 2005

Tired of using the age old Courier New font for coding, well Microsoft now provides a new Consolas font which installs itself as the default font within Visual Studio 2005.


Sean Laberee within the Visual Studio Editor’s blog, cautions that the Consolas font will only look good if you have ClearType enabled. Using the Appearance Tab of the Display applet within the Windows Control Panel you need to ensure that the check box “Use the following method to smooth edges of screen fonts” is checked and that it is set to Clear Type.


Just when you thought C# couldn’t look any better…


 

WinHEC 2006 – Windows Vista Beta 2 and Office 2007 Beta 2

At the Microsoft WinHEC 2006 conference in Seattle today, Microsoft announced the release of the Beta 2 milestone binaries for both Windows Vista (Build 5384), Windows “Longhorn” Server (Build 5384), and Office 2007.


As I write this blog entry I’m downloading these binaries and will blog about the quality of these builds once I have had a chance to install them in the next day or so. One thing to note if you’re planning on testing Windows Vista on an x64 platform you’ll need a DVD burner capable of burning dual layer 8Gb DVD’s as the .iso image for the x64 platform is just a touch above the 4.7Gb limit on conventional DVD’s.


Update May 24, 2006 – NVIDIA GeForce Go 7800 Device Driver Problems


I successfully downloaded both the 32-bit and 64-bit versions of Windows Vista Beta 2 last night and today installed the 32-bit version on my Dell Inspiron 9400 laptop which is equipped with the NVIDIA GeForce Go 7800 graphics card. The graphics driver for this device still causes the blue screen of death when I attempt to refresh the performance rating or run any application that uses the more impressive graphics characteristics of Windows Vista such as the new chess application. While I’m sure that NVIDIA will resolve these issues before Windows Vista RTM (release to manufacturing) I would have certainly liked these problems to have been solved for the Beta 2 milestone.


I’ll therefore post some screenshots of Windows Vista Beta 2 and Office 2007 Beta 2 using my workstation that uses an ATI graphics card instead, these should be available sometime on May 25th 2006.


Update May 25, 2006 – Windows Server “Longhorn” Beta 2 Does Not Support Dual Booting Windows Vista Beta 2


So last night I installed Windows Vista Beta 2 and Office 2007 Beta 2 and life was being fairly good to me until I decided that I would install Windows Server “Longhorn” Beta 2 onto the second hard drive within the workstation; unfortunately Windows Server “Longhorn” Beta 2 never presents me with a boot menu to enable me to get back to the Windows Vista Beta 2 installation. If anyone reading this knows how to customize the boot loader such that I can see both operating systems when I turn on the machine please e-mail me through this blog and let me know how to do this.


As such the screenshots that I’d previously promised will be slightly delayed while I resolve these issues.

To Interface or not to Interface, that is the Question

As an architect on a software project being developed using C# 2.0 the client is asking me to provide them a definition on when "to interface, or not to interface…" and although they are looking for a non-technical definition, I thought that a more technical discussion would make a good blog posting.

All to often, books on C# and other programming languages simply describe language constructs and how to use them, but it is less often that you find a discussion on when a particular language construct is appropriate or not. Although I had some ideas of my own as to when it is appropriate to use an interface and when it is appropriate to use an abstract base class I decided to first ask some fellow MVP's and C# authors their opinions on the subject.

Within this posting I'll now distill some of my own thoughts with the additional thoughts of those MVP's and authors who were nice enough to reply to me within the private MVP newsgroups.

In the book CLR via C# by Jeffrey Richter he provides some guidance on when to design using an interface and when to prefer an abstract base class. Within .net a type can inherit only one base implementation, although it can specify multiple interfaces that the type realizes. Jeffrey Richter says that interfaces imply a "CAN-DO" relationship, others would say that interfaces describe behavior, such as a types ability to convert instances of itself to another type, provided by the IConvertible interface. Another example would be a types ability to serialize itself through the ISerializable interface.

Abstract base classes on the other hand provide a developer with an easer path to creating new types rather than having to provide implementations for all the methods specified within an interface. Within the .net framework the abstract base class Stream provides the basis for several derived types within the BCL such as the FileStream, MemoryStream, and NetworkStream. Within the following Visual Studio class diagram we see the fact that these derived types all inherit their base functionality from the abstract base class.

Collections within the .net base class library, on the other hand, are implemented using interfaces such as the ICollection, IDictionaryIEnumerable interfaces and their generic counterparts within the System.Collections.Generic namespace. Using interfaces within the collections namespaces allowed Microsoft to describe the behavioral traits of the collections which are common to many collection types; abstract base classes would not have provided substantial benefit here because there really isn't a lot of common code betwen the List<T>, Dictionary<K, V>, and Queue<T>.

Within the .net framework Microsoft then provides default implementations of many of these interfaces such as the List<T> and Dictionary<K, V> classes. When designing frameworks with interface inheritance such the collection interfaces discussed here, it provides developers with substantial flexibility to provide these default implementations that can either be used themselves or can provide the basis for other, more specialized collections. If the default implementation of the Dictionary<K, V> class was not provided by Microsoft then you'd have to provide implementations for several different interfaces to enable any specialized dictionary to mimic the behavior of the default implementation. Another important benefit from providing default implementations, whether abstract or not, is that it enables developers to extend the default implementation in such a way that any derived types are also subsequently extended. Compare this with the nightmare situation where an additional behavior is added to an interface and every type implementing the interface must now provide an implementation of the additional behavior.

It therefore makes sense often to provide both an interface, to describe the behavioral characteristics, and an abstract base class that can serve as the basis for a familiy of types. IBusinessObject in the following class diagram defines the common behavior of business objects and the abstract base class BusinessObjectBase provides the default implementations of some of this behavior such as the implementation of the ICloneable interface. An example of this within the .net framework base class library can be found within the System.CodeDom namespace where the ICodeGenerator interface is realized by the abstract base class CodeGenerator.

Providing an interface for business objects that themselves inherit from the abstract base class BusinessObjectBase also provides an additional benefit in that client code needing an instance of the Person class, for example, could call a Factory to create an instance of the Person class on an application server but return it to the client code as an IPerson. Using the Factory design pattern in this way enables you to deploy only the shared assemblies that provide the interfaces and not the actual implementation of those interfaces which then solely resides upon the application server.

Unless you're planning on distributing the application across machine boundaries like this then the simplest answer would be to provide interfaces when you have an object that "does something" (e.g. describes behavior) and use a standard class with an abstract base class between it and the base interface when the object "is something".

Of course most of the applications I can forsee architecting and developing in the coming months will use a distributed architecture so providing interfaces for specific business objects (e.g. those classes exhibiting an "is a" relationship) will enable a simplified deployment and change management process once the applications are in production; however this does have the potential to complicate the development phase of the project when it may be unclear as to what a particular business object will ultimately look like. It therefore may or may not be appropriate to provide interfaces for all business objects based upon several factors including the required pace of the project schedule and how well the requirements of the software have been documented.

Unfortunately distilling the rules as to when to use an interface, or an abstract base class, or both, is complicated and often even the most experianced object-oriented designers will differ in their opinion whether to use an interface or an abstract base class. In the early versions Visual Studio Whidbey, now Visual Studio 2005, the ProviderBase class was in fact an interface. Microsoft then determined that an abstract base class would serve .net developers better and hence the IProvider interface is now a mere fragment of history.

Interfaces also enable developers to force a separation between the behavior of an object and its actual implementation. Within the C# programming language, among others, interfaces can be implemented either implicitly or explicitly. ICloneable is implemented implicitly within the abstract base class BusinessObjectBase. Implementing an interface implicitly allows developers to use the implementation without first casting an object instance to the particular interface.


   
public object Clone()
    {
       
try
        {
           
object clone = null;

            using (MemoryStream buffer = new MemoryStream())
            {
                BinaryFormatter formatter =
new BinaryFormatter();

                // serialize the business object into the memory stream buffer.
                formatter.Serialize(buffer, this);

                // set the current position of the memory stream to the beginning of the buffer.
                buffer.Position = 0;

                // deserialize the memory stream representation of the object.
                clone = formatter.Deserialize(buffer);

            } // MemoryStream.Dispose() ~ called automatically

            // return the cloned business object.
            return clone;
        }
       
catch (Exception ex)
        {
            IIdentity identity = WindowsIdentity.GetCurrent()
as IIdentity;
            ExceptionProvider.Publish(ex, identity);

            return null;
        }
    }

Interfaces can also be implemented explicitly, forcing developers to use the abstraction of the behavior provided by the interface rather than calling the members of the interface directly and this is illustrated in the following class diagram. BusinessObjectManager is an object that manages the communication between the business logic layer and the data access layer through the explicit realization of the IBusinessObjectManager interface. Using this framework a developer never actually gets an instance of the BusinessObjectManager class because it is adorned with the internal visibility modifier, meaning it can only be accessed within the assembly that it resides. Using explicit interface realization provides the author of such components with a great deal of freedom to change the underlying implementation without affecting any code that uses the component so long as they do not change the contract that the component observes through the realization of the interface.

In the C# programming language, explicit implementation of an interface is done by prepending the interface name to each member of the interface within the type realizing the interface. We therefore refer to the Principal property as IBusinessObjectManager.Principal rather than simply Principal and IBusinessObjectManager.SelectCollection rather than merely SelectCollection. In the C# programming language, when explicitly implementing interfaces it is not permissible to provide visibility modifiers and therefore doing so will cause compilation errors. In the code below the implementation of the interface members is not provided as each member requires a significant amount of code that would simply distract from this discussion.

    public sealed class BusinessObjectManager : MarshalByRefObject, IBusinessObjectManager
    {
        
IPrincipal IBusinessObjectManager.Principal
        {
            
get
            {
            }
            
set
            {
            }
        }

        IBusinessObject IBusinessObjectManager.SelectInstance(ICriteria criteria)
        {
        }

        System.Collections.IList IBusinessObjectManager.SelectCollection(ICriteria criteria)
        {
        }

        IBusinessObject IBusinessObjectManager.UpdateInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(ICriteria criteria)
        {
        }
    }

I hope this has provided some insight into when to interface, and when not to interface, afterall that is the question that inspired this posting.


Interfaces can also be implemented explicitly, forcing developers to use the abstraction of the behavior provided by the interface rather than calling the members of the interface directly and this is illustrated in the following class diagram. BusinessObjectManager is an object that manages the communication between the business logic layer and the data access layer through the explicit realization of the IBusinessObjectManager interface. Using this framework a developer never actually gets an instance of the BusinessObjectManager class because it is adorned with the internal visibility modifier, meaning it can only be accessed within the assembly that it resides. Using explicit interface realization provides the author of such components with a great deal of freedom to change the underlying implementation without affecting any code that uses the component so long as they do not change the contract that the component observes through the realization of the interface.

In the C# programming language, explicit implementation of an interface is done by prepending the interface name to each member of the interface within the type realizing the interface. We therefore refer to the Principal property as IBusinessObjectManager.Principal rather than simply Principal and IBusinessObjectManager.SelectCollection rather than merely SelectCollection. In the C# programming language, when explicitly implementing interfaces it is not permissible to provide visibility modifiers and therefore doing so will cause compilation errors. In the code below the implementation of the interface members is not provided as each member requires a significant amount of code that would simply distract from this discussion.

    public sealed class BusinessObjectManager : MarshalByRefObject, IBusinessObjectManager
    {
        
IPrincipal IBusinessObjectManager.Principal
        {
            
get
            {
            }
            
set
            {
            }
        }

        IBusinessObject IBusinessObjectManager.SelectInstance(ICriteria criteria)
        {
        }

        System.Collections.IList IBusinessObjectManager.SelectCollection(ICriteria criteria)
        {
        }

        IBusinessObject IBusinessObjectManager.UpdateInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(ICriteria criteria)
        {
        }
    }

I hope this has provided some insight into when to interface, and when not to interface, afterall that is the question that inspired this posting.


Interfaces can also be implemented explicitly, forcing developers to use the abstraction of the behavior provided by the interface rather than calling the members of the interface directly and this is illustrated in the following class diagram. BusinessObjectManager is an object that manages the communication between the business logic layer and the data access layer through the explicit realization of the IBusinessObjectManager interface. Using this framework a developer never actually gets an instance of the BusinessObjectManager class because it is adorned with the internal visibility modifier, meaning it can only be accessed within the assembly that it resides. Using explicit interface realization provides the author of such components with a great deal of freedom to change the underlying implementation without affecting any code that uses the component so long as they do not change the contract that the component observes through the realization of the interface.

In the C# programming language, explicit implementation of an interface is done by prepending the interface name to each member of the interface within the type realizing the interface. We therefore refer to the Principal property as IBusinessObjectManager.Principal rather than simply Principal and IBusinessObjectManager.SelectCollection rather than merely SelectCollection. In the C# programming language, when explicitly implementing interfaces it is not permissible to provide visibility modifiers and therefore doing so will cause compilation errors. In the code below the implementation of the interface members is not provided as each member requires a significant amount of code that would simply distract from this discussion.

    public sealed class BusinessObjectManager : MarshalByRefObject, IBusinessObjectManager
    {
        
IPrincipal IBusinessObjectManager.Principal
        {
            
get
            {
            }
            
set
            {
            }
        }

        IBusinessObject IBusinessObjectManager.SelectInstance(ICriteria criteria)
        {
        }

        System.Collections.IList IBusinessObjectManager.SelectCollection(ICriteria criteria)
        {
        }

        IBusinessObject IBusinessObjectManager.UpdateInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(ICriteria criteria)
        {
        }
    }

I hope this has provided some insight into when to interface, and when not to interface, afterall that is the question that inspired this posting.


Interfaces can also be implemented explicitly, forcing developers to use the abstraction of the behavior provided by the interface rather than calling the members of the interface directly and this is illustrated in the following class diagram. BusinessObjectManager is an object that manages the communication between the business logic layer and the data access layer through the explicit realization of the IBusinessObjectManager interface. Using this framework a developer never actually gets an instance of the BusinessObjectManager class because it is adorned with the internal visibility modifier, meaning it can only be accessed within the assembly that it resides. Using explicit interface realization provides the author of such components with a great deal of freedom to change the underlying implementation without affecting any code that uses the component so long as they do not change the contract that the component observes through the realization of the interface.

In the C# programming language, explicit implementation of an interface is done by prepending the interface name to each member of the interface within the type realizing the interface. We therefore refer to the Principal property as IBusinessObjectManager.Principal rather than simply Principal and IBusinessObjectManager.SelectCollection rather than merely SelectCollection. In the C# programming language, when explicitly implementing interfaces it is not permissible to provide visibility modifiers and therefore doing so will cause compilation errors. In the code below the implementation of the interface members is not provided as each member requires a significant amount of code that would simply distract from this discussion.

    public sealed class BusinessObjectManager : MarshalByRefObject, IBusinessObjectManager
    {
        
IPrincipal IBusinessObjectManager.Principal
        {
            
get
            {
            }
            
set
            {
            }
        }

        IBusinessObject IBusinessObjectManager.SelectInstance(ICriteria criteria)
        {
        }

        System.Collections.IList IBusinessObjectManager.SelectCollection(ICriteria criteria)
        {
        }

        IBusinessObject IBusinessObjectManager.UpdateInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(ICriteria criteria)
        {
        }
    }

I hope this has provided some insight into when to interface, and when not to interface, afterall that is the question that inspired this posting.


Interfaces can also be implemented explicitly, forcing developers to use the abstraction of the behavior provided by the interface rather than calling the members of the interface directly and this is illustrated in the following class diagram. BusinessObjectManager is an object that manages the communication between the business logic layer and the data access layer through the explicit realization of the IBusinessObjectManager interface. Using this framework a developer never actually gets an instance of the BusinessObjectManager class because it is adorned with the internal visibility modifier, meaning it can only be accessed within the assembly that it resides. Using explicit interface realization provides the author of such components with a great deal of freedom to change the underlying implementation without affecting any code that uses the component so long as they do not change the contract that the component observes through the realization of the interface.



In the C# programming language, explicit implementation of an interface is done by prepending the interface name to each member of the interface within the type realizing the interface. We therefore refer to the Principal property as IBusinessObjectManager.Principal rather than simply Principal and IBusinessObjectManager.SelectCollection rather than merely SelectCollection. In the C# programming language, when explicitly implementing interfaces it is not permissible to provide visibility modifiers and therefore doing so will cause compilation errors. In the code below the implementation of the interface members is not provided as each member requires a significant amount of code that would simply distract from this discussion.

    public sealed class BusinessObjectManager : MarshalByRefObject, IBusinessObjectManager
    {
        
IPrincipal IBusinessObjectManager.Principal
        {
            
get
            {
            }
            
set
            {
            }
        }

        
IBusinessObject IBusinessObjectManager.SelectInstance(ICriteria criteria)
        {
        }

        System.Collections.
IList IBusinessObjectManager.SelectCollection(ICriteria criteria)
        {
        }

        
IBusinessObject IBusinessObjectManager.UpdateInstance(IBusinessObject instance)
        {
        }

        
bool IBusinessObjectManager.DeleteInstance(IBusinessObject instance)
        {
        }

        
bool IBusinessObjectManager.DeleteInstance(ICriteria criteria)
        {
        }
    }

I hope this has provided some insight into when to interface, and when not to interface, afterall that is the question that inspired this posting.

Interfaces can also be implemented explicitly, forcing developers to use the abstraction of the behavior provided by the interface rather than calling the members of the interface directly and this is illustrated in the following class diagram. BusinessObjectManager is an object that manages the communication between the business logic layer and the data access layer through the explicit realization of the IBusinessObjectManager interface. Using this framework a developer never actually gets an instance of the BusinessObjectManager class because it is adorned with the internal visibility modifier, meaning it can only be accessed within the assembly that it resides. Using explicit interface realization provides the author of such components with a great deal of freedom to change the underlying implementation without affecting any code that uses the component so long as they do not change the contract that the component observes through the realization of the interface.

In the C# programming language, explicit implementation of an interface is done by prepending the interface name to each member of the interface within the type realizing the interface. We therefore refer to the Principal property as IBusinessObjectManager.Principal rather than simply Principal and IBusinessObjectManager.SelectCollection rather than merely SelectCollection. In the C# programming language, when explicitly implementing interfaces it is not permissible to provide visibility modifiers and therefore doing so will cause compilation errors. In the code below the implementation of the interface members is not provided as each member requires a significant amount of code that would simply distract from this discussion.

    public sealed class BusinessObjectManager : MarshalByRefObject, IBusinessObjectManager
    {
        
IPrincipal IBusinessObjectManager.Principal
        {
            
get
            {
            }
            
set
            {
            }
        }

        IBusinessObject IBusinessObjectManager.SelectInstance(ICriteria criteria)
        {
        }

        System.Collections.IList IBusinessObjectManager.SelectCollection(ICriteria criteria)
        {
        }

        IBusinessObject IBusinessObjectManager.UpdateInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(IBusinessObject instance)
        {
        }

        bool IBusinessObjectManager.DeleteInstance(ICriteria criteria)
        {
        }
    }

I hope this has provided some insight into when to interface, and when not to interface, afterall that is the question that inspired this posting.

Windows Vista Build 5381

Windows Vista build 5381 was recently released to beta testers and although it is not due to be released as a CTP build on MSDN subscriber downloads, it appears to be one of the best builds of Windows Vista released to date.


Below are several screen shots from the 64-bit version of Windows Vista build 5381 beginning with one showing the new desktop with several windows being tabbed between using the new tabbing feature (Windows Key + Tab), which makes use of the graphics capabilities of Windows Vista assuming you have an appropriate graphics card.




Windows Vista now includes a performance scoring that is intended to help you determine software that will be, or will not be, supported by the hardware upon which Windows Vista is running.



In Windows Vista build 5381 we also can see the improved graphics available in the Minesweeper and Solitaire games along with a new Chess game.