Category Archives: 2106

CodePlex Project – CSharpDistilled.Diagnostics 1.0.0.3


You’ve probably noticed that it has been a few weeks since my last blog posting here and that is largely due to the fact that I’ve been working on a open source project called CSharpDistilled.Diagnostics.


While at Microsoft TechEd this year I got talking to the folks at the CodePlex area about the exciting things they were doing with exposing Microsoft Team Foundation Server through the Web for open source projects.


Uploaded tonight, is the first version of the CSharpDistilled.Diagnostics framework which includes the main C# library project, unit testing project, database project, and associated setup project. Although you’ll need Visual Studio 2005 Team Developer or Team Suite to use the unit testing project.


CSharpDistilled.Diagnostics introduces a new framework for publishing exceptions, based upon the ASP.NET 2.0 Provider design pattern. Using this framework you can configure one or more exception providers within an application domain configuration file (e.g. app.config or Web.config) and at runtime the framework determines the appropriate provider to publish the exceptions to.


The default exception provider within the framework is the SqlExceptionProvider class, which is responsible for persisting exceptions within a SQL Server 2005 database. Within the database there is the Exception table which contains columns for the each of the properties defined within the System.Exception base exception class, however it also contains a column that uses the new XML column type, within SQL Server 2005, to enable the database to store the exceptions serialized using the .NET Framework’s SoapFormatter class. The serialized exceptions will then allow developers to examine the various properties that may exist on exceptions derived from System.Exception.


When debugging exceptions that occur either within a development environment, or especially within a production environment, knowledge is power!!!


CSharpDistilled.Diagnostics is intended to provide that power such that .NET developers can sleep easy at night knowing that their exceptions are being published and that they’ll be able to resolve the issues that caused the exception in the first place.


Although the project is listed as an alpha release on CodePlex the framework is fully functional and will persist exceptions, and the various inner-exceptions, to the SQL Server 2005 database. In reality it is alpha because I’d like to get as much feedback from people who download it before I release a beta release which will then be functionally complete and unlikely to change aside from some internal workings which may be tweeked before a final RTM build is made available.


So hopefully the alpha nature of the release won’t stop you from downloading the framework and letting me know what you think.


Finally, once the framework has been released with one or two exception providers it is my intent to provide both a Windows Forms and ASP.NET based Diagnostics Management Studio, which would allow development teams to more easily search through exceptions that have been logged either in production or development environments. There is even a chance that the Diagnostics Management Studio will find itself as a plug-in to either Visual Studio 2005 or Microsoft Outlook 2007 (once released).

Windows Vista Build 5456 and .NET Framework 3.0 June CTP


Yesterday Microsoft released the June CTP of the newly renamed .NET Framework 3.0 which was previously known by the codename WinFX. You can download this CTP here:

.NET Framework 3.0 June CTP


Interestingly, this download page mentions that this CTP is intended only for users of Windows Vista Build 5456, Windows XP, or Windows 2003 Server. Those of you with a keen eye will notice that Windows Vista Beta 2 was build 5384, meaning that Microsoft must be about to release build 5456 to beta testers although it is unclear if this build will also be made available to MSDN subscribers. I would hope that it would be made widely available to MSDN subscribers so that they too can contribute to the quality, not only of Windows Vista, but of the .NET Framework 3.0 as it progresses towards the RTM milestone. If you install this CTP and have any suggestions or bugs to report I would advise you to surf on over to the Microsoft Product Feedback Center and log them there for Microsoft to triage and hopefully act upon accordingly. The Microsoft Product Feedback Center is now hosted on the Microsoft Connect website which has recently undergone a major revision.


In addition to the CTP build of the .NET Framework 3.0, a release candidate (RC) build of the Windows Workflow Foundation has also been released and can be downloaded here:


June CTP Available, RC Build of WF


Update June 24, 2006 1:08PM PST – Microsoft may well have uploaded Windows Vista Build 5456 as Microsoft Connect is suddenly very slow…


Update June 24 2006 1:35PM PST – Build 5456 of Windows Vista is now available for download on Microsoft Connect in both x86 and x64 editions.

Was an Assembly Built in Debug or Release Mode?

