Instalador de herramientas WPF para un tipo definido en un ensamblaje diferente

visual-studio user-controls

Question

Estoy tratando de crear un instalador VSIX para un control WPF.

Supuestamente es fácil, pero la versión "fácil" asume que usted crea el control WPF en el proyecto VSIX .

La cuestión es que tengo mi UserControl dentro de uno de mis archivos DLL, y no creo que sacarlo sea el mejor diseño. Me gustaría dejarlo allí, pero parece que no puedo hacer esto Y tener el control agregado a la caja de herramientas.

Una opción sería mover el código que necesito para instalarlo en la caja de herramientas en el ensamblaje del control, pero eso agregaría una dependencia a Microsoft.VisualStudio.Shell.Immutable.10.0.dll . El ensamblado lo usa alguien con Visual Studio instalado y un servidor remoto que se ejecuta dentro de un servicio donde VS no está instalado, por lo que es un no-go.

Otra opción que probé fue "engañar" al instalador de herramientas VSIX al aplicar RegistrationAttribute a los proxies que registrarían los tipos definidos en el otro ensamblado. Pensé que funcionaría, pero sucedieron cosas raras.

En lugar de obtener dos controles, obtengo un montón de controles de borde (el borde WPF estándar) en pestañas con nombres extraños, algunas de las cuales se hacen eco de algunos de mis espacios de nombres.

¿Cómo puedo registrar un UserControl de WPF con Toolbox cuando el control está definido en un ensamble que no sea el VSIX?

Answer 1

Logré una prueba de concepto similar a la idea de proxy que mencionó.

El problema que está viendo es causado por el registro del ensamblaje incorrecto, por lo que creé un nuevo atributo de registro llamado ProvideProxyToolboxControlAttribute que se usa como un atributo en las clases proxy que tiene en su ensamblado de integración VS. Es casi idéntico a ProvideToolboxControlAttribute excepto que toma el tipo del control real. Por supuesto, este nuevo atributo también estaría en su ensamblaje VS.

Por ejemplo, supongamos que tengo un control de caja de herramientas en mi ensamblado no VS llamado MyToolboxControl , crearía una clase de proxy simple MyToolboxControlProxy en mi ensamblado VS que se ve así:

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

Y, por supuesto, la magia ocurre en ProvideProxyToolboxControlAttribute , que básicamente es solo esta clase (los comentarios y la comprobación de parámetros / errores se eliminaron por brevedad):

[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));
}
}
}

Parece que funciona bien, he verificado que el control está en la caja de herramientas y que se agregaron las claves de registro adecuadas.

¡Espero que esto ayude!