.NET: COM vs NET 
Author Message
 .NET: COM vs NET

Hi All,

We are starting a large new project with C++, with an intended release date
of 2005. We are starting completely "from scratch", from design up. (or is
that design down?)

We intend to have:
 * 80% of the code as pure, portable, C++ objects,
 * 10% of the code as a simple client side UI app,
 * and 10% of the code as some sort of COM layer that allows us to run the
whole lot on a single machine, and/or on 2 machines on a LAN, and/or on 2
machine across the Net.

We currently have some experimental code working with DCOM, and all is
working well.

Now, with .NET just around the corner, we are wondering if "COM" is the
direction we should be taking. We've looked at the Beta of VS-NET, and
VC.Net in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
runs...
All the documentation seems to indicate that using the new "attributes"
makes "COM programming easier", and that (D)COM for RPCs is still valid, but
thats not what I am hearing from people supposedly in the "know".

My question is: Is (D)COM still a valid, and acceptable way to remote a
ClientUI from the ServerObjects, is there a better way? Is Microsoft telling
us we should drop COM, and use the .NET framework instead (and what doies
that even mean? Does it mean "use NET objects on the
CommonLanguageRuntime"?)

Any thoughts much appreciated,
Robert.



Sun, 08 Jun 2003 21:58:13 GMT  
 .NET: COM vs NET
Hi Rob,

Quote:
> My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way?

Is certainly valid. As to better or not, that very much depends on your
needs, expectations and what you hope to accomplish. COM is not going away
anytime soon, too much depends on it, but I can't predict what will happen 5
years from now :)

Quote:
> Is Microsoft telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)

Most likely. .NET can use multiple
channels/transports/formatters(serializers). The most common will be those
that ship with the runtime, which are SOAP over HTTP and a binarry formatter
(or SOAP) on top of TCP, but you can extend the architecture to provide
aditional channels/transports and formatters.

--
Tomas Restrepo [VC++ MVP]

http://www.mvps.org/windev/



Mon, 09 Jun 2003 02:12:34 GMT  
 .NET: COM vs NET

Quote:
> > Is Microsoft telling
> > us we should drop COM, and use the .NET framework instead (and what
doies
> > that even mean? Does it mean "use NET objects on the
> > CommonLanguageRuntime"?)

> Most likely. .NET can use multiple
> channels/transports/formatters(serializers). The most common will be those
> that ship with the runtime, which are SOAP over HTTP and a binarry
formatter
> (or SOAP) on top of TCP, but you can extend the architecture to provide
> aditional channels/transports and formatters.

SOAP could be very easily integrated into VC6 with specific proxy/stubs (new
version of MIDL) and a derived version of CIS for the transport. .NET 's
considerations are elsewhere.
BTW, I've not used the SOAP toolkit yet, what does it provide exactly ?

--
Frederic Claux



Tue, 10 Jun 2003 00:20:54 GMT  
 .NET: COM vs NET

Quote:
> We are starting a large new project with C++, with an intended release
date
> of 2005. We are starting completely "from scratch", from design up. (or is
> that design down?)

Wow! You got plenty of time! I wish I had to release my stuff in 5 years.
But then I would probably spend couple of years on prototyping, and only
then decide which technology to use. If I had to ship in 2002, I would
definitely choose .NET.

--
Vagif Abilov



Tue, 10 Jun 2003 00:58:05 GMT  
 .NET: COM vs NET
5 years?! you work for the federal government, don't you?


Quote:
> Hi All,

> We are starting a large new project with C++, with an intended release
date
> of 2005. We are starting completely "from scratch", from design up. (or is
> that design down?)

> We intend to have:
>  * 80% of the code as pure, portable, C++ objects,
>  * 10% of the code as a simple client side UI app,
>  * and 10% of the code as some sort of COM layer that allows us to run the
> whole lot on a single machine, and/or on 2 machines on a LAN, and/or on 2
> machine across the Net.

> We currently have some experimental code working with DCOM, and all is
> working well.

> Now, with .NET just around the corner, we are wondering if "COM" is the
> direction we should be taking. We've looked at the Beta of VS-NET, and
> VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
> runs...
> All the documentation seems to indicate that using the new "attributes"
> makes "COM programming easier", and that (D)COM for RPCs is still valid,
but
> thats not what I am hearing from people supposedly in the "know".

> My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way? Is Microsoft
telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)

> Any thoughts much appreciated,
> Robert.



Wed, 11 Jun 2003 00:08:21 GMT  
 .NET: COM vs NET


