all groups > dotnet windows forms designtime > february 2005 >
You're in the

dotnet windows forms designtime

group:

Separating Design-Time Capabilities from Run Time


Separating Design-Time Capabilities from Run Time mark NO[at]SPAM arcabama.com
2/16/2005 7:55:50 PM
dotnet windows forms designtime:
I find myself running into the following situation writing C# programs
that have controls and components that have custom designers associated
with them:

1) I need to write code that uses non-redistributable assemblies (e.g.,
EnvDTE) at design time, but not at run time.

2) Referencing Types from the non-redistributable assemblies in the
same assembly as the redistributable Types causes a runtime exception
on my client's machines (because they do not have the
non-redistributable assemblies installed).

I "solve" this problem by segregating the code sections that use
non-redistributable Types into a separate assembly. As long as the code
that references the new "non-redistributable wrapper assembly" (sorry,
it's late, and I can't think of a clever name) never gets executed, the
previous run time exception is avoided.

While this works, it feels kludgy (for one thing, I have to
redistribute the "non-redistributable wrapper assembly", even though if
it were ever called it would cause an exception).

What's a better design pattern to use?

- Mark
RE: Separating Design-Time Capabilities from Run Time v-jetan NO[at]SPAM online.microsoft.com (
2/17/2005 7:54:28 AM
Hi Mark,

Thanks for your posting!!

Based on my understanding, you want to force the code section that uses
non-redistributable assemblies only to execute at design-time. If I
misunderstand you, please feel free to tell me, Thanks.

In Windows Forms, we may query Component.Site.DesignMode property to
determine if currently the components are under designmode. But in Asp.net,
there is not equivalent property for us, please refer to the article below:
"Detecting Designmode in ASP.Net"
http://west-wind.com/weblog/posts/189.aspx

Once we can determine if currently the component is under design-time, we
may disable the design-time available code running without at runtime.

Hope this helps
==================================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Re: Separating Design-Time Capabilities from Run Time mark NO[at]SPAM arcabama.com
2/17/2005 10:03:03 AM
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

[quoted text, click to view]
rights.
Re: Separating Design-Time Capabilities from Run Time Frank Hileman
2/17/2005 10:31:23 AM
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]

Re: Separating Design-Time Capabilities from Run Time Frank Hileman
2/17/2005 6:59:36 PM
Hello Jeffrey,

It is not necessary for the assembly to be installed on the client's
machine, unless the client is using the design-time assemblies in Visual
Studio .NET. This is a Visual Studio .NET problem and not specific to the
problem in general. It appears that non-GAC assemblies were not considered
or tested during the Visual Studio .NET design, except in the case where the
design-time types (designers, etc) were embedded in the same assembly.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor


[quoted text, click to view]

Re: Separating Design-Time Capabilities from Run Time v-jetan NO[at]SPAM online.microsoft.com (
2/18/2005 2:40:10 AM
Hi Mark,

Thanks for your feedback!!

DesignMode property should be reliable except that it will not return the
correct value in component class' constructor.

Frank's way of retrieving types from GAC is another choice, but I think it
requires extra work of installing assembly in client's machine. However,
you may still separate the design-mode code in another assembly. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
AddThis Social Bookmark Button