469,645 Members | 1,148 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,645 developers. It's quick & easy.

C# solution in MTS / MSMQ?

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#?

Jon
Sep 2 '06 #1
11 3357
You can build enterprise-level applications using MSMQ and
EnterpriseServices. Your VB6 experience, however, is likely to be of limited
usefulness. A prime example is that you are referring to "MTS" a term which
hasn't been used by Microsoft for over 5 years.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Jon Davis" wrote:
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#?

Jon
Sep 3 '06 #2


<DIV>&quot;Jon Davis&quot; &lt;jo*@REMOVE.ME.PLEASE.jondavis.net&gt; wrote
in message news:OF**************@TK2MSFTNGP03.phx.gbl...</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

Sep 3 '06 #3

"David Browne" <davidbaxterbrowne no potted me**@hotmail.comwrote in
message news:%2****************@TK2MSFTNGP05.phx.gbl...
|
|
| <DIV>&quot;Jon Davis&quot; &lt;jo*@REMOVE.ME.PLEASE.jondavis.net&gt; wrote
| in message news:OF**************@TK2MSFTNGP03.phx.gbl...</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)?
Willy.
Sep 3 '06 #4


<DIV>&quot;Willy Denoyette [MVP]&quot; &lt;wi*************@telenet.be&gt;
wrote in message news:Oo**************@TK2MSFTNGP05.phx.gbl...</DIV>>
"David Browne" <davidbaxterbrowne no potted me**@hotmail.comwrote in
message news:%2****************@TK2MSFTNGP05.phx.gbl...
|
|
| <DIV>&quot;Jon Davis&quot; &lt;jo*@REMOVE.ME.PLEASE.jondavis.net&gt;
wrote
| in message news:OF**************@TK2MSFTNGP03.phx.gbl...</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/de...et04232002.asp
Especially with .NET 3.0 what enterprise application requirement do you need
COM+ for anymore?

David
Sep 3 '06 #5
See inline.

Willy.

"David Browne" <davidbaxterbrowne no potted me**@hotmail.comwrote in
message news:e4**************@TK2MSFTNGP03.phx.gbl...
|
|
| <DIV>&quot;Willy Denoyette [MVP]&quot; &lt;wi*************@telenet.be&gt;
| wrote in message news:Oo**************@TK2MSFTNGP05.phx.gbl...</DIV>>
| "David Browne" <davidbaxterbrowne no potted me**@hotmail.comwrote in
| message news:%2****************@TK2MSFTNGP05.phx.gbl...
| |
| |
| | <DIV>&quot;Jon Davis&quot; &lt;jo*@REMOVE.ME.PLEASE.jondavis.net&gt;
| wrote
| | in message news:OF**************@TK2MSFTNGP03.phx.gbl...</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

This is not the same thing, COM+ Threading services are attribute based
(just like all COM+ services) little or no threading code to write it's all
taken care of for you.

| System.Transactions
Yep, this is really the only service pulled from COM+, note that both use
MSDTC when escalating to a distributed transaction.
| Windows Communication Foundation (or .NET Remoting and web services)
| .NET's OO functionality (constructors, singletons, thread agility)
|

WCF is not released yet, and Remoting serves other purposes and it requires
..NET at both ends (not to talk about what it lacks), WCF will build on COM+
for some of it's services (at least for V1 of NetFx V3).

| Really make COM+ redundant.
|

Well, I have to disagree,
How about object pooling, component activation and launch support,
security services like "access and activation security control","private
components" "Identity selection" ...,
distributed components,
COM+ partitions with Active Directory Services integration ,
automatic or user controled application recycling,
application control (pausing/disabling),
run as a Windows service,
low memory activation gates,
Debugging features (Process Dump).....?
and this, all attributed, no or little code to write. And don't forget the
reduced management overhead, all component services & attributes can be
controled from native clients and are scriptable.
| 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.

