Re: Remoting and COM+

Ian Harding wrote:
I have a COM+ application, which acts as a remoting server. The .NET assembly contains two COM visible objects - one is trigger by a service to load a config file and start listening for remoting clients, the other is used in remoting calls (there is another object which is the actual remoting component because it seems a class cannot be a remoted object and serviced component).

For installation, I use regasm /codebase, then gacutil to register the .NET assembly, then regsvcs to add the components to the COM+ application (it's an existing application).

On one server, this is enough, and clients can create and make use of the remoted object. On another server (both are Windows 2003, no SP), the remoting configuration object reports a successful start, but clients are unable to use the remoted object. Instead an exception is thrown indicating that my assembly or one of its dependencies was not found.

The fact that I have used regasm /codebase _or_ GACed the assembly and all of its dependencies should mean there won't be a problem. I added the folder storing the assembly and dependencies to the system path - still no joy. In desperation I put the assembly and dependencies into the Windows\System32 folder - suddenly it started working.

I have checked and double checked that all file versions match between the two servers and all clients. I removed the application files and configuration from both servers and started from scratch, one step at a time, copying exactly what I did on both machines. Still the same situation - on one server the application will not work unless all of the .NET files are in Windows\System32!

I don't understand what's going on.  Please can someone help!

Thank you
Ian

I've worked it out. The remoting configuration file needs to specify the assembly version, culture, and public key in order to load the assembly from the GAC.

For example, this is what I started with, that didn't work:

  <system.runtime.remoting>
    <application name="EngineSupport">
      <service>
        <wellknown mode="SingleCall"
          type="<remote class>,<assembly name>"
          objectUri="<uri>" />
      </service>
      <channels>
        ...
      </channels>
    </application>
  </system.runtime.remoting>

This is what I had to change it to:

<system.runtime.remoting>
<application name="EngineSupport">
<service>
<wellknown mode="SingleCall"
type="<remote class>,<assembly name>,Version=<x.x.x.x>,Culture=<culture>,PublicKeyToken=<key>"
objectUri="<uri>" />
</service>
<channels>
...
</channels>
</application>
</system.runtime.remoting>

I don't understand why this is necessary. Surely if I don't specify version, culture, key then _any_ assembly that matches the specified name and contains the requested class should be loaded from the GAC.

This is certainly going to be an inconvenience for customers to have to change version numbers in their configuration files every time we release a new version.

Ian
.

Relevant Pages

  • Re: COM+ Hölle
    ... > die Kommunikation zwischen Server und den Clients. ... > Clients nutzen (anfangs dachten wir noch an eine simple TCP/IP ... die Wrapperklasse - verschiedene Vorteile: ... Remoting innerhalb des .NET-Frameworks ist aber inzwischen schon ...
    (microsoft.public.de.vb)
  • Re: Remoting and DataSets
    ... It is a wrong approach unless you are sure that your server ... insert/update/delete statements in the .NET remoting server). ... updates back to the server or handling these. ... It depends on how many clients and network types. ...
    (microsoft.public.dotnet.framework.remoting)
  • RemotingException.
    ... makes a call to a remoting server to get information on what the page should ... customErrors in the server's .config file. ... An unhandled exception occurred during the execution of the ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Unknown clients
    ... You should be able to supply all the information in your config file using ... password exist on both machines involved in the remoting conversation. ... > For some strange reason, when using supplied credentials, you have to ... > assign the "machineName" on the server side to match it's public IP. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: remoting cross platform compatibility
    ... I really had the idea that it would be possible to let my remoting ... acts as a server for underpowered clients ... > However, if you're thinking of using non-.NET clients, then I'd recommend ... >>what i exactly need to change in my server config file ...
    (microsoft.public.dotnet.framework.remoting)