An interesting problem for Assembly sages

[Ron M. Newman]

Hi,

I can load an assembly using the Assembly.Load(....)

However, I'd like dynamic loading of assemblies to be identical to putting
an assembly reference in your VS2005 project. and yes, I know about the
unloading problems. Let's say I don't care for the moment.

If I have an assemlbly file at "c:\\assembly.dll" - how do I load it at
runtime as if it were references in the project at build time? I know
something about loading an assembly into the current appDomain but can't
seem to be able to find examples on how to do that. My attemps on this have
failed.

Help?

Thanks
Ron

[Jon Shemitz]

"Ron M. Newman" wrote:

I can load an assembly using the Assembly.Load(....)

However, I'd like dynamic loading of assemblies to be identical to putting
an assembly reference in your VS2005 project. and yes, I know about the
unloading problems. Let's say I don't care for the moment.

If I have an assemlbly file at "c:\\assembly.dll" - how do I load it at
runtime as if it were references in the project at build time? I know
something about loading an assembly into the current appDomain but can't
seem to be able to find examples on how to do that. My attemps on this have
failed.

It's not really clear what your question is. What do you want to
happen when you Load an Assembly that's not happening?

Surely you don't expect to be able to compile using symbols that
aren't referenced at compile time?

--

www.midnightbeach.com/.net
What you need to know.

[Herfried K. Wagner [MVP]]

"Ron M. Newman" <co**********@confideltial.comschrieb:

I can load an assembly using the Assembly.Load(....)

However, I'd like dynamic loading of assemblies to be identical to putting
an assembly reference in your VS2005 project. and yes, I know about the
unloading problems. Let's say I don't care for the moment.

If I have an assemlbly file at "c:\\assembly.dll" - how do I load it at
runtime as if it were references in the project at build time?

Check out 'Assembly.Load*'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Ron M. Newman]

Hi,

I am using a property grid and I use custom type editors and type
converters. The properties are dynamic, not based on pre-compiled
properties/attributes so I'm using the "propertyBag" exmample
implementation. In order for it to work with custom editors and type
coverters you need to enter the fully qualified name of those classes into a
structure and then into a collection which is then used by an
ICustomTypeDescriptor to simulate dynamic properties.

That's really a property grid issue and i bring it as a background
explanation. It may be irrelevant to my question.

The symptoms I experience are

1) When the classes for the custom editor and typeConverter are pre-compiled
with the main application in which the property grid resides -- everything
works perfectly.
2) When the same classes are within a dynamically loaded assembly who's
Assembly object is a member of the main form of the main application - the
property grid ignores the input and reverts to its own standard
editor/typecoverter
3) Situation #2 + adding a reference to the assembly in the VS2005
project -- it WORKS prefectly.

This triggered my question. What's the difference between #1 and #3? what's
causing a mere Assembly.LoadFrom(...) not to function properly - although I
can generate types from it and they seem to work. when I submit a string of
a fully qualified class name from that assembly - it can't use it to load
the proper classes.

Where is my mistake?

Thanks
Ron


"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...

"Ron M. Newman" <co**********@confideltial.comschrieb:

>I can load an assembly using the Assembly.Load(....)

However, I'd like dynamic loading of assemblies to be identical to
putting an assembly reference in your VS2005 project. and yes, I know
about the unloading problems. Let's say I don't care for the moment.

If I have an assemlbly file at "c:\\assembly.dll" - how do I load it at
runtime as if it were references in the project at build time?

Check out 'Assembly.Load*'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Ron M. Newman]

Is this a bug in .NET? are we really on the cutting edge of technology
here????

Here's what he says:

I've got a plugin architecture system that calls LoadFrom to load the .dlls
in a specific folder and it works fine and dandy, imports everything, my
code
can create objects from types found in the loaded .dlls

HOWEVER, One issue i've not been able to solve is that, in some of the
classes, I've got custom Type Editors that do not function when I try to
edit
them via a PropertyGrid that is on my application's main form.

Whenever I create object from one of the plugged in .dlls and set it to the
property grid's selected object, trying to edit it does not produce the
correct type editor. This is especially the case with my custom collection
classes. Since most of them are inherited from ArrayList, I constantly get
the Object editor form.

