WPF toolbox installer for a type defined in a different assembly

Question

I'm trying to create a VSIX installer for a WPF control.

Its supposedly easy, but the "easy" version assumes that you create the WPF control in the VSIX project.

The thing is, I've got my UserControl nestled deep within one of my DLLs, and I don't believe pulling it out is the best design. I'd like to leave it in there, but I can't seem to do this AND have the control added to the toolbox.

One option would be to move the code I need to install it to the toolbox into the control's assembly, but that would add a dependency to Microsoft.VisualStudio.Shell.Immutable.10.0.dll. The assembly is both used by someone with Visual Studio installed, and a remote server running within a service where VS isn't installed, so that's a no-go.

Another option I tried was to "trick" the toolbox installer VSIX by applying the RegistrationAttribute to proxies which would register the types defined in the other assembly. Thought it would work, but weird stuff happened.

Instead of getting two controls, I get a bunch of Border controls (the standard WPF border) in oddly named tabs, some of which echo some of my namespaces.

How can I register a WPF UserControl with the Toolbox when the control is defined in an assembly other than the VSIX?

Shirker

Where is the assumption that the WPF control must be in the VSIX project? Also, what do you mean by the "easy" version? – Serajevo

@Matt: No assumption, just how the tools are designed. If you follow the MSDN walkthroughs here and here or just look at the installed template, you'll see that it is geared towards (the tutorials and the template) combining installer and control in the same project. Or, you could just try to answer my question, in which case you'll find there is nothing easy about doing it any other way. – Shirker

@Will I think I see your point, it looks like the ProvideToolboxControl attribute is the dependency you talk about? – Serajevo

@Matt: Yep. And the proxies are types that went in the VSIX, but that I tried to use to register other types defined in other assemblies. – Shirker

@Will, What weird stuff happened with the proxies? I use a similar trick for my custom editors (where the core controls live in another dll). – Serajevo

@Matt: The image describes exactly what happens. AFAICR, it seemed very simple to create the proxies (I don't have the code anymore), but it would fail spectacularly as you can see. – Shirker

Have you found a solution? – Flourish

@Riccardo: Have you tried the answer's solution? Also, there is an overload for the attribute that takes a type name and assembly name, which can break that assembly reference requirement. That's how MS does it. But you have to drop the control assembly somewhere that VS can find it. – Shirker

Answer 1

I was able to whip up a proof of concept similar to the proxy idea that you had mentioned.

The problem that you're seeing is caused by the registration of the wrong assembly, so I created a new registration attribute called ProvideProxyToolboxControlAttribute which is used as an attribute on the proxy classes that you have in your VS integration assembly. It's almost identical to ProvideToolboxControlAttribute except that it takes the type of the actual control. Of course, this new attribute would also be in your VS assembly.

For example, say I have a toolbox control in my non-VS assembly called MyToolboxControl, I'd create a simple proxy class MyToolboxControlProxy in my VS assembly that looks like this:

[ProvideProxyToolboxControl("MyToolboxControl", typeof(NonVsAssembly.MyToolboxControl))]
public class ToolboxControlProxy
{
}

And of course, the magic happens in ProvideProxyToolboxControlAttribute, which is basically just this class (comments and parameter/error checking removed for brevity):

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)]
[System.Runtime.InteropServices.ComVisibleAttribute(false)]
public sealed class ProvideProxyToolboxControlAttribute : RegistrationAttribute
{
    private const string ToolboxControlsInstallerPath = "ToolboxControlsInstaller";
    public ProvideProxyToolboxControlAttribute(string name, Type controlType)
    {
        this.Name = name;
        this.ControlType = controlType;
    }

    private string Name { get; set; }

    private Type ControlType { get; set; }

    public override void Register(RegistrationAttribute.RegistrationContext context)
    {
        using (Key key = context.CreateKey(String.Format(CultureInfo.InvariantCulture, "{0}\\{1}",
                                                         ToolboxControlsInstallerPath,
                                                         ControlType.AssemblyQualifiedName)))
        {
            key.SetValue(String.Empty, this.Name);
            key.SetValue("Codebase", ControlType.Assembly.Location);
            key.SetValue("WPFControls", "1");
        }
    }
    public override void Unregister(RegistrationAttribute.RegistrationContext context)
    {
        if (context != null)
        {
            context.RemoveKey(String.Format(CultureInfo.InvariantCulture, "{0}\\{1}",
                                                         ToolboxControlsInstallerPath,
                                                         ControlType.AssemblyQualifiedName));
        }
    }
}

It seems to work well, I verified that the control is in the toolbox and that the proper registry keys were added.

Hope this helps!

Serajevo

Thanks for the help on this. It will be a week or so before I can actually roll this in and see if it works for me. – Shirker

@Will I'd say a couple of years. – Basso