Re: Run-time loading assembly on Server RO question

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Ken Kolda (ken.kolda_at_elliemae-nospamplease.com)
Date: 12/21/04 

Date: Tue, 21 Dec 2004 09:20:38 -0800

OK -- I understand what you're doing now. That said, I'm not sure why the
factory ever needs to load the assembly for the RO it's creating the proxy
for. I think you said all of the ROs have a common base class
(AbstractBaseObject), so your server should be able to use that type when
generating the proxy. In fact, your code snippet even showed this:

 public AbstractBaseObject GetObject(string objType)
{
      LoadConfigXml();

       //Create an SAO object
      AbstractBaseObject retObj = Activator.GetObject(....);
      return retObj;
}

That should create a proxy and return it to the client. The client can then
cast it to the appropriate type and do what it needs to do. Am I missing
something here?

Ken

"mtv" <mtv@discussions.microsoft.com> wrote in message
news:3E903F6D-6C83-45DD-9403-D929BA6AFDDA@microsoft.com...
> Ken:
>
> The model is this:
> Client --Remoting Call--> Factory --Remoting Call-->Remote Object
>
> Client always gets back RemoteBaseObject and then typecast it to its own
> type (the one client passed in by name). I think you got this.
>
> Factory, on client's call, loads xml file for details and remotely calls
> appropriate remote object. The newly created object is not an in-memory
> object of Factory. Instead, it's a WellKnown Singleton type of remote
object.
> The RO is infact a remote Singleton to the Factory. Once the Factory gets
> RO's proxy, it returns this proxy to client.
>
> Remote Object: as stated above, is always a Singleton RO. Hence, it can,
> infact, be a factory itself which will host in-memory CAOs. These ROs can
> live on different servers, as we want to have. And each RO may have its
> dependencies for their business needs; I cannot set the rule of not having
> them. Although I can require each RO (w/ its dep) must be compiled all
into
> only 1 dll per RO type, but that's a limitation.
>
> The whole reason of having this architecture is to provide plug-in
> capability to future development. We want to allow other developers later
on
> build their own Singleton ROs and then, all they need to do is providing
the
> xml info so our Factory know where/how to load their object.
>
> About the xml: Server/Port/Uri is needed to RO call to remote objects. So,
> in order to call Activator.CreateInstance/GetObject method, the factory
must
> load the RO's assembly & its dependencies first. At this time, I cannot
load
> them at runtime; I still have to make reference to those dll's at design
> time. That means everytime a new RO needs to be plugged into this
> architecture, I will have to recompile my Factory [server].
>
> My goal is somehow I can load appropriate RO's assembly and its
dependencies
> at run-time before I can call CreateInstance/GetObject. Or do I have to?
How
> can I do that?
>
> Thanks.
>
>
>
> "Ken Kolda" wrote:
>
> > I can undestand the purpose of the XML file to map type names to
assemblies
> > if the assembly info isn't being passed by the client. However, I don't
> > understand the uri/server/port portion. What do you use these values for
on
> > the server?
> >
> > Also, I'm not sure of the purpose of the three different assemblies.
From
> > the example you showed, I assumed you had defined a base class
> > (AbstractBaseObject) from which all of the classes in your assemblies
which
> > the server can load derive. So, the client passes as type name, you look
it
> > up in the XML mapping to get the appropriate assembly name, instantiate
an
> > instance of the class using Activator.CreateInstance() (casting it to
> > AbstractBaseObject) and pass it back to the client. The client, then,
would
> > only need the implementation of AbstractBaseObject. If that's not the
> > correct model, let me know what you're doing. If yu could provide the
flow
> > you envision from the client requesting the remote object to the time it
> > receives the object, that would be helpful.
> >
> > Ken
> >
> >
> > "mtv" <mtv@discussions.microsoft.com> wrote in message
> > news:CD95C8F0-18A0-45BA-B758-D77A0819818A@microsoft.com...
> > > My client code passed in the type name, and server side will
load/convert
> > to
> > > the right type. I have a look-up file (xml) on server side to
determine
> > > type/uri/server/port... enough to instantiate the object. And all of
these
> > > are working fine if the server asm references all object types the
client
> > may
> > > ask for.
> > >
> > > What I now want to do is at design time, server does not need to know
> > which
> > > object types it should be "ready" for, so it does not have to
reference
> > > appropriate dll's. And at run-time, it will look up its look-up file
for
> > the
> > > dll and load it before it instantiate the object. The problem is for
each
> > > remote object type, I have at least 3 dll's: abstract, implementation
and
> > > common interface dll's. How can I load all of them into AppDomain to
> > > instantiate the object. Or do I have to by using GetInstance?
> > >
> > > Thanks.
> > >
> > >
> > > "Ken Kolda" wrote:
> > >
> > > > First, in your call code for GetObject(), you should be using
> > > > Activator.CreateInstance() instead of Activator.GetObject(). The
former
> > > > would load the appropriate assembly an instantiate an object while
the
> > > > latter simply creates a proxy for a type -- I'm not even sure what
> > parameter
> > > > you could be passing to this function for the URI (the second
> > parameter).
> > > >
> > > > If all your client is passing to you is a type name, then you need
to
> > > > convert this so you can get a type name and an assembly name (or you
> > have
> > > > the client pass an assembly name as well). Then just pass these to
> > > > CreateInstance(). I'm not sure you need to do much more than that.
> > > >
> > > > Ken
> > > >
> > > >
> > > > "mtv" <mtv@discussions.microsoft.com> wrote in message
> > > > news:95969B3D-B914-46D8-949F-088579146550@microsoft.com...
> > > > > Hi all,
> > > > >
> > > > > I have a SAO that returns an object to remote client's call
> > > > > (MyFactory.GetObject(objectType)). I want to make the server part
> > dynamic
> > > > and
> > > > > plug-in[able], so I want to be able to load correct assembly
file(s)
> > based
> > > > on
> > > > > the "objectType" STRING that client passes in. Hence, I read from
a
> > config
> > > > > xml file for the data like this:
> > > > >
> > > > >
> > > > > ========================
> > > > > Server side:
> > > > > Configuration.xml file:
> > > > > <Types>
> > > > > <myObjectOne>
> > > > > <Server>...</Server>
> > > > > <Port>...</Port>
> > > > > ....
> > > > > <Type>namespace.namespace1.ObjectOneClass</Type>
> > > > > <Assembly>
> > > > > <dll>C:\ObjectOne\bin\ObjectOneAsm.dll</dll>
> > > > > <Dependency>
> > > > >
<File>C:\baseObject\bin\AbstractBaseObject.dll</File>
> > > > >
<File>C:\ObjectOneDep1\bin\ObjectOneDep1.dll</File>
> > > > >
<File>C:\ObjectOneDep2\bin\ObjectOneDep2.dll</File>
> > > > > <File>....</File>
> > > > > </Dependency>
> > > > > </Assembly>
> > > > > </myObjectOne>
> > > > > <myObjectTwo>
> > > > > .....
> > > > > </myObjectTwo>
> > > > > </Type>
> > > > >
> > > > > Server RO:
> > > > > public class ServerRO: MarshalByRefObject
> > > > > {
> > > > > ...
> > > > > public AbstractBaseObject GetObject(string objType)
> > > > > {
> > > > > LoadConfigXml();
> > > > >
> > > > > //Create an SAO object
> > > > > AbstractBaseObject retObj = Activator.GetObject(....);
> > > > >
> > > > > return retObj;
> > > > > }
> > > > >
> > > > > private void LoadConfigXml()
> > > > > {
> > > > > ...//load data from config file
> > > > >
> > > > > //Load assembly by name
> > > > > Assembly myAsm = Assembly.LoadFrom(dllFile);
> > > > >
> > > > > //Get type from assembly:
> > > > > myAsm.GetType(myType);
> > > > > }
> > > > >
> > > > > ...
> > > > > }
> > > > >
> > > > >
> > > > > Client RO:
> > > > > public class ClientRO
> > > > > {
> > > > > ...
> > > > > myRO = myServerRO.GetObject("ObjectOne") as
> > AbstractObjectOneClass;
> > > > > }
> > > > >
> > > > > ========================
> > > > >
> > > > > Before I had the server load assembly (at run-time), my program
run
> > just
> > > > > fine. The reason is the server host had referenced all assemblies,
> > > > including
> > > > > their dependencies, that the client want to create. And now, I
want
> > the
> > > > > server not having to reference the dll's until there's a need; I
can't
> > > > find a
> > > > > way to do this. If the loading assembly does not have any
> > dependencies,
> > > > > meaning they are compiled all into one large dll, I think it will
> > work.
> > > > But
> > > > > when the dll requires dependencies, how can I load many of them
into
> > the
> > > > > AppDomain of the server?
> > > > >
> > > > > I'm sorry that the msg is quite long, but I hope it will help you
> > > > understand
> > > > > what I'm looking for. Thanks for your ideas.
> > > > >
> > > > >
> > > > > --
> > > > > Your 2 cents are worth $milion$. Thanks.
> > > >
> > > >
> > > >
> >
> >
> >

