.NET Remoting - client development/design-time and run-time requirements

I have a .NET Remoting solution. My remote objects are hosted in a Windows
Service on my remote server. My remote objects are configured for SingleCall
Server Activation, so instantiation on the client results in a proxy object
and the remote objects aren't instantiated on the server until a method is
called on the proxy object. My client is a hybrid ASP/ASP.NET web
application. The ASP pages access the .NET Remoting objects via a custom
..NET Factory class I built that handles the COM Interop and makes the
Remoting call to instantiate the remote objects. Once the ASP page has the
proxy remote object, it no longer needs to go through the Factory class but
makes its calls directly to the remote object through the proxy object.The
ASP.NET pages can instantiate the remote objects directly with the New
keyword.

It seems that at development/compile time, the ASP.NET portion of the client
web application needs to have a copy of the DLL that defines the remote
objects in its bin folder or it won't compile. Is that accurate?

Does the client web application (ASP and/or ASP.NET) need to have the DLL
that defines the remote objects anywhere on the client machine at runtime?
When an ASP.NET page (or my Factory class) instantiates a new remote object
via the New keyword (remoteObject = new MyRemoteObject()) where does the
information that defines the proxy class come from? Does it need to be on
the client machine or does the client machine get it from the remote server?

The reason I'm asking is that I recently updated several methods in my
remote object to take an additional, optional parameter. Since it was
optional, I had thought I could update my remote server first and then
update my client machines and that old clients would work correctly while
they waited to be updated. But they didn't. They reported error
number -2146233077, "8 arguments were passed to
'MyRemoteObject::MyRemoteMethod'. 9 arguments were expected by this method.
If I drop an updated DLL (one that defines the remote classes with the new
optional parameter) on the client machines without changing the client pages
that are making the actual calls (so they're still passing the same number
of arguments), the error goes away.

This will necessarily change my deployment strategy and suggests I need to
somehow simultaneously update my remote service and all of my client web
servers, even for the addition of an optional parameter. Is that correct?

Thanks,
Zoe


.

Relevant Pages

  • Re: Synchronized objects
    ... > proxies to remote objects and the appropriate one to use depends on how ... > plan to use the object in your clients and on your server. ... > 1) Does every client that connects need to access the same Foo instance ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: lost responsiveness
    ... > objects are in the same dll. ... > the host runs with all the responsiveness. ... > when the existing clients try to access one of the 4 remote objects again, ... > try to run an additional client. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: remoting & security.
    ... authentication of clients you might want to host your remote objects in IIS. ... object of the client. ... Sam Santiago ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: .NET Remoting - client development/design-time and run-time requirements
    ... Service on my remote server. ... proxy object and the remote objects aren't instantiated on the server until ... My client is a hybrid ASP/ASP.NET ... remote object to take an additional, optional parameter. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Synchronization in .Net Remoting
    ... > different locks on different remote objects before performing any real ... the client should acquire all the ... > (which may on different remote objects), then the client can perform some ... >> control the synchronization, especially via a remote method call. ...
    (microsoft.public.dotnet.distributed_apps)