Connecting Tech Pros Worldwide Forums | Help | Site Map

.NET Remoting vs COM+ Serviced Component

=?Utf-8?B?QkY=?=
Guest
 
Posts: n/a
#1: Apr 19 '07
I am currently working on moving our business objects into COM+ serviced
components. But in the process, there are too many changes such ComVisible
and serviced component does not support parameterized constructors. So I am
thinking whether I should change to use .NET remoting instead.

Have anybody else gone through this .NET remoting vs serviced component
comparison before? Which one is better?
Can .NET remoting support object pooling and other features provided by COM+.

By the way, I am not planning to use COM+ transaction control and security.

Thanks a lot.

Michael Nemtsev
Guest
 
Posts: n/a
#2: Apr 19 '07

re: .NET Remoting vs COM+ Serviced Component


Hello BF,

Object pooling is the COM+ feature.

Does only the COMVisibility attriribute inspur u to switch on Remoting? Or
smth else?

We've been using COM+ for 3 years and I found it more usable over remoting.
COM+ is faster in some scenarious and more flexible to be migrated to WCF.



---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

BI am currently working on moving our business objects into COM+
Bserviced components. But in the process, there are too many changes
Bsuch ComVisible and serviced component does not support parameterized
Bconstructors. So I am thinking whether I should change to use .NET
Bremoting instead.
B>
BHave anybody else gone through this .NET remoting vs serviced
Bcomponent
Bcomparison before? Which one is better?
BCan .NET remoting support object pooling and other features provided
Bby COM+.
BBy the way, I am not planning to use COM+ transaction control and
Bsecurity.
B>
BThanks a lot.
B>


=?Utf-8?B?QkY=?=
Guest
 
Posts: n/a
#3: Apr 19 '07

re: .NET Remoting vs COM+ Serviced Component


One major reason I am hesitating to user COM+ serviced components is because
serviced component does not support parameterized constructors. I need to
make lots of changes in my code.
The other one, which could cause issues in the future is that if a Class is
derived from Generic List, it cannot be a serviced component. Microsoft said
they have already fixed this issue. But I still have this problem in my
development environment.

Thanks a lot.


"Michael Nemtsev" wrote:
Quote:
Hello BF,
>
Object pooling is the COM+ feature.
>
Does only the COMVisibility attriribute inspur u to switch on Remoting? Or
smth else?
>
We've been using COM+ for 3 years and I found it more usable over remoting.
COM+ is faster in some scenarious and more flexible to be migrated to WCF.
>
>
>
---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/
>
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
>
BI am currently working on moving our business objects into COM+
Bserviced components. But in the process, there are too many changes
Bsuch ComVisible and serviced component does not support parameterized
Bconstructors. So I am thinking whether I should change to use .NET
Bremoting instead.
B>
BHave anybody else gone through this .NET remoting vs serviced
Bcomponent
Bcomparison before? Which one is better?
BCan .NET remoting support object pooling and other features provided
Bby COM+.
BBy the way, I am not planning to use COM+ transaction control and
Bsecurity.
B>
BThanks a lot.
B>
>
>
>
Closed Thread


Similar .NET Framework bytes