Relevant Pages

  • Re: Run-time loading assembly on Server RO question
    ... Client always gets back RemoteBaseObject and then typecast it to its own ... Factory, on client's call, loads xml file for details and remotely calls ... it's a WellKnown Singleton type of remote object. ... xml info so our Factory know where/how to load their object. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: how to ensure only strong name assemblies are loaded with matching public key
    ... assembly for introspection, which means that you can inspect its metadata (including the public key), but cannot execute any code. ... >Subject: Re: how to ensure only strong name assemblies are loaded with matching public key ... >assumption is that one would load an assembly to use it, ... >>>special directory containing updates to the client software. ...
    (microsoft.public.dotnet.security)
  • Re: Run-time loading assembly on Server RO question
    ... My client code passed in the type name, and server side will load/convert to ... dll and load it before it instantiate the object. ... The reason is the server host had referenced all assemblies, ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Run-time loading assembly on Server RO question
    ... If all your client is passing to you is a type name, ... I want to make the server part dynamic ... > Before I had the server load assembly, ... The reason is the server host had referenced all assemblies, ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Abstract factory and remoting
    ... made the Factory local to the Client. ... AbsServer - ... Factory - not remotable anymore, invokes the remotable Servers ...
    (microsoft.public.dotnet.framework.remoting)