Re: What about CAO?

I'm totally with you up until "take care of lifetime issues" - that's an
area I'm fuzzy on. Can you give me one more tiny push of where I should look
to control the lifetime of these objects? I haven't found any
good/understandable references! :-(

And also, how I'm doing this now with Activator.GetObject() - methods work
fine, it seems that it's not keeping state because properties aren't keeping
their values. So if I have the remoting service set as SingleCall - it's
like it creates an object for every time I make a reference to a remoting
object - which seems, utterly ridiculous. And when I set it to Singleton, it
keeps state - but only has one state for ALL callers that use it, which is
obviously not right either.

I just want a remoting object to act like a local object - you would've
thought that would be the very first thing they would've worked on, when
designing this technology!!



"Helge Lenuweit" <""nospam\"@nospam@xxxxxxxxxxxx"> wrote in message
news:ddf434$vf9$1@xxxxxxxxxxxx
> Hi,
>
> using an interface-only approach, it's not possible to instantiate a new
> CAO object on the client side - you can't just use "new MyObject(...)"
> because the implementation is only available on the server.
>
> One possible solution to this is to extend your shared assembly with an
> interface for a SAO object. It needs a single method which returns a new
> instance of the CAO, like GetCAO(). Now implement this interface on the
> server and expose the object. Then get a reference of this object on the
> client via GetObject (you do not instantiate the object, you get a proxy
> of the existing one from the server - so it will work with the interface
> only on the client).
>
> Now that you have the SAO instance on the client, call its method that
> returns the CAO. Make sure to appropriately take care of lifetime issues
> and this object will retain state.
>
> Regards,
> Helge
>
>
> RCS schrieb:
>> So have a successful remoting environment setup with a shared assembly
>> that stores the interfaces-only that are available. The client has a
>> copy, and the remoting server has that, and also has objects that are
>> offerred, that implement those interfaces.
>>
>> On the client, I am using Activator.GetObject() to create the object, but
>> it's not keeping state. To be more specific, I'll set properties, and
>> they don't keep. It's as if every call is a new call to the server.
>>
>> So it looks like from everything I've read, that I should be
>> instantiating these objects different, as CAO - but I can't seem to find
>> the syntax for this. For example, here is my function for creating an
>> object:
>>
>> Private Function GetRemotingObject(Of typ)() As typ
>>
>> Dim InterfaceName As String = GetType(typ).ToString()
>>
>> Dim intLastPos As Int16 = InterfaceName.LastIndexOf(".")
>>
>> If intLastPos > 0 Then
>>
>> InterfaceName = InterfaceName.Substring(intLastPos + 1,
>> (InterfaceName.Length - intLastPos) - 1)
>>
>> End If
>>
>> Return CType(Activator.GetObject( _
>>
>> GetType(typ), _
>>
>> "http://"; + WEBSERVER + "/WASRemoting/" + InterfaceName + ".rem") _
>>
>> , typ)
>>
>> End Function
>>
>>
>>
>> Sorry for the VB, but the front-end needed to be that way, because I'm
>> whipping up examples for other duh-velopers. So how else could I
>> instantiate this object via remoting to make it CAO, and ideally - keep
>> state??
>>
>>


.

Relevant Pages

  • Re: What about CAO?
    ... One possible solution to this is to extend your shared assembly with an interface for a SAO object. ... It needs a single method which returns a new instance of the CAO, ... Then get a reference of this object on the client via GetObject (you do not instantiate the object, you get a proxy of the existing one from the server - so it will work with the interface only on the client). ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Return argument has an invalid type - does remoting work reliably at all?
    ... interface back to the client as .NET Remoting will try to create it (not ... BUT I doubt it will allow you to cast it to the interface in your DLL. ... Activate an interface but that is different than remoting an interface. ... > .Net Remoting is really a pain to work with for me. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Can I create a remote object without a DLL on the client?
    ... Remoting is not a means of deploying objects/assemblies or of loading ... If you want a client app that downloads assemblies dynamically from a remote ... > have the object on the client, why wouldn't I just instantiate it? ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: .net remoting Performance Issue (Urgent)
    ... MemoryStream and BinaryFormatter to do this....take the position of the ... > about how to control remoting windows serviceto support STA. ... >> from the client and not actually the time for the calculation. ... >> is an interface which moves a lot of data I provide a Sockets based ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: third post: Marshal by value remoting
    ... client again).So far so good.It is exactly what I want.I'd like to know how ... > use it is going to determine if remoting is involved or not. ... > on the server and returned to you. ... > If you instantiate the object locally and use it locally without involving ...
    (microsoft.public.dotnet.framework.remoting)
Loading