Now here's the really wicked twist. If the plugins are set to references in
my project in vs.net, The correct editors will appear just fine.

I did some debugging by getting a type for one of my collections that uses a
custom editor, and wrote all the attributes from GetCustomAttributes method
and the System.ComponentModel.EditorAttribute was still a recognized
attribute on the class, eliminating my thought that perhaps the attribute
was
being lost during the LoadFrom.

I am totally baffled.

"Ron M. Newman" <co**********@confideltial.comwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...

Hi,

I am using a property grid and I use custom type editors and type
converters. The properties are dynamic, not based on pre-compiled
properties/attributes so I'm using the "propertyBag" exmample
implementation. In order for it to work with custom editors and type
coverters you need to enter the fully qualified name of those classes into
a structure and then into a collection which is then used by an
ICustomTypeDescriptor to simulate dynamic properties.

That's really a property grid issue and i bring it as a background
explanation. It may be irrelevant to my question.

The symptoms I experience are

1) When the classes for the custom editor and typeConverter are
pre-compiled with the main application in which the property grid
resides -- everything works perfectly.
2) When the same classes are within a dynamically loaded assembly who's
Assembly object is a member of the main form of the main application - the
property grid ignores the input and reverts to its own standard
editor/typecoverter
3) Situation #2 + adding a reference to the assembly in the VS2005
project -- it WORKS prefectly.

This triggered my question. What's the difference between #1 and #3?
what's causing a mere Assembly.LoadFrom(...) not to function properly -
although I can generate types from it and they seem to work. when I submit
a string of a fully qualified class name from that assembly - it can't use
it to load the proper classes.

Where is my mistake?

Thanks
Ron


"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...

>"Ron M. Newman" <co**********@confideltial.comschrieb:

>>I can load an assembly using the Assembly.Load(....)

However, I'd like dynamic loading of assemblies to be identical to
putting an assembly reference in your VS2005 project. and yes, I know
about the unloading problems. Let's say I don't care for the moment.

If I have an assemlbly file at "c:\\assembly.dll" - how do I load it at
runtime as if it were references in the project at build time?

Check out 'Assembly.Load*'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Jon Shemitz]

"Ron M. Newman" wrote:

1) When the classes for the custom editor and typeConverter are pre-compiled
with the main application in which the property grid resides -- everything
works perfectly.
2) When the same classes are within a dynamically loaded assembly who's
Assembly object is a member of the main form of the main application - the
property grid ignores the input and reverts to its own standard
editor/typecoverter
3) Situation #2 + adding a reference to the assembly in the VS2005
project -- it WORKS prefectly.

I don't know why you're seeing this behavior ... but I did a plugin
architecture for a customer that involved a property grid in the app,
and all the custom editors and type converters in the plugins worked
just fine.

--

www.midnightbeach.com/.net
What you need to know.

[Ron M. Newman]

was that a dynamic property grid? or were the properties "pre-compiled" with
classes that contained the browsable properties with attributes that
indicated usage of custom converters and editors that happened to come from
a dynamically loaded assembly?
Ron
"Jon Shemitz" <jo*@midnightbeach.comwrote in message
news:45***************@midnightbeach.com...

"Ron M. Newman" wrote:

>1) When the classes for the custom editor and typeConverter are
pre-compiled
with the main application in which the property grid resides --
everything
works perfectly.
2) When the same classes are within a dynamically loaded assembly who's
Assembly object is a member of the main form of the main application -
the
property grid ignores the input and reverts to its own standard
editor/typecoverter
3) Situation #2 + adding a reference to the assembly in the VS2005
project -- it WORKS prefectly.

I don't know why you're seeing this behavior ... but I did a plugin
architecture for a customer that involved a property grid in the app,
and all the custom editors and type converters in the plugins worked
just fine.

--

www.midnightbeach.com/.net
What you need to know.

[Jon Shemitz]

"Ron M. Newman" wrote:

I don't know why you're seeing this behavior ... but I did a plugin
architecture for a customer that involved a property grid in the app,
and all the custom editors and type converters in the plugins worked
just fine.

