473,320 Members | 1,857 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

An interesting problem for Assembly sages

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
Nov 21 '06 #1
12 1673
"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.
Nov 21 '06 #2
"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/>

Nov 21 '06 #3
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/>

Nov 21 '06 #4
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/>


Nov 21 '06 #5
"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.
Nov 21 '06 #6
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.

Nov 21 '06 #7
"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.
Nov 21 '06 #8
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
Nov 22 '06 #9
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.

Nov 22 '06 #10
"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.
Nov 22 '06 #11
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.

Nov 22 '06 #12
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
Nov 22 '06 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

56
by: Dave Vandervies | last post by:
I just fixed a bug that some of the correctness pedants around here may find useful as ammunition. The problem was that some code would, very occasionally, die with a segmentation violation...
9
by: David Smith | last post by:
Im curious, other than those of you who use C# or VB for work, do you guys miss the "good 'ol days" of programming? When C was about all you had (or maybe some primitive BASIC, or some academic...
1
by: Shawn | last post by:
Hi All; another simpleton question. i'm pretty sure i already know but... what is a .Net Assembly? In the C++ app i work on at work, we use a main app with COM "plugnis" and a few COM servers....
1
by: Steve Lutz | last post by:
I have written a web service to provide some back-end functionality to a Web Site. The web service returns lists of items. If I use the webservice via a browser, it works fine and returns the...
6
by: Kevin Frevert | last post by:
In the process of learning VS2005/C# (having a background in Borland Delphi 2 through 2005) I came across an interesting feature of Visual Studio's file management. At first, it appeared there...
2
by: Ron M. Newman | last post by:
Hello .NET Sages, Question. What is the meaning of adding say, an XML file to a project, next to a .CS file (not that it matters). Does that mean the XML file becomes a part of the compiled...
27
by: Frederick Gotham | last post by:
I thought it might be interesting to share experiences of tracking down a subtle or mysterious bug. I myself haven't much experience with tracking down bugs, but there's one in particular which...
4
by: Ron M. Newman | last post by:
Hi: How do I get the GUID string out of an assembly? (I have it loaded and referenced from an Assembly obect). -Ron
4
by: Andrew | last post by:
I am having an interesting namespace conflict. When we use a third party lib we create a company assembly for any descending classes to go in. I have simplified the problem into the example...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.