I tend to disagree, SQL server is a separate product, it's not part of the
core OS services, nor is the Broker API part of .NET, and when you need
redundency (who doesn't want it?) it's even more expensive. And let's not
talk about administrative overhead and performance.
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/de...et04232002.asp
|
Sorry, this say's nothing "aren't so overwhelmingly" what is meant with,
and why should it be overwhelmingly ?
.... on the other hand - <features of COM+ that were unavailable to Visual
Basic
| 6.0 developers are fully accessible when developing in Visual Basic
..NET.- that's great isn't it?


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

Not sure, it's certainly a departure from COM+ as technology and it offers a
lot more (albeit a number of features are still missing), but as it's not
released yet, you can hardly call it "enterprise ready", (even V2 isn't yet
that widely accepted in the enterprises, let alone V3), and IMHO it targets
Vista and Longhorn more than W2K3, it will take years before it will and the
first release will use COM+ for a number of it's "enterprise services" (MSMQ
and COM+ integration services).

Willy.



Sep 3 '06 #6
Redundant or not, David, there are people who are still supporting MSMQ and
COM+ while also implementing C# solutions, and I am trying to figure out
whether there is a migration path to .NET v2 architecture that does not
entail dropping all prior investments in Windows DNA.

Jon
Sep 4 '06 #7

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:Om**************@TK2MSFTNGP05.phx.gbl...
| Redundant or not, David, there are people who are still supporting MSMQ
and
| COM+ while also implementing C# solutions, and I am trying to figure out
| whether there is a migration path to .NET v2 architecture that does not
| entail dropping all prior investments in Windows DNA.
|
| Jon
|
|

