Component classes, what's the idea?

[Mikael]

What's the idea behind Component Classes? When are they intended to be used
and what's the benefits?

How can you in the midle tier of a n-tiered remoting application use component
classes, when remoting objects must be inherited from MarshalByRefObject,
not from "System.ComponentModel.Component"?

Thanks,
Mikael

[Aaron Anderson]

The idea behind System.ComponentModel.Component is to allow developers to
easily create components that can interact with the Visual Studio IDE. If
you don't care about dragging and dropping the component onto the designer,
then just inherit from System.Object.

"Mikael" <mjs@nospam.beamex.com> wrote in message
news:3a8a6cff$1@news.devx.com...
>
>
> What's the idea behind Component Classes? When are they intended to be
used
> and what's the benefits?
>
> How can you in the midle tier of a n-tiered remoting application use
component
> classes, when remoting objects must be inherited from MarshalByRefObject,
> not from "System.ComponentModel.Component"?
>
> Thanks,
> Mikael
>

[Mikael]

>> How can you in the midle tier of a n-tiered remoting application use
>component
>> classes, when remoting objects must be inherited from MarshalByRefObject,
>> not from "System.ComponentModel.Component"?

The solution to this problem seems to be the viritual class "ServicedComponent",
which derives directly from "MarshalByRefObject".