You don’t need to play the piano, use Virtuosity.

This blog posts is part of a series of blog posts about Simon Cropp’s awesome Fody project. For an overview over the blog posts please read this article.

In this article we are going to focus on Virtuosity. Let us first explore what Virtuosity does and what we can benefit from this Fody addin.

If you install (Install-Package Virtuosity.Fody)Virtuosity to your assemblies it will automatically select all members that meet the following criteria:

• from non sealed classes
• non static members
• non abstract members
• non private members
• non virtual members

the selected members will be changed to virtual in the output assembly and those now virtual members will have the following changes applied:

• change calls to those members to virtual
• change new modifiers to override modifiers

Code means more than thousand words so let us explore some production worthy code ( 😉 ):

namespace Virtuositized
{
    public abstract class AbstractClass
    {
        public abstract void PublicAbstractMember();
        internal abstract void InternalAbstractMember();
        protected abstract void ProtectedAbstractMember();

        public static void PublicStaticMethod()
        {
        }

        internal static void InternalStaticMethod()
        {
        }

        protected static void ProtectedStaticMethod()
        {
            PrivateStaticMethod();
        }

        private static void PrivateStaticMethod()
        {
        }
    }

    public sealed class SealedClass : AbstractClass
    {
        public override void PublicAbstractMember()
        {
        }

        internal override void InternalAbstractMember()
        {
        }

        protected override void ProtectedAbstractMember()
        {
        }
    }

    public class PublicClass : AbstractClass
    {
        public void PublicConcreteMember()
        {
        }

        internal void InternalConcreteMember()
        {
        }

        protected void ProtectedConcreteMember()
        {
        }

        private void PrivateConcreteMember()
        {
            ProtectedStaticMethod();
        }

        public override void PublicAbstractMember()
        {
        }

        internal override void InternalAbstractMember()
        {
        }

        protected override void ProtectedAbstractMember()
        {
        }
    }

    internal class InternalClass : IInterface
    {
        public void PublicConcreteMethod()
        {
        }

        public void Method()
        {
        }
    }

    internal class AnotherInternalClass : InternalClass
    {
        public new void Method()
        {
        }
    }

    public interface IInterface
    {
        void Method();
    }
}

After compilation we open the assembly with dotPeek and see:

The assembly contains now a marker interface called ProcessedByFody. This indicates that Fody has done some magic with our assembly. Let’s explore the individual classes:

Nothing has changed for the abstract class.

Neither for the sealed class.

The public class has been selected by Virtuosity’s algorithm and all “concrete” members which are not private have been changed to virtual.

The InternalClass has been changed also. The implemented method of the interface IInterface has been made virtual, this change has an effect on all inheritors of InternalClass. So let us have a look at the AnotherInternalClass.

The previously declared new method is now an override as expected. But why is this useful?

If you are using tools like NHibernate, Ninject with the Interception Extension, Entity Framework or any other tools which makes use of DynamicProxy there is one caveat involved. All intercepted members must be virtual. If you fail to mark a member as virtual an obscure runtime exception will occur and looking for the needle in the haystack begins. Virtuosity certainly helps in those scenarios. But there is another scenario where Virtuosity makes my developer life more enjoyable.

• Do you do Test Driven Development in your project?
• Did you end up writing a lot of interfaces which are named exactly like the class that implements that interface plus a prefix or a postfix?
• Did you never, ever swap out those interfaces during composition with another implementation except for acceptance or integration testing purpose?

In essence we have been writing a lot of unnecessary interfaces just for testing purpose so that our faking framework of choice was able to fake it out. This time is over with Virtuosity and I will demonstrate this in my next blog post!