Sometimes you find yourself wondering if an assembly was compiled with or without the /debug compiler option, in the case of the C# compiler. The following download link will allow you to download a small C# program that given the path to an assembly will print either debug more or release mode to the console.


Basically this is determined by looking at the IsJITTrackingEnabled property of the DebuggableAttribute class as applied to the assembly in question. This property returns true if the runtime will track information during code generation for the debugger; otherwise, false.


Thanks to Bill for providing a blog posting in VB that this C# solution is based upon.


Notes: Within the Visual Studio 2005 solution that can be downloaded from this blog posting you will find three C# projects. The first of these projects, DebugBuild, contains the actual program that establishes if an assembly was built with the debug or release modes. Also within the solution are two other projects, Debug and Release, that are intended to allow you to test the DebugBuild program. These projects are simply new C# projects with only the Debug or Release configuration set, nothing more interesting than that there. If you have any questions regarding this code please contact me through the blog.

Chatting about LINQ and ADO.NET Entities

In preparation for Microsoft TechEd 2006 which begins this weekend in Boston; I’ve been absorbing as much information as I can regarding some of the future technologies that I plan to attend sessions for while at TechEd. These technologies include LINQ (Language Integrated Query) and the Windows Communication Foundation (previously known by the Microsoft code-name Indigo.

MSDN Channel 9 is an excellent resource for developers, and today I noticed that Anders Hejlsberg and Sam Druker are chatting about LINQ and ADO.NET Entities. The May CTP of LINQ is now available for download from the LINQ homepage

CLR via C#



Jeffrey Richter (Wintellect) has produced an awesome C# book in CLR via C# published by Microsoft Press.


Unlike many books on the C# programming language, which simply show you the syntax behind some programming concept as supported by the CLR, this book lifts up the hood to expose the inner workings of the CLR enabling the reader to appreciate the why as well as the how.


Incidentally, Jeffrey Richter will be presenting a two day virtual course entitled Effective Threading, which I would recommend to any developer who feels as though they would like to master threading and asychronous programming on the .net platform.

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…


 

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.

Visual Studio Orcas Class Designer

Unfortunately I’m not about to divulge Microsoft’s plans for the Visual Studio Orcas Class Designer but rather discuss some enhancements that I’d really like to see included in the Orcas release of this wonderful addition to the Visual Studio environment. If you agree with any of these suggestions then I would encourage you to surf on over to the MSDN Product Feedback Center and then vote on the suggestions. The FDBK numbers below are hyperlinked to the suggestions within the Product Feedback Center.



FDBK24225    Display Custom Attributes on Class Diagrams


Class diagrams should show custom attributes adorning the types shown within class diagrams, including those adorning the fields, methods, properties, events, etc. Custom attributes could be shown within the class diagram using either a language specific notation (e.g. [Serializable] in C# and in VB) or in a language neutral notation not too dissimilar to UML stereotypes.


FDBK23744    Visual Differencing of Class Diagrams


With most UML tools I’ve ever used from IBM/Rational Software and other vendors, there hasn’t been an ability to perform differencing at the diagram level although this would be an exceptionally powerful feature. I’ve seen this feature implemented in IBM/Rational Software Architect 6.0 although this is the only tool that I’m aware of that provides support for visual differencing


FDBK23695    Class Designer Interface Realization Association


It would be nice when the interface is shown on the class diagram in its class form rather than the lollipop notation for a dashed realization association to be shown and optionally hidden if the diagram becomes too chaotic.


FDBK23743    Support for Design Pattern Wizards in Visual Studio Class Designer


This was a feature that was really useful with Rational XDE for Visual Studio 2003, the ability to apply design pattern wizards for the Gang-of-Four design patterns; especially if the wizard infrastructure allowed for extensibility with other pattern wizards provided either by the developer themselves or by Microsoft and third parties.

FDBK11348    Visual Debugging using Sequence Diagrams


Not directly related to the class designer which shows static code structure, but what would be an excellent debugging tool (similar to the Visual Trace tool in Rational XDE for Visual Studio 2003) is the ability to generate sequence diagrams showing the execution path for a set of types that are ‘watched’ in a given debugging session.