Quote:
> 5 years?! you work for the federal government, don't you?



> > Hi All,

> > We are starting a large new project with C++, with an intended release
> date
> > of 2005. We are starting completely "from scratch", from design up. (or
is
> > that design down?)

> > We intend to have:
> >  * 80% of the code as pure, portable, C++ objects,
> >  * 10% of the code as a simple client side UI app,
> >  * and 10% of the code as some sort of COM layer that allows us to run
the
> > whole lot on a single machine, and/or on 2 machines on a LAN, and/or on
2
> > machine across the Net.

> > We currently have some experimental code working with DCOM, and all is
> > working well.

> > Now, with .NET just around the corner, we are wondering if "COM" is the
> > direction we should be taking. We've looked at the Beta of VS-NET, and
> > VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and
it
> > runs...
> > All the documentation seems to indicate that using the new "attributes"
> > makes "COM programming easier", and that (D)COM for RPCs is still valid,
> but
> > thats not what I am hearing from people supposedly in the "know".

> > My question is: Is (D)COM still a valid, and acceptable way to remote a
> > ClientUI from the ServerObjects, is there a better way? Is Microsoft
> telling
> > us we should drop COM, and use the .NET framework instead (and what
doies
> > that even mean? Does it mean "use NET objects on the
> > CommonLanguageRuntime"?)

In .NET, you would have a couple of options. You could use object remoting,
which has a model that is similar to DCOM, in that you have static
connections to objects.

Or, you could use Web Services, which is a connectionless protocol, and uses
SOAP to send XML information across http.

Which one would work best for you depends upon your architecture and needs.
If you're planning on running across the internet (and not a local net),
SOAP can make life a lot easier, as you don't really have the DCOM setup
issues.



Wed, 11 Jun 2003 00:40:24 GMT  
 .NET: COM vs NET
Quote:
> 5 years?! you work for the federal government, don't you?

Nope, I just work for that rarest of companies, large, rich, patient, and
future thinking! Sometimes I pinch myself to make sure I'm not dreaming!
haha.

Quote:
> In .NET, you would have a couple of options. You could use object
remoting,
> which has a model that is similar to DCOM, in that you have static
> connections to objects.

Hmmm ok, I think this sounds like us. The closest thing I can compare our
app to is AutoC*D. Imagine that the AutoC*D objects and functionaliuty are
pretty much pure C++ with no COM stuff, (about 80% of the code), followed by
a 10% layout of COM or .NET or something on top of that. And finally a 10%
UI which handles mouse, keyboard, screen draws etc, and can be on a
different machine to the core.
Under the "DCOM" model, this is working pretty well, and we'd be keen to use
that same type of "model" in NET I think.

Its also important to us that the package runs on single machine just as
well as on 2 machines on a LAN, just as well as 2 machines on the
Internet... preferable without having to change our code for those different
cases, and without having to have the "single machine" case needing to have
IIS and\or NT server installed....

DCOM seems to let us do all of that ok (the 2 machines on the internet case
is a bit more tricky admittedly).
We NET make it easier or harder to achieve this goal of "single machine" up
to "2 machines on the internet"?

Rob.



Quote:



> > 5 years?! you work for the federal government, don't you?



> > > Hi All,

> > > We are starting a large new project with C++, with an intended release
> > date
> > > of 2005. We are starting completely "from scratch", from design up.
(or
> is
> > > that design down?)

> > > We intend to have:
> > >  * 80% of the code as pure, portable, C++ objects,
> > >  * 10% of the code as a simple client side UI app,
> > >  * and 10% of the code as some sort of COM layer that allows us to run
> the
> > > whole lot on a single machine, and/or on 2 machines on a LAN, and/or
on
> 2
> > > machine across the Net.

> > > We currently have some experimental code working with DCOM, and all is
> > > working well.

> > > Now, with .NET just around the corner, we are wondering if "COM" is
the
> > > direction we should be taking. We've looked at the Beta of VS-NET, and
> > > VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine,
and
> it
> > > runs...
> > > All the documentation seems to indicate that using the new
"attributes"
> > > makes "COM programming easier", and that (D)COM for RPCs is still
valid,
> > but
> > > thats not what I am hearing from people supposedly in the "know".

> > > My question is: Is (D)COM still a valid, and acceptable way to remote
a
> > > ClientUI from the ServerObjects, is there a better way? Is Microsoft
> > telling
> > > us we should drop COM, and use the .NET framework instead (and what
> doies
> > > that even mean? Does it mean "use NET objects on the
> > > CommonLanguageRuntime"?)

> In .NET, you would have a couple of options. You could use object
remoting,
> which has a model that is similar to DCOM, in that you have static
> connections to objects.

> Or, you could use Web Services, which is a connectionless protocol, and
uses
> SOAP to send XML information across http.

> Which one would work best for you depends upon your architecture and
needs.
> If you're planning on running across the internet (and not a local net),
> SOAP can make life a lot easier, as you don't really have the DCOM setup
> issues.



Sun, 15 Jun 2003 15:01:16 GMT  
 .NET: COM vs NET
do you really care? Consider your UI - is it Web base, or VB or x/motif or
whatever!? If its only 10% and properly decoupled from your core
application, I'm sure it doesn't exactly matter what technology you use for
display, and besides general thinking on how it will look to the user, you
don't have to implement it for years.

The same applies to the distribution layer - DCOM/.NET/EJB/CORBA.. who
cares! Decide now on how you want it to be accessed (cosider things like
state and connection-oriented v connectionless, etc) and you can change the
distribution layer to be whatever is in vogue 4 years down the line.

Cheers, Andy.


Quote:
> Hi All,

> We are starting a large new project with C++, with an intended release
date
> of 2005. We are starting completely "from scratch", from design up. (or is
> that design down?)

> We intend to have:
>  * 80% of the code as pure, portable, C++ objects,
>  * 10% of the code as a simple client side UI app,
>  * and 10% of the code as some sort of COM layer that allows us to run the
> whole lot on a single machine, and/or on 2 machines on a LAN, and/or on 2
> machine across the Net.

> We currently have some experimental code working with DCOM, and all is
> working well.

> Now, with .NET just around the corner, we are wondering if "COM" is the
> direction we should be taking. We've looked at the Beta of VS-NET, and
> VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
> runs...
> All the documentation seems to indicate that using the new "attributes"
> makes "COM programming easier", and that (D)COM for RPCs is still valid,
but
> thats not what I am hearing from people supposedly in the "know".

> My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way? Is Microsoft
telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)

> Any thoughts much appreciated,
> Robert.



Wed, 25 Jun 2003 00:27:30 GMT  
 .NET: COM vs NET


Quote:

> Now, with .NET just around the corner, we are wondering if "COM" is the
> direction we should be taking. We've looked at the Beta of VS-NET, and
> VC.NET in particular. My VC6 DCOM code compiles thru VC7 just fine, and it
> runs...
> All the documentation seems to indicate that using the new "attributes"
> makes "COM programming easier", and that (D)COM for RPCs is still valid,
but
> thats not what I am hearing from people supposedly in the "know".

> My question is: Is (D)COM still a valid, and acceptable way to remote a
> ClientUI from the ServerObjects, is there a better way? Is Microsoft
telling
> us we should drop COM, and use the .NET framework instead (and what doies
> that even mean? Does it mean "use NET objects on the
> CommonLanguageRuntime"?)

Depends on what you are using DCOM for. If you want connections over the
internet or between several private networks on a WAN, then DCOM is not for
you. If you are on a LAN, then DCOM is fine, it maintains the connections
for you making sure that dead clients do not turn objects into zombies, has
security integrated into NT etc.

It is not clear yet what services MS will come up with in its '.NET
strategy', I'm not even sure I know what it is anyway. Thus it pays to be as
flexible as possible. If you have an experienced C++ team and intend to use
facilities that .NET does not cater for then it makes sense to do unmanaged
C++ development. But keep your options open and make sure that any class
that is useful has COM support (class factory, interfaces), this will allow
you to use the same _binary_ in managed code if you decide to move over to
.NET later.

Richard
--
www.grimes.demon.co.uk



Fri, 25 Jul 2003 00:43:57 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. VS.NET Enterprise Vs VS.NET Professional

2. Changes in C# between VS.NET Beta and VS.NET Final versions

3. C# .NET vs C++ .NET

4. VS.NET 2003 VC++ and .NET controls

5. Visual C# .NET Standard vs. Visual Studio.NET

6. CE.NET and VS.NET

7. Is VS.net a .Net application?

8. VS.NET is slow on .net server

9. VS.NET and .NET Framework

10. ANN: Datacode ToolsLibrary.NET for VS.NET (true inputcontrols)

11. VB.NET vs. C#.NET

12. Studio .NET CRAP, VS .NET SUCKS BIG TIME

 

 
Powered by phpBB® Forum Software