Design time and run time component assemblies

[Edward Diener]

In Borland's VCL it was possible to divide a component into design time and
run time DLLs. The design time DLL would only be necessary when the
programmer was setting a component's properties or events in the Object
Inspector, the equivalent to the VS .NET Windows form designer. The run-time
DLL would only contain the code necessary at run-time. The design time DLL
referenced the run-time DLL, but not vice-versa. This allowed the run-time
DLL only to be shipped to end-users of a module. The design time DLL was
only used by programmers who "designed" the component in their own code.

Why was this a good thing ? It was because the code pertaining to the RAD
design time system did not have to be included at run-time when the
component was executed, and therefore did not have to be shipped to
end-users as opposed to end-programmers. The run-time DLL was therefore
smaller and less bloated with unnecessary code.

It does not appear this is possible in .NET. I can still certainly divide my
component into two different assemblies, one for run-time code and one for
design-time code, which is what I would anyway as a matter of cleaner design
from my point of view. But it seems there are two reasons that I can not
make a clean division, such that both assemblies need to be available at
design time while the run-time assembly only needs to be available at
run-time.

The first reason is that the classes I use for my design time code, derived
from System.ComponentModel, do not necessarily only pertain to design time
functionality. According to the documentation on type converters, as an
example, they might apply both to design time and run-time.

Secondly to use the classes in my design time assembly at design time, I
must provide attributes for the types and properties to which the
design-time classes pertain and, if the attributes refer to classes in
another assembly, they must reference that other assembly. This effectively
ties my run-time assembly to these classes which I only want to use at
design time.

Has this issue been addressed or discussed anywhere ? It does seem to me
wasteful that .NET classes which I create only for design time functionality
needs to be distributed to the end-user by a programmer who uses my
component, even though the end-user will never need the functionality.
Furthermore I see no way to tell .NET that the classes which I create for
design-time functionality should only be used at design time and not
run-time.

Because of these issues, I have a feeling that there must be a way to create
a design time assembly for my component which does not have to be
unnecessarily shipped to end-users for run-time execution. Does anybody know
how to do this ?

 

[Nick Malik]

I am not a Borland user, so I don't have the experience you have had.
However, I don't see why you shouldn't be able to do this.

Create a base class derived from System.ComponentModel that provides your
run-time funcationality for your object. Put your type converters into this
class.

Create another class, derived from that one, that provides the design time
functionality. Put these classes into two seperate projects.
The upper class would make reference to any code from the design time
portions of other components... simply make sure that the runtime classes do
not have access to the design time capabilities of other controls and you
won't get the links you don't want.

Since the design time control simply inherits the capabilities of the
run-time class, you can have functionality that applies to both fairly
readily.

I'm not sure why you believe that this isn't possible, but to be honest, I'm
not doing control development. You may very well have stumbled upon a
limitation and I may very well be speaking out of ignorance. If that is the
case, I apologize.

In conclusion, while Borland's objects may have had this kind of thing
built-in, I'm not certain that your problems aren't simply design issues,
and not actually framework limitations.

Either way, good luck,
HTH,
--- Nick

 

[Edward Diener]

I am not a Borland user, so I don't have the experience you have had.
However, I don't see why you shouldn't be able to do this.

Create a base class derived from System.ComponentModel that provides
your run-time funcationality for your object. Put your type
converters into this class.

I only need my type converters at design-time. Putting type converters in
my class pays for something I do not need at run-time. The whole idea of
putting type converters into a design-time assembly, and then having
attributes which reference these type converters purely for design-time
functionality, is a decent one, but it ties my run-time assembly to my
design-time assembly even when I do not need the functionality at run-time.

Create another class, derived from that one, that provides the design
time functionality. Put these classes into two seperate projects.
The upper class would make reference to any code from the design time
portions of other components... simply make sure that the runtime
classes do not have access to the design time capabilities of other
controls and you won't get the links you don't want.

But I would still be using the design-time capabilities of my own control in
my run-time assembly even though I only need this at design-time and not
run-time. The same goes for design-time editors and designers. In order to
use them, one must specify attributes in the run-time component, and this
ties the run-time component to the design-time component, even when the
design-time component is no longer needed at run-time.

Since the design time control simply inherits the capabilities of the
run-time class, you can have functionality that applies to both fairly
readily.

I'm not sure why you believe that this isn't possible, but to be
honest, I'm not doing control development. You may very well have
stumbled upon a limitation and I may very well be speaking out of
ignorance. If that is the case, I apologize.

I could be wrong but I do not believe that attributes are polymorphic. When
you specify an attribute, you specify the exactly class of the attribute.

In conclusion, while Borland's objects may have had this kind of thing
built-in, I'm not certain that your problems aren't simply design
issues, and not actually framework limitations.

I do not think you have solved the problem. I do not see this as my design
issue. The only other way to solve it, as I understand it, is to create the
design-time attributes for my types and properties at run-time rather than
directly in the source. But this is a PITA.

I am still surprised that no one else has run into this situation.