Hello Mark,
Yes, most design-time attributes that reference design-time classes can use
a string containing a fully qualified class name instead of a class
reference. For example, DesignerAttribute, EditorAttribute. If you use this
mechanism you will need to install the main run-time assembly in the GAC,
otherwise VS may load your assembly twice using its internal LoadFrom code,
causing type errors. Finally you may also separate some of your EnvDTE code
into an assembly that references your run-time assembly, instead of
vice-versa. This might require a redesign, but the string based attributes
will help.
Regards,
Frank Hileman
check out VG.net:
http://www.vgdotnet.com Animated vector graphics system
Integrated Visual Studio .NET graphics editor
----- Original Message -----
Newsgroups: microsoft.public.dotnet.framework.windowsforms.designtime
Sent: Thursday, February 17, 2005 10:03 AM
Subject: Re: Separating Design-Time Capabilities from Run Time
[quoted text, click to view] > Jeffrey,
>
> Thanx for the quick reply. However, that's not what I was asking. I
> essentially do what you're suggesting already (although I tend to use a
> try/catch block wrapping creation of the designtime-only objects;
> DesignMode isn't sufficiently reliable, IMHO).
>
> What I'm really interested in is whether there's a different design
> pattern from distributing the designtime library but blocking any of it
> from running at run time. In other words, right now I have to
> distribute an assembly DLL that I never want called at runtime. This
> strikes me as ugly.
>
> Does anyone know of any other design patterns that can be used to deal
> with the need to segregate designtime code?
>
> - Mark