You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/07/31 20:20:09 UTC
What are .NET capabilities?
Before we go down the road of developing Avalon.NET container and framework,
I would like to find out how .NET handles certain things. For example, in
Java we have JMX (Java Management Extensions) which *can* (though not
necessarily) connect to SNMP consoles.
One of the things I would like us to answer is what is the fundamental
difference between a .NET component and an Avalon component? I can answer
questions all day about Avalon components, but I am sketchy on the details
of .NET components.
What management functions/instrumentation options does .NET provide? For
example, can we plug in to the Microsoft Management Console?
What other .NET goodies would apply?
While some of these are long term (like management), others affect how much
we want to simply use vs. invent.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: What are .NET capabilities?
Posted by hammett <ho...@cimcorp.com.br>.
Chris Geer's post named "CSFramework & CSContainer Thoughts..." has a core
list of differences.
AFAIK there is no JMX-like solution for .Net and a MMC Snap in is not easy
do develop (even in C++/ATL). There is a framework
(http://www.ironringsoftware.com/DesktopDefault.aspx?PageId=19) that
implements a bridge between .Net and "legacy" COM interfaces to create MMC
Snap ins in a easy way. Management of local or remote containers should be
easy implemented using remoting architecture.
> What management functions/instrumentation options does .NET provide? For
> example, can we plug in to the Microsoft Management Console?
>
> What other .NET goodies would apply?
The things that I think should be considered are:
- Configurations
- Security
- Remoting
I'm sure I forgot something.
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: What are .NET capabilities?
Posted by Berin Loritsch <bl...@apache.org>.
hammett wrote:
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
>
>>>Berin, are you trying to bring up distictions of run-time and
>
> desing-time?
>
>>>The component model namespace deals with it.
>>
>>No, I'm fairly ignorant of the .NET API and I am trying to come up to
>
> speed
>
>>as quickly as possible so that we don't have to rethink things that have
>>already been done well enough.
>
>
> Easy, man. We don't have the time-to-market pressure (I think). Let's do a
> fine job that we can be proud of.
I hear ya. Its just finding out where to start. I think that was the last
little bit. Truthfully I was looking for something that was akin to the
LookupManager concept (i.e. kind of like JNDI or just the
Context/ServiceManager). I stumbled across those and was curious.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: What are .NET capabilities?
Posted by hammett <ho...@cimcorp.com.br>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
> > Berin, are you trying to bring up distictions of run-time and
desing-time?
> > The component model namespace deals with it.
>
> No, I'm fairly ignorant of the .NET API and I am trying to come up to
speed
> as quickly as possible so that we don't have to rethink things that have
> already been done well enough.
Easy, man. We don't have the time-to-market pressure (I think). Let's do a
fine job that we can be proud of.
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: What are .NET capabilities?
Posted by Berin Loritsch <bl...@apache.org>.
hammett wrote:
> Berin, are you trying to bring up distictions of run-time and desing-time?
> The component model namespace deals with it.
No, I'm fairly ignorant of the .NET API and I am trying to come up to speed
as quickly as possible so that we don't have to rethink things that have
already been done well enough.
>
> "An important feature of components in the .NET Framework is that they are
> designable, which means that a class that is a component can be used in a
> rapid application development (RAD) environment such as Visual Studio .NET.
> A component can be added to the toolbox of Visual Studio .NET, can be
> dragged and dropped onto a form, and can be manipulated on a design surface.
> Note that base design-time support for IComponent types is built into the
> .NET Framework; a component developer does not have to do any additional
> work to take advantage of the base design-time functionality."
>
>
>>Anyway, we may just as well be barking up the wrong tree with these.
>
>
> I bet so :-)
>
> hammett
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: What are .NET capabilities?
Posted by hammett <ho...@cimcorp.com.br>.
Berin, are you trying to bring up distictions of run-time and desing-time?
The component model namespace deals with it.
"An important feature of components in the .NET Framework is that they are
designable, which means that a class that is a component can be used in a
rapid application development (RAD) environment such as Visual Studio .NET.
A component can be added to the toolbox of Visual Studio .NET, can be
dragged and dropped onto a form, and can be manipulated on a design surface.
Note that base design-time support for IComponent types is built into the
.NET Framework; a component developer does not have to do any additional
work to take advantage of the base design-time functionality."
> Anyway, we may just as well be barking up the wrong tree with these.
I bet so :-)
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: What are .NET capabilities?
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Before we go down the road of developing Avalon.NET container and
> framework,
> I would like to find out how .NET handles certain things. For example, in
> Java we have JMX (Java Management Extensions) which *can* (though not
> necessarily) connect to SNMP consoles.
>
> One of the things I would like us to answer is what is the fundamental
> difference between a .NET component and an Avalon component? I can answer
> questions all day about Avalon components, but I am sketchy on the details
> of .NET components.
>
> What management functions/instrumentation options does .NET provide? For
> example, can we plug in to the Microsoft Management Console?
>
> What other .NET goodies would apply?
>
> While some of these are long term (like management), others affect how much
> we want to simply use vs. invent.
>
After a quick scan to get more info on the System.IDisposable interface, I
stumbled accross the System.ComponentModel stuff.
I believe we can keep using the System.IDisposable interface without issue.
I was quite surprised that there is no System.IInitializable interface
considering all the classes that define the Initialize() method.
Anyway, a quick rundown of what M$ has done for the ComponentModel:
THere are a series of interfaces (I always check these first):
IComponent --> Can be applicable, although not quite sure if it should be
required yet. There are some things I am not convinced on yet.
IContainer --> Can be as simple as a List. Allows you to add components
bound to a specific name, etc. It seems very collections-like.
ICustomTypeDescriptor --> Bears looking into. It might be a good thing/pattern
to leverage.
IExtenderProvider --> Allows you to define a provider to extend components.
ISite --> A container/component mapping. Holds a name and any component
specific info. Assumes integration with IComponent and IContainer.
ISupportInitialize --> A pre/post initialize adaptor. Kind of like an
interceptor for initialization.
ISynchronizeInvoke --> Provides interface for synchronous or asynchronous
delegator invocation. Very promising.
ITypeDescriptorContext --> Not exactly sure what it does. It doesn't seem
to represent what I originally thought it did.
Anyway, we may just as well be barking up the wrong tree with these.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org