"Valery Romanov" <vromanov@activewebservices.com> wrote in message
news:e9QzDxoUDHA.736@TK2MSFTNGP09.phx.gbl...
>
> Greetings!
>
> It seems we've caught the problem. The SERVER party COM+ component
> (MSMQTestServer.QC
> omponent) hadn't been installed on the CLIENT (caller) side! After we had
> registered the component on the both sides, communication worked fine!
> Why does the server component need to be registered on the client also
(it's
> public interface definition is not enough)? May be the moniker need
> definitions of object public methods to create a proxy for remote calls?
> Could we create a simple stub assembly with the same name and interface as
> remote COM+ object and register it on the client instead of the object
> itself, since the moniker string contains only name of the object:
> queue:.../new:MSMQTestServer.QC
> omponent? Server side assemblies may have different implementations and we
> don't want to register them all on the client.
>
> Actually we've got 3 assemblies:
>
> Client Party:
> TestClient.exe - Win32 application to invoke Queued Component
> Shared.dll - definition of Queued Component public interface
>
> Server Party:
> QComponent.dll - the COM+ component itself
> Shared.dll - the same definition of interfaces
>
> It doesn't seem to be enough. It seems we need QComponent.dll on the
client
> also.
>
> TestClient.exe:
> private void _SendMessage(string msg)
> {
> IQComponent iQc = (IQComponent)Marshal.BindToMoniker
>
(@"queue:formatname=direct=OS:ComputerName\PRIVATE$\msmqtestsvr/new:MSMQTest
> Server.QComponent");
>
> iQc.DisplayMessage (msg);
> }
>
> shared.dll:
> public interface IQComponent
> {
> void DisplayMessage(string msg);
> }
>
> QComponent.dll:
>
> [InterfaceQueuing(Interface = "IQComponent")]
> public class QComponent : ServicedComponent, IQComponent
> {
> public void DisplayMessage(string msg)
> {
> MessageBox.Show(msg, "Processing message");
> }
> }
>
> Does it make sense? What would be the best approach in our case?
>
> Thanks
>
> Valery,
> MCSD.NET, MCSD
>
>
>
>
>