MSMQ - confused about COM - Invoke COM component (trigger rule)

[Leo Muller]

Okay,

I got confused here.
In order to get the messages out the MSMQ 3, on windows 2003, I need to
invoke a COM component (ProgID).
However, if I compile a class of .NET, and get a DLL, is this considered a
COM component?
If this is the case, should I register it? (against all .NET logic?). Or
because I call it through the ProgID it knows how to locate the DLL by
itself?

Could it be that I have to stick to my component from VB6?

Does anyone have an example of how to get messages from an MSMQ through .NET
code, invoked by the trigger on windows2003?

Thanks to anyone who can deconfuse me.

Leo

[bclegg]

Hi Leo,
From my reading (and not practical experience.)
You can create a .net component which is then registered with regASM
It is then available to the application that is expecting to see your
original Com component.
As a quick test, you could prototype a .Net component that references
your existing DLL and exposes its public interface.

Re: The MSMQ, System.messagin g name space provides the necessary classes
to create, read, write from queues.

I have just managed to get my first use of this going.

The only trap I found was not paying attention to the formatter used to
write and read the messages.
It was very easy to write messages to the queue but my reader would not
deserialise them.
FWIW.
Bob


Leo Muller wrote:

Okay,

I got confused here.
In order to get the messages out the MSMQ 3, on windows 2003, I need to
invoke a COM component (ProgID).
However, if I compile a class of .NET, and get a DLL, is this considered a
COM component?
If this is the case, should I register it? (against all .NET logic?). Or
because I call it through the ProgID it knows how to locate the DLL by
itself?

Could it be that I have to stick to my component from VB6?

Does anyone have an example of how to get messages from an MSMQ through .NET
code, invoked by the trigger on windows2003?

Thanks to anyone who can deconfuse me.

Leo