was that a dynamic property grid? or were the properties "pre-compiled" with
classes that contained the browsable properties with attributes that
indicated usage of custom converters and editors that happened to come from
a dynamically loaded assembly?

Dynamic as in using Reflection.Emit? No. The classes and their grid
customizations were compiled into a normal, C# assembly - compiled in
VS, and loaded at runtime.

--

www.midnightbeach.com/.net
What you need to know.

[Gadget]

On Tue, 21 Nov 2006 12:06:51 -0500, Ron M. Newman wrote:

Is this a bug in .NET? are we really on the cutting edge of technology
here????

Here's what he says:

I've got a plugin architecture system that calls LoadFrom to load the .dlls
in a specific folder and it works fine and dandy, imports everything, my
code
can create objects from types found in the loaded .dlls

HOWEVER, One issue i've not been able to solve is that, in some of the
classes, I've got custom Type Editors that do not function when I try to
edit
them via a PropertyGrid that is on my application's main form.

Whenever I create object from one of the plugged in .dlls and set it to the
property grid's selected object, trying to edit it does not produce the
correct type editor. This is especially the case with my custom collection
classes. Since most of them are inherited from ArrayList, I constantly get
the Object editor form.

Now here's the really wicked twist. If the plugins are set to references in
my project in vs.net, The correct editors will appear just fine.

I did some debugging by getting a type for one of my collections that uses a
custom editor, and wrote all the attributes from GetCustomAttributes method
and the System.ComponentModel.EditorAttribute was still a recognized
attribute on the class, eliminating my thought that perhaps the attribute
was
being lost during the LoadFrom.

I am totally baffled.

"Ron M. Newman" <co**********@confideltial.comwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...

>Hi,

I am using a property grid and I use custom type editors and type
converters. The properties are dynamic, not based on pre-compiled
properties/attributes so I'm using the "propertyBag" exmample
implementation. In order for it to work with custom editors and type
coverters you need to enter the fully qualified name of those classes into
a structure and then into a collection which is then used by an
ICustomTypeDescriptor to simulate dynamic properties.

That's really a property grid issue and i bring it as a background
explanation. It may be irrelevant to my question.

The symptoms I experience are

1) When the classes for the custom editor and typeConverter are
pre-compiled with the main application in which the property grid
resides -- everything works perfectly.
2) When the same classes are within a dynamically loaded assembly who's
Assembly object is a member of the main form of the main application - the
property grid ignores the input and reverts to its own standard
editor/typecoverter
3) Situation #2 + adding a reference to the assembly in the VS2005
project -- it WORKS prefectly.

This triggered my question. What's the difference between #1 and #3?
what's causing a mere Assembly.LoadFrom(...) not to function properly -
although I can generate types from it and they seem to work. when I submit
a string of a fully qualified class name from that assembly - it can't use
it to load the proper classes.

Where is my mistake?

Thanks
Ron


"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...

>>"Ron M. Newman" <co**********@confideltial.comschrieb:
I can load an assembly using the Assembly.Load(....)

However, I'd like dynamic loading of assemblies to be identical to
putting an assembly reference in your VS2005 project. and yes, I know
about the unloading problems. Let's say I don't care for the moment.

If I have an assemlbly file at "c:\\assembly.dll" - how do I load it at
runtime as if it were references in the project at build time?

Check out 'Assembly.Load*'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Is your UITypeEditor in the same library as your control?

I just tested this out, and it works fine for me with no reference to the
dynamically loaded component.
Here's the section of loading code that worked fine for me:

Assembly a =
Assembly.LoadFile(System.IO.Path.Combine(System.IO .Path.GetDirectoryName(Application.ExecutablePath) ,
"CustomEditor.dll"));

Type o = a.GetType("CustomEditor.RectangleControl");
ConstructorInfo ci = o.GetConstructor(System.Type.EmptyTypes);
object obj = ci.Invoke(System.Type.EmptyTypes);
this.Controls.Add((Control)obj);
((Control)obj).Visible = true;
((Control)obj).Location = new Point(100, 100);
((Control)obj).Size = new Size(100,100);
propertyGrid1.SelectedObject = obj;

