design-time writer’s block

Something to ease the pain of switching between Visual Studio and Blend. An Intellisense AddIn for Blend!

A well executed, no-nonsense addin, reusing Kaxaml’s intellisense code and hooking Blends ICodeEditor. Well done, Stefan.

My only concern is what happens when a second highly useful addin becomes available. I hope Blend 3 has AddIn management on the table, or perhaps an AddIn Manager addin is in order…

So I just read Robby’s fantastic and informative post discussing the state of 3d support in silverlight and I had one nitpick clarification I wanted to point out. Some context; in his post he discusses markup in silverlight within the “‘Real’ 3D Frameworks” part, stating

Unfortunately, Silverlight doesn’t yet have the parser extensibility required to make these APIs markup friendly. For now, at least, the 3D API may be compatible with WPF in code, but there’s not a good markup story.

This isn’t exactly true. Silverlight supports custom TypeConverters, which would allow the xaml parser to convert custom type markup to objects. This is just a case of Kit3D hasn’t yet ported those over, for things like Vector3D using a Vector3DConverter.

The xaml story for silverlight is pretty strong, over all. In addition to TypeConverters, you can use XmlnsDefinition in silverlight, so that you can map several namespaces to a single schema Uri providing a more natural usage of namespaces in your xaml. The only thing that silverlight is really lacking is MarkupExtensions, which incidentally I think will be added in a future release, based on the fact that the MS.Internal.IMarkupExtension interface exists in System.Windows.dll.

[Updated 8.5.2008]
Hey Robby, Turns out I was wrong about XmlnsDefinitions. Yes the attributes exist in silverlight 2, but the XamlParser does not respect them. As Mark has informed me, this is a feature that will be added after Silverlight 2 RTM. On the plus side, TypeConverters definitely work.

I discovered, much to my surprise, that Blend 2 has the necessary infrastructure to support rudimentary custom extensions.  The extensions take the form of a class which implements the public interface Microsoft.Expression.Framework.AddIn.IAddIn.

Inline is a very simple HelloWorld sample.

AddInDescription("HelloWorld", AddInCategory.Tool)]
public class HelloWorld : IAddIn
{
    public void Initialize(IApplicationService 
      applicationService) {}

    public void StartupComplete()
    {
        // Show we were here
        System.Windows.MessageBox.Show("Hi");
    }

    public void ShuttingDown() {}

    IDisposable Members
}

AddIns are hooked on startup, specified as command line arguments:
path\to\blend.exe /addin:HelloWorld.dll

When initialized, an Application ServiceProvider object reference is passed, which contains accessors to all the major service provider objects of Blend.  Through this, it’s possible to add custom menus and dialogs, possibly even panels, to Blend.

I expect there are alot of limitations.  The most glaring is loading Addins only by specifying them as commandline arguments. Much of Blend is internal and/or sealed, including Nautilus (Blend’s code editor), Visual Studio abstractions for Projects, Solutions, and the Build system.  Enough remains open to allow for some customization of existing features, and certainly for new features.

More discovery needs to be done.