All COM+ services are well integrated in .NET, System.EnterpriseServices and
System.Messaging are the namespaces that holds all the classes you need to
implement COM+/MSMQ (DNA) applications/components using C# or VB.NET. It
offers a rather smooth migration path because both .NET and native
applications use the same underlying technology, that means that you can mix
and match native and/or managed applications with native and/or managed
components. The COM+ and MSMQ wrapper classes (System.EnterpriseServices and
System.Messaging) are part of the existing and upcoming framework, WFC which
is part of the upcoming netfx3 is not meant to replace the existing
framework, it extends the existing technology with (Industry) standards
based (WS-* based protocols and services) distributed technology. It also
offers an integration path, so that WCF based applications will be able to
work with the current set of COM+/MSMQ based technologies. Now whether you
should migrate to .NET v2 now, or wait for Netfx3 is a question that you
have to answer, it depends on the size of the existing code, the need to
change the code (changing business logic or additional functionality)
etc..., but IMHO it's better to investigate a (planned) migration to .NET V2
now (you can't keep your VB6 code do you?) while keeping an eye on Netfx3.

Willy.

Sep 4 '06 #8


<DIV>&quot;Willy Denoyette [MVP]&quot; &lt;wi*************@telenet.be&gt;
wrote in message news:%2****************@TK2MSFTNGP04.phx.gbl...</DIV>See
inline.
>
Willy.

"David Browne" <davidbaxterbrowne no potted me**@hotmail.comwrote in
message news:e4**************@TK2MSFTNGP03.phx.gbl...
|
|
| <DIV>&quot;Willy Denoyette [MVP]&quot;
&lt;wi*************@telenet.be&gt;
| wrote in message news:Oo**************@TK2MSFTNGP05.phx.gbl...</DIV>>
| "David Browne" <davidbaxterbrowne no potted me**@hotmail.comwrote in
| message news:%2****************@TK2MSFTNGP05.phx.gbl...
| |
| |
| | <DIV>&quot;Jon Davis&quot; &lt;jo*@REMOVE.ME.PLEASE.jondavis.net&gt;
| wrote
| | in message news:OF**************@TK2MSFTNGP03.phx.gbl...</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

This is not the same thing, COM+ Threading services are attribute based
(just like all COM+ services) little or no threading code to write it's
all
taken care of for you.

| System.Transactions
Yep, this is really the only service pulled from COM+, note that both use
MSDTC when escalating to a distributed transaction.
| Windows Communication Foundation (or .NET Remoting and web services)
| .NET's OO functionality (constructors, singletons, thread agility)
|

WCF is not released yet, and Remoting serves other purposes and it
requires
.NET at both ends (not to talk about what it lacks), WCF will build on
COM+
for some of it's services (at least for V1 of NetFx V3).

| Really make COM+ redundant.
|

Well, I have to disagree,
How about object pooling, component activation and launch support,
security services like "access and activation security control","private
components" "Identity selection" ...,
distributed components,
COM+ partitions with Active Directory Services integration ,
automatic or user controled application recycling,
application control (pausing/disabling),
run as a Windows service,
low memory activation gates,
Debugging features (Process Dump).....?
and this, all attributed, no or little code to write. And don't forget the
reduced management overhead, all component services & attributes can be
controled from native clients and are scriptable.
. . ..

I think the question is not whether COM+ has a number of useful features: it
does. Or whether it's hard to use once you understand those features: it
isn't. Or whether you should continue to use it for scenarios it handles
well or applications that are coded for it: you should.

The issue is whether COM+ is still necessary for enterprise applications.
And if it's not necessary, whether a principle of economy might relegate its
use to a few scenarios for a majority of developers.

Remember before .NET, you had VB6, a safe and easy but low-functioning
language, and C++ a much more capable, but complicated and error-prone
language where simple coding errors cause process failure. Producing an
enterprise without COM+ in VB6 was nearly impossible, and in C++ it could be
very expensive. In either case, COM+ was a necessary technology for
building enterprise applications.

In .NET, without using Enterprise Services, you have IIS Web Applications,
IIS Web Service Applications and Windows Services. Every .NET developer
must understand how to build, deploy and manage these application types.
They are necessary. Enterprise applications can be built with just these
and the .NET languages and framework. They are sufficient.
David

Sep 5 '06 #9
Thanks for your responses.

So let me get this straight. In addition to doing things "the .NET way" in
C#, you *can* utilize MSMQ / COM+ (DNA) in C# by way of COM wrappers that
are accessible in the System.EnterpriseServices and System.Messaging
namespaces. Is this correct? I have not perused these namespaces, so whether
they are wrappers is also being asked about here for confirmation.

I am aware that .NET intends to deprecate DNA but wanted to see if legacy
support knowledge could be obtained in the context of C# and not just things
like VB6.

Thanks,
Jon

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:OF**************@TK2MSFTNGP03.phx.gbl...
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#?

Jon

Sep 5 '06 #10


<DIV>&quot;Jon Davis&quot; &lt;jo*@REMOVE.ME.PLEASE.jondavis.net&gt; wrote
in message news:Oz**************@TK2MSFTNGP06.phx.gbl...</DIV>Thanks for
your responses.
>
So let me get this straight. In addition to doing things "the .NET way" in
C#, you *can* utilize MSMQ / COM+ (DNA) in C# by way of COM wrappers that
are accessible in the System.EnterpriseServices and System.Messaging
namespaces. Is this correct? I have not perused these namespaces, so
whether they are wrappers is also being asked about here for confirmation.
Yes this is correct. Basically the .NET framework provides managed wrappers
for most important parts of the Windows operating system. System.Messaging
provides access to MSMQ and System.EnterpriseServices provides access to
COM+. In fact, with the attribute programming model for EnterpriseServices,
it's substantially easier to leverage COM+ in .NET than in any pre-.NET
language.

David

Sep 5 '06 #11
Thanks Willy. I guess the only question I have left is how much of the COM+
wrapper stuff in System.EnterpriseServices and System.Messaging is already
in NetFX v2. I am not exploring this for my particular work environment so
much as my career path, so I will definitely explore v3 WCF but in the short
term I need to respect and pay close attention to adoption levels of
existing NetFX implementations.

- Jon
Sep 5 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Andrew Gordon | last post: by
3 posts views Thread by Vai2000 | last post: by
10 posts views Thread by Jet Leung | last post: by
4 posts views Thread by SRLoka | last post: by
5 posts views Thread by Alex Nitulescu | last post: by
reply views Thread by yonirabin | last post: by
3 posts views Thread by yonirabin | last post: by
5 posts views Thread by Christian Schlemmer | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.