It seems both Assembly.LoadFrom and Activator.CreateInstance create a new
instance of the object. But I want to access an already existing object. I
am writing a control which holds a pointer to an object of the type defined
in the 2nd assembly. If that pointer is assigned a valid reference( i.e. not
Null) , then I will access the methods of the 2nd object through the
pointer.  For example

MyObject1.SecondObjectRefernce = secondObject1 //  already existing object
of type SecondObject
...
...
if(!SecondObjectReference)
{
SecondObjectReference->CallMethod1()

If SecondObjectReference is Null, then there is no need for the assembly
containing the object of type SecondObject to be present, and similarly, if
the reference is used --> implies that the assembly will be present

How can I do this?

Thanks
Atul

Atul,

I'm not really sure what you're asking, and I'm not VC++ programmer, but
I'll try and help.

says...

If this object already exists, who created it?  How did you obtain a
reference to it?

What do you mean by "be present"?  Do you mean actually exist on the
machine in a compiled DLL?

--
Patrick Steele
Microsoft .NET MVP
http://radio.weblogs.com/0110109

Hello,

I will try to explain from the beginning.

I have two different projects both of which are Controls, say Control1 and
Control2, in the assemblies Control1.dll and Control2.dll. These controls
will be used by a developer for application development. However the
developer can use any one or both controls for development. Only the
assemblies corresponding to the controls that he is using, need to be
present on the developer's machine.

I want Control1 to hold a reference to Control2 ( I.e. have a property of
type Control2, let the name of this property be Control2Reference) . This is
because, if used together, they synchronize with each other; however they
can also be used standalone..  Thus if Control1.Control2Refernce = Nothing,
then Control1 will not call methods of Control2 for synching, and therefore
there is no need for the Control2.dll assembly to be physically present on
the developer's computer.

Now if the developer has instances of both Control1 and Control2 on a form
and if he writes Control1.Control2Reference = Control2 in code, then
synchronization will take place.

Now my problem is that Control1 and Control2 are different projects, so
Control1 does not have type information ( methods,properties,etc) for
Control2. If I make this information available in Control1, by adding a
reference to Control2.dll, then Control1.dll becomes dependant on
Control2.dll ( I.e. Control2.dll needs to be physically present on the
developer's machine) , even if some developer may not want to use the
synchronization features. ( When you try to add
Control1 on the toolbox, I get an error message saying  "Control2 not
found" )

With ActiveX controls, this was not a problem, because each control had a
unique GUID and VC++ would make wrapper classes for Control2 in the Control1
project. The wrapper class implementation of Control2 would dynamically
invoke the methods of Control2 using a reference to an existing instance of
Control2.

How can I solve this issue in .Net?

I hope I have succeeded in explaining my problem.

Thanks
Atul

says...

If, as you state, both controls "will be used by a developer", then why
would only one of the assemblies be on the machine?

I'm still not clear as to why you have this need to (possibly) only
having one physical DLL on the machine.  Are you trying to save disk
space?  How big are these DLLs?  Why not just put both on the machine
and you don't need to worry about any of this?

If you really need to keep two different DLLs, then my solution probably
won't help since it involves a third DLL...  :)

Define an interface for this "synchronization".  Have Control2 implement
that interface and have Control1.Control2Reference be a type of that
interface.  The interface would need to be distributed with both DLL's
however.

Or you could define the interface in Control1, and then Control2.DLL
would require a reference to Control1.DLL so it could get a definition
of the interface to implement.

--
Patrick Steele
Microsoft .NET MVP
http://radio.weblogs.com/0110109