There is no reference in my code to CustomEditor.dll.

Can you post an example that shows it not working for you?

Cheers,
Gadget

[Ron M. Newman]

No project compile time reference is needed.

I load an assembly DLL dynamically with a complex path. the assembly DLL is
NOT in the exutable folder.
I submit the fully qualified name to to the property grid (custom editor
etc.) and it FAILS.

How do I fix that?

I have a copy of the assembly DLL in the executable folder and it seems to
WORK ! (still, no compile time references required).

My question is:

although I have loaded the assembly DLL successfully from the other path.
how can I make sure it gets used correctly when things like the property
grid need to use it? it seems very strange to me that loading is successful
from a "foreign" path, type instantiation works fine for all intents and
purposes, but only the damn property grid needs to have a copy of the
assembly DLL in the executable folder.

Any ideas?

Ron

"Jon Shemitz" <jo*@midnightbeach.comwrote in message
news:45***************@midnightbeach.com...

"Ron M. Newman" wrote:

>1) When the classes for the custom editor and typeConverter are
pre-compiled
with the main application in which the property grid resides --
everything
works perfectly.
2) When the same classes are within a dynamically loaded assembly who's
Assembly object is a member of the main form of the main application -
the
property grid ignores the input and reverts to its own standard
editor/typecoverter
3) Situation #2 + adding a reference to the assembly in the VS2005
project -- it WORKS prefectly.

I don't know why you're seeing this behavior ... but I did a plugin
architecture for a customer that involved a property grid in the app,
and all the custom editors and type converters in the plugins worked
just fine.

--

www.midnightbeach.com/.net
What you need to know.

[Jon Shemitz]

"Ron M. Newman" wrote:

it seems very strange to me that loading is successful
from a "foreign" path, type instantiation works fine for all intents and
purposes, but only the damn property grid needs to have a copy of the
assembly DLL in the executable folder.

Me, too. *Perhaps* the property grid is doing something like loading
assemblies into an AppDomain, and it can't find them if they're not in
the app path.

Any ideas?

Nope, sorry. I don't see any properties or methods to set assembly
path ....

--

..NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.

[Ron M. Newman]

Thanks. What I'm doing anyhow to get around it is i autoamtically copy the
assembly I'm about to use to the executable folder. this solves the
problem -- or rather bypasses it. PropertyGrid lives in peace with this
solution.
Ron

"Jon Shemitz" <jo*@midnightbeach.comwrote in message
news:45***************@midnightbeach.com...

"Ron M. Newman" wrote:

>it seems very strange to me that loading is successful
from a "foreign" path, type instantiation works fine for all intents and
purposes, but only the damn property grid needs to have a copy of the
assembly DLL in the executable folder.

Me, too. *Perhaps* the property grid is doing something like loading
assemblies into an AppDomain, and it can't find them if they're not in
the app path.

>Any ideas?

Nope, sorry. I don't see any properties or methods to set assembly
path ....

--

.NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.

[Gadget]

On Wed, 22 Nov 2006 14:45:54 -0500, Ron M. Newman wrote:

Thanks. What I'm doing anyhow to get around it is i autoamtically copy the
assembly I'm about to use to the executable folder. this solves the
problem -- or rather bypasses it. PropertyGrid lives in peace with this
solution.
Ron

"Jon Shemitz" <jo*@midnightbeach.comwrote in message
news:45***************@midnightbeach.com...

>"Ron M. Newman" wrote:

>>it seems very strange to me that loading is successful
from a "foreign" path, type instantiation works fine for all intents and
purposes, but only the damn property grid needs to have a copy of the
assembly DLL in the executable folder.

Me, too. *Perhaps* the property grid is doing something like loading
assemblies into an AppDomain, and it can't find them if they're not in
the app path.

>>Any ideas?

Nope, sorry. I don't see any properties or methods to set assembly
path ....

--

.NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.

It's very odd, because I just copied the DLL to another drive and I still
have no problem at all.
Also, it's best to continue the thread you started earlier. Don't
cross-post, let people know if you've read their responses, otherwise
people won't bother trying to help you any more.

Cheers,
Gadget