Re: C# solution in MTS / MSMQ?



<DIV>&quot;Willy Denoyette [MVP]&quot; &lt;willy.denoyette@xxxxxxxxxx&gt; wrote in message news:Oo7NTW2zGHA.1300@xxxxxxxxxxxxxxxxxxxxxxx</DIV>>
"David Browne" <davidbaxterbrowne no potted meat@xxxxxxxxxxx> wrote in
message news:%23VTzQvwzGHA.5048@xxxxxxxxxxxxxxxxxxxxxxx
|
|
| <DIV>&quot;Jon Davis&quot; &lt;jon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx&gt; wrote
| in message news:OFVXVHtzGHA.5072@xxxxxxxxxxxxxxxxxxxxxxx</DIV>> Can a
| solution built in C# utilize MSMQ and/or MTS?
| >
| > If so, does this make the training material I already have on MSMQ and
MTS
| > in the context of VB6 an appropriate prerequisite foundation before
| > learning how to build C# solutions on MSMQ / MTS, if I already know VB6
as
| > well as C#?
|
|
| Also be aware that .NET has much less need of the services provided by
MSMQ
| and COM+ (formerly MTS), than VB6 did. Each of these platform technologies
| is still sometimes useful, and there is good support in the .NET framework
| for them, but they are no longer the "bread and butter" of enterprise
| applications.
|
| David
|

Not sure where you get this idea from, what are the alternatives offered by
.NET? How would you implement enterprise like applications without resorting
to System.EnterpriseServices and System.Messaging (COM+ and MSMQ wrappers)?



Ok. EnterpriseServices (COM+) basically offers a bunch of services to applciations:

Object Lifetime Management
Threading
Transaction Management
Distributed Components

You can do all of this in .NET without the help of COM+. The "COM" in COM+ should remind you that COM+ is an application server designed to service an earlier generation of components.

..NET features such as

System.Threading
System.Transactions
Windows Communication Foundation (or .NET Remoting and web services)
..NET's OO functionality (constructors, singletons, thread agility)

Really make COM+ redundant.

For MSMQ, it's still a useful option for guaranteed delivery messages, but SQL Server Service Broker is a better choice for many enterprise applications. Having the persistent state of the application stored in one place is a great advance over storing "messages" in the file system on the application server, and "data" in the database.

See, EG

O COM+, Where Art Thou?
Rockford Lhotka

It is easy to say that EnterpriseServices in Microsoft .NET gives us access to all the COM+ features. While this is accurate, it really isn't sufficient because it may lead you to believe that you should just continue to use COM+ services in Microsoft .NET just as you did in COM, only with a different name.

The reality is that some of the overwhelmingly positive benefits COM+ offered to COM development aren't so overwhelmingly positive in Microsoft ..NET. In other cases, features of COM+ that were unavailable to Visual Basic 6.0 developers are fully accessible when developing in Visual Basic .NET.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet04232002.asp


Especially with .NET 3.0 what enterprise application requirement do you need COM+ for anymore?

David


.