.NET Remoting and COM Interop Component

[Guest]

I'm running into another problem with my component.

I'm trying to use .NET remoting to avoid complex firewall issues.

I have a webserver which is the client machine and a database server which
is the server machine. On the database server I have created a Windows
Service which binds a component to port 42525 using TCP. The component
involved contains a reference to a VB6 DLL in which are some functions used
by the component.

On the webserver client I have a simple console application to test the
complete solution. I'm able to communicate with the remote object, though
when the remote object tries to create an instance of the VB6 DLL the client
application receives the error 'ClassFactory cannot supply requested class'.

I've tried to invoke the VB6 DLL from a simple console app on the server.
This results in invoking the VB6 DLL correctly. Problem seems to have
something to do with remoting.

Can anyone give me a clue?

 

[David Williams]

Remember that for Remoting to work on a component, that component needs
to be serializable. Most VB6 DLL's will not be serializable unless some
very complex programming was thought of during the creation of the DLL.
The only "normal" means of communicating with a VB6 DLL via remoting is
a wrapper class that exposes an interface for the remoting side and
provides the functionality on the server side.



HTH



David

 

[Guest]

Thank you David.

At the moment I have a .NET component which I expose for use by remoting.
This .NET class which will be used remotely invokes an instance of a certain
COM component. When trying to invoke other COM components like MSXML2 things
are working correctly on the client side, but this particular COM component
causes the 'ClassFactory' error.


--
Michel Smit
Atos Origin Nederland BV

Remember that for Remoting to work on a component, that component needs
to be serializable. Most VB6 DLL's will not be serializable unless some
very complex programming was thought of during the creation of the DLL.
The only "normal" means of communicating with a VB6 DLL via remoting is
a wrapper class that exposes an interface for the remoting side and
provides the functionality on the server side.



HTH



David

 

[Steven Cheng[MSFT]]

Hi Michel,

Glad to see you again.

As for this issue, I think it is likely an ActiveX component (.net interop)
issue in windows service environment rather than .net remoting specific.
Have you received my mail which has mentioned some general suggestion on
this?

Based on my research, there are some existing web threads discussign on
similar problem and most of them are caused by some script library
components. The reason why I suspect the problem specific to windows
service is because the error here "ClassFactory cannot supply requested
class" indicate that there is some problem get the component's interface
and this is possiblye specific to the windows service application
environment since it running in a deamon session with a service account
normally. Also, as you said that youv'e created a .ne wrapper
class(MarshalByRef ?) around the VB 6 component to serve the remoting
client, I don't think there should be any serialization problem(as long as
the return type from wrapper class is ok).

BTW, since this could be component specific, would you provide some
information about this VB6 dll's internal code logic and what is it doing
internally? Meanwhile, I will perform some test acorrding to your
description on my side to see whether this is a common reproducable issue.

Please feel free to let me know if there is anything else you wonder or if
there is any new update.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.