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.d ll" - 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]

Re: An interesting problem for Assembly sages

"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.d ll" - 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?

--

https://www.midnightbeach.com/.net

What you need to know.

[Herfried K. Wagner [MVP]]

Re: An interesting problem for Assembly sages

"Ron M. Newman" <confidential@c onfideltial.com schrieb:

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.d ll" - 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]

Re: I'll try to explain the problem

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 "propertyBa g" 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
ICustomTypeDesc riptor 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.LoadFr om(...) 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]" <hirf-spam-me-here@gmx.atwrot e in message
news:ODzOiHWDHH A.4952@TK2MSFTN GP06.phx.gbl...

"Ron M. Newman" <confidential@c onfideltial.com schrieb:

>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.d ll" - 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]

(.NET bug???) found another poor soul with the same problem

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 GetCustomAttrib utes method
and the System.Componen tModel.EditorAt tribute 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" <confidential@c onfideltial.com wrote in message
news:%23cz5fjXD HHA.992@TK2MSFT NGP03.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 "propertyBa g" 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
ICustomTypeDesc riptor 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.LoadFr om(...) 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]" <hirf-spam-me-here@gmx.atwrot e in message
news:ODzOiHWDHH A.4952@TK2MSFTN GP06.phx.gbl...

>"Ron M. Newman" <confidential@c onfideltial.com schrieb:

>>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.d ll" - 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]

Re: I'll try to explain the problem

"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.

--

https://www.midnightbeach.com/.net

What you need to know.

[Ron M. Newman]

Re: I'll try to explain the problem

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" <jon@midnightbe ach.comwrote in message
news:45634A6C.B 27880CE@midnigh tbeach.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.
>
--
>

https://www.midnightbeach.com/.net

What you need to know.

[Jon Shemitz]

Re: I'll try to explain the problem

"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.

--

https://www.midnightbeach.com/.net

What you need to know.

[Gadget]

Re: (.NET bug???) found another poor soul with the same problem

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 GetCustomAttrib utes method
and the System.Componen tModel.EditorAt tribute 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" <confidential@c onfideltial.com wrote in message
news:%23cz5fjXD HHA.992@TK2MSFT NGP03.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 "propertyBa g" 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
>ICustomTypeDes criptor 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.LoadFr om(...) 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]" <hirf-spam-me-here@gmx.atwrot e in message
>news:ODzOiHWDH HA.4952@TK2MSFT NGP06.phx.gbl.. .

>>"Ron M. Newman" <confidential@c onfideltial.com schrieb:
>>>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.d ll" - 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.LoadFi le(System.IO.Pa th.Combine(Syst em.IO.Path.GetD irectoryName(Ap plication.Execu tablePath),
"CustomEditor.d ll"));

Type o = a.GetType("Cust omEditor.Rectan gleControl");
ConstructorInfo ci = o.GetConstructo r(System.Type.E mptyTypes);
object obj = ci.Invoke(Syste m.Type.EmptyTyp es);
this.Controls.A dd((Control)obj );
((Control)obj). Visible = true;
((Control)obj). Location = new Point(100, 100);
((Control)obj). Size = new Size(100,100);
propertyGrid1.S electedObject = obj;

There is no reference in my code to CustomEditor.dl l.

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

Cheers,
Gadget

[Ron M. Newman]

I GOT IT! I GOT IT!!!! PLEASE READ!

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" <jon@midnightbe ach.comwrote in message
news:45634A6C.B 27880CE@midnigh tbeach.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.
>
--
>

https://www.midnightbeach.com/.net

What you need to know.

[Jon Shemitz]

Re: I GOT IT! I GOT IT!!!! PLEASE READ!

"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

https://www.midnightbeach.com/.net

What you need to know.

[Ron M. Newman]

Re: I GOT IT! I GOT IT!!!! PLEASE READ!

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" <jon@midnightbe ach.comwrote in message
news:4564A68A.7 EDC171D@midnigh tbeach.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

https://www.midnightbeach.com/.net

What you need to know.

[Gadget]

Re: I GOT IT! I GOT IT!!!! PLEASE READ!

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" <jon@midnightbe ach.comwrote in message
news:4564A68A.7 EDC171D@midnigh tbeach.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