Re: .NET Remoting - client development/design-time and run-time requirements
- From: "Shailen Sukul" <shane@xxxxxxxxxxxxx>
- Date: Wed, 17 Jan 2007 16:32:09 +1100
See my comments below:
HTH
--
With Regards
Shailen Sukul
..Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au
"Zoe Hart" <zoehart@xxxxxxxxxxxxxxxx> wrote in message
news:eziaJgYOHHA.1248@xxxxxxxxxxxxxxxxxxxxxxx
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?
That is true. Best practice is to separate the definition of the CAO objects
into an interface assembly and reference it both from the client and the
server.
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?
YES. The client app needs to know about the CAO objects that it is
receiving.
You could choose to use an interface assembly as suggested earlier to avoid
security risks.
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.
YES that is the correct behaviour. You could have chosen to OVERLOAD that
the method if you wanted to avoid updating the old dll.
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?
YES. You cannot change the signature of a method and expect things to be ok.
Optionally you could either overload a method, or release a new VERSION of
the server object (in which case you would still need to host the old
version).
Thanks,
Zoe
.
- References:
- Prev by Date: Re: How to handle the events raised from remote server object in clien
- Next by Date: Re: find out if client is connected / server is reachable
- Previous by thread: .NET Remoting - client development/design-time and run-time requirements
- Next by thread: InvalidCastException and Remoting version compatibility
- Index(es):
Relevant Pages
|
Loading
