WPF toolbox installer for a type defined in a different assembly

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?

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!