Transaction Servers & .NET

[cameron]

I know that you can still use MTS from .NET components via the COM+ interop
services provided by the .NET framework, but does anyone know if there are
any plans, by anyone, to develop a Transaction Server product based entirely
on .NET that doesn't rely on COM+.

I know it's not necessary, but it might be nice to have a system that has
the functionality provided by MTS that doesn't rely on COM+ at all.

Cameron

[markN]

I wondered the same thing. (BTW Isn't MTS now part of COM+?) It seems MS
is rushing .NET out with out updating COM+(MTS and MSMQ?) to be .NET+. Maybe
this is included in .NET.


"cameron" <daeva@visto.com> wrote:
>
>I know that you can still use MTS from .NET components via the COM+ interop
>services provided by the .NET framework, but does anyone know if there are
>any plans, by anyone, to develop a Transaction Server product based entirely
>on .NET that doesn't rely on COM+.
>
>I know it's not necessary, but it might be nice to have a system that has
>the functionality provided by MTS that doesn't rely on COM+ at all.
>
>Cameron

[cameron]

Yes - in Windows 2000 MTS has effectively been renamed to Component Services,
and it and COM+ are intimately related.

I wouldn't say though that MS are rushing out .NET, it has been in development
for over three years now, and the .NET framework does have a set of classes
dealing specifically with MSMQ. It can also interact with COM+ components
easily enough. What my real concern is is the Distributed Transactions capabilities
that MTS provides. There doesn't seem to be any initiative from MS to have
a fully .NET implementation of it, and as I say, it would be good to be able
to have a fully .NET system that has all the functinality that at present
still requires COM+/MTS.

Cameron

"markN" <mnuttall@nospam.com> wrote:
>
>I wondered the same thing. (BTW Isn't MTS now part of COM+?) It seems MS
>is rushing .NET out with out updating COM+(MTS and MSMQ?) to be .NET+.
Maybe
>this is included in .NET.
>

[Dave Harney]

Hi,

I've been trying to get a really complete answer to this question for
months.

Let's assume that I'm building a brand-new app from scratch and I don't have
any existing COM components that I need to reuse. Let's also assume that I
need distributed transactions, object pooling, DB connection pooling, queued
components, etc. I also want to use VB exclusively and I want all the .Net
features associated with CLR and the promise of "XCopy" for deployment.

We can clearly write a VB.Net object that has transaction capability under
..Net without creating a COM DLL like we did in VB6. The example I followed
created an object that can be managed under COM+ Applications in Component
Services.

At this point, I am confused as to what all the implications are in terms of
that object's capability and deployment procedure. Is there still some
reason I would go back to VB6 or C++ to create a COM DLL like we used to?
Am I not looking at this issue correctly?

Thanks, appreciate any insight.


"anil" <anil_study@yahoo.com> wrote in message
news:12fb01c186b3$6f3fba80$a5e62ecf@tkmsftngxa07...
> Hi Folks
>
> I come to know that to group "some classes generated in
> vb.net" , (to support transactions)we need to create a
> com+ application in component
> services.
>
> It means we need to convert vb.net classes to com
> components using com .net interop wrappers.
>
> If we use interop wrappers then there will be performance
> issue cuz it consumes some resources as a new layer.
>
> If I want to support transactions for my components ,I
> guess direct generation of COM+ components is better
> than generation of vb.net classes and interop
> wrapper and com+ application.
>
> Am I right?
>
> If so what is the fun of .net?
>
> MSDN says that if possible create .net classes for com
> components instead of ccw wrappers.
> If I want to support JIT,scalability,Transactions COM+ is
> best right?
>
> what do you guys think?
>
> Please correct me if I am wrong.
>
> Thanking you
> Anil
> .
>
>


"cameron" <daeva@visto.com> wrote in message
news:3ba2ade3$1@news.devx.com...
>
> Yes - in Windows 2000 MTS has effectively been renamed to Component
Services,
> and it and COM+ are intimately related.
>
> I wouldn't say though that MS are rushing out .NET, it has been in
development
> for over three years now, and the .NET framework does have a set of
classes
> dealing specifically with MSMQ. It can also interact with COM+ components
> easily enough. What my real concern is is the Distributed Transactions
capabilities
> that MTS provides. There doesn't seem to be any initiative from MS to
have
> a fully .NET implementation of it, and as I say, it would be good to be
able
> to have a fully .NET system that has all the functinality that at present
> still requires COM+/MTS.
>
> Cameron
>
> "markN" <mnuttall@nospam.com> wrote:
> >
> >I wondered the same thing. (BTW Isn't MTS now part of COM+?) It seems MS
> >is rushing .NET out with out updating COM+(MTS and MSMQ?) to be .NET+.
> Maybe
> >this is included in .NET.
> >
>
>