Re: 1st hosting of objects, new(), etc.

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Mike (vimakefile_at_yahoo.com)
Date: 08/17/04 

Date: Tue, 17 Aug 2004 14:25:22 -0700

"Mike" <vimakefile@yahoo.com> wrote in message
news:eBLRC7JhEHA.596@TK2MSFTNGP11.phx.gbl...
> At least for this question, looks like not to call rWKCT and call
> Activator.GetObject for remote, and new() for local.

Hmm. I may be wrong here.

Also, rWKST doesn't even take a factory delegate, so you can't manage your
own singelton. E.g., it looks like you can be sure .Net will only create one
of your objects, but this will be a different one from a singleton you may
already have created for your own use.
It looks like the only way around this is to create a wrapper class that
includes that target class as a member.
Seeing c# doesn't support delgation, this means you'd have to manually
delegate the public methods to the inner object.

>
> > (Or execute remote versions on several different machines.)
> >
> > The client-server model seems too restrictive and is no more easily
> > understood than something like an agent model -- here you'd simply tell
> the
> > object where you want its state to be held (which you could .Move) and
> where
> > you wanted to execute a method, which could be in different places,
> although
> > you'd have to stub back for any objects that weren't migrated with the
> > object. There exist such beasts for Java, but I can't seem to find any
for
> > .Net.
> >
> > mike
> >
> > "Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
> > news:eLuZDbJhEHA.2764@TK2MSFTNGP11.phx.gbl...
> > > The New statement will create a local object on the server
> application
> > > even if you have published a wellknown object of that type. On the
> client
> > > application once you have registered a wellknown type in that app
domain
> > it
> > > makes sense that New would attempt to create a remote object.
> > > Your issue is that either one of your applications can act as a
> > server.
> > > You might want to reconsider that. I think it is a bit risky to have
an
> > > ASP.Net application dependent on a remote object in a Windows Forms
> > > application that can be shut down at will. With that said you might
> want
> > to
> > > try something like the pseudo code below in each application, I am not
> > sure
> > > if it would work:
> > >
> > > obj1 = New Myojbect - Create a local instance of the object
> > > bUseLocalObj = true
> > > Register MyObject as a wellknown type
> > > try
> > > obj2 = attempt to create another instance of your object (obj2 -
> > should
> > > be remote instance)
> > > bUseLocalObj = false
> > > catch
> > > if error, remote object is not available, probably not been
> published
> > > Marshal obj1 to a URI
> > > end try
> > >
> > > if not bUseLocalObj then obj1 = obj2 (obj1 and obj2 are both
> Myobject
> > > types, but obj2 is a proxy, so not sure what would happen)
> > >
> > > Use obj1 throughout your application (may or may not be a proxy
based
> > on
> > > what happened above)
> > >
> > >
> > > Good luck.
> > >
> > > Thanks,
> > >
> > > Sam
> > >
> > >
> > > --
> > > _______________________________
> > > Sam Santiago
> > > ssantiago@n0spam-SoftiTechture.com
> > > http://www.SoftiTechture.com
> > > _______________________________
> > > "Mike" <vimakefile@yahoo.com> wrote in message
> > > news:eRSlNz$gEHA.3272@TK2MSFTNGP11.phx.gbl...
> > > > I'd like to have the first-running application that references my
> object
> > > > host a singleton server for the app's lifetime, and I'd like the
> hosting
> > > > application to use a local (non-remoted, same process) version of
the
> > > > object.
> > > > For instance, if my winforms app is the first app to need the
object,
> it
> > > > will do a registerWellKnownServerType on a singleton that is also
used
> > > > locally, and if an IIS application on the same machine runs first,
> I'll
> > > > create a the local object and cache it in the ASP.Net Application
> object
> > > and
> > > > then register it. Otherwise, if one or the other is running, it will
> use
> > a
> > > > remoted version. Is it possible to have this
> > > > local-and-remoted-access-to-the-same-singleton scenario work? (With
> > > > appropriate lock()'s in case the local and remote context threads
muck
> > > with
> > > > state at the same time.)
> > > >
> > > > The impetus is that I'd like a management console to be able to run
> w/o
> > > IIS
> > > > active, but most of the time I want the IIS application to host the
> > object
> > > > and have fast, local access to it. In the case that I run one or
more
> > > > managment consoles from local or remote machines with IIS already
> > hosting
> > > > the object, they will connect to the already running object.
> > > >
> > > > One problem is .Net's choice of implicit remote creating via new()
> which
> > I
> > > > don't really like. It seems like before a
registerWellKnownClientType
> > "new
> > > > foo(...)" means one thing, and after the registration it means
> something
> > > > else - an explict Remote.Create( typeof(foo), ...) seems cleaner.
> Once
> > > > rWKCT is called, how do I create local, non-remote, non-singlton
> > versions
> > > of
> > > > the object if I wanted to?
> > > >
> > > > I guess in the case where the hosting app exits, it would cause an
> > > exception
> > > > on the client, or I could have the process stick around while there
> are
> > > > still non-timed-out clients (unless IIS gets aggressive with an
> > ostensibly
> > > > zombified process.)
> > > >
> > > > thanks,
> > > > mike
> > > >
> > > >
> > >
> > >
> >
> >
>
>