I GOT IT! - And it's strange!

[Ron M. Newman]

No project compile time reference is needed to my dynamic assembly DLL...

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 simplu copy the dynamic assembly DLL to the executable
folder and it seems to
WORK ! (and yes, 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

[Chris Dunaway]

Ron M. Newman wrote:

No project compile time reference is needed to my dynamic assembly DLL...

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 are you determining the fully qualified name? Are you doing it
from an instance of the class?

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.

Can you post a short but complete program that demonstrates the
problem? It would make it much easier to triage the problem.

Chris

[Ron M. Newman]

Hi,

This is a large project. I will try to narrow down the problem down as
simply as I can

- I have an app compiling and running from: "c:\myapp\myapp.exe"

- The app's main form has an Assembly member

- The main form loads up an assembly from "c:\\assembly\\myassembly.dll"
using the following command (names changed): this.myAssembly =
AppDomain.CurrentDomain.Load(AssemblyName.GetAssem blyName(c:\\assembly\\myassembly.dll"));

- Needless to say there is no project reference between my application and
the "myassembly.dll"

- At this point, I can easily instantiate types from the assembly using
"Activator.CreateInstance(type)" - everything works fine.

- The problem: The main from has a property grid. I want it to use custom
type editor and a custom type converted that reside in myassembly.dll - you
do that by passing their assembly qualified name, which I do. The property
grid crashes!

- The solution

Change nothing but have a copy of myassembly.dll reside in the folder where
myapp.exe runs from (even if the dynamic assembly is being dynamically
loaded from its original path!!!) - when I do that, the property grid does
not crash on my custom type editor and type converter classes. It's like the
property grid only looks for the assembly in the current executable folder.
weird.

My question is: why do I need to have a copy of the myassembly.dll reside at
the myapp.exe folder for it to work.

Ron

"Chris Dunaway" <du******@gmail.comwrote in message
news:11*********************@h54g2000cwb.googlegro ups.com...

Ron M. Newman wrote:

>No project compile time reference is needed to my dynamic assembly DLL...

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 are you determining the fully qualified name? Are you doing it
from an instance of the class?

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

Can you post a short but complete program that demonstrates the
problem? It would make it much easier to triage the problem.

Chris

[Gadget]

My question is: why do I need to have a copy of the myassembly.dll reside at

the myapp.exe folder for it to work.

Ron

My question is, why have you started three separate threads asking this in
different ways? :)

I posted a sample yesterday that *works* even when the DLL is in another
folder. If you can create a small app that does work, as I did, then the
bug or problem lies elsewhere.
It is quite possible that you have a reference in your *external* DLL that
it can't find, and so the problem is that the external DLL is the one
failing.
Check that when you copy over your external DLL it has all the references
it needs, as that DLL will be looking in it's own directory and the GAC for
any support DLLs it needs.

Cheers,
Gadget

[Ron M. Newman]

Hi Gadget,

Understood about the threads. I'll switch to single threads from now on with
my development problems :-) It's just that I've spent days trying to
understand where this c*** comes from. I'm a little worked up here.

so, you're saying my assembly DLL that's in another folder depends on other
assemblies which are not to be found in the folder it resides at? I think
that's the case here. it DOES reference some other assemblies that just
happen to reside in the app folder, which might explain the reason it works
fine when it's copied there.

What's the best practice of resolving this? is there somehting like a
generic "search path" I can set during runtime? (e.g. registering the DLLs
my assembly depends on in the GAC?)

Thanks,
Ron
"Gadget" <ga****@sobell.netwrote in message
news:1i*****************************@40tude.net...

>My question is: why do I need to have a copy of the myassembly.dll reside
at
the myapp.exe folder for it to work.

Ron

My question is, why have you started three separate threads asking this in
different ways? :)

I posted a sample yesterday that *works* even when the DLL is in another
folder. If you can create a small app that does work, as I did, then the
bug or problem lies elsewhere.
It is quite possible that you have a reference in your *external* DLL that
it can't find, and so the problem is that the external DLL is the one
failing.
Check that when you copy over your external DLL it has all the references
it needs, as that DLL will be looking in it's own directory and the GAC
for
any support DLLs it needs.

Cheers,
Gadget

[Gadget]

On Sat, 25 Nov 2006 00:20:25 -0500, Ron M. Newman wrote:

Hi Gadget,

Understood about the threads. I'll switch to single threads from now on with
my development problems :-) It's just that I've spent days trying to
understand where this c*** comes from. I'm a little worked up here.

so, you're saying my assembly DLL that's in another folder depends on other
assemblies which are not to be found in the folder it resides at? I think
that's the case here. it DOES reference some other assemblies that just
happen to reside in the app folder, which might explain the reason it works
fine when it's copied there.

What's the best practice of resolving this? is there somehting like a
generic "search path" I can set during runtime? (e.g. registering the DLLs
my assembly depends on in the GAC?)

Thanks,
Ron
"Gadget" <ga****@sobell.netwrote in message
news:1i*****************************@40tude.net...

>>My question is: why do I need to have a copy of the myassembly.dll reside
at
the myapp.exe folder for it to work.

Ron

My question is, why have you started three separate threads asking this in
different ways? :)

I posted a sample yesterday that *works* even when the DLL is in another
folder. If you can create a small app that does work, as I did, then the
bug or problem lies elsewhere.
It is quite possible that you have a reference in your *external* DLL that
it can't find, and so the problem is that the external DLL is the one
failing.
Check that when you copy over your external DLL it has all the references
it needs, as that DLL will be looking in it's own directory and the GAC
for
any support DLLs it needs.

Cheers,
Gadget

I'm not sure what your easiest solution is. One method that springs to mind
is that your DLL will raise an AppDomain.AssemblyResolve event whenever it
wants an external DLL, so you could always intercept this event and have it
source those DLLs from the application's folder.
There may be an easier way, but other than sticking your shared DLLs in the
GAC I'm not sure what that might be.

Cheers,
Gadget

[Chris Dunaway]

Ron M. Newman wrote:

What's the best practice of resolving this? is there somehting like a
generic "search path" I can set during runtime? (e.g. registering the DLLs
my assembly depends on in the GAC?)

If you want to organize your app folder and place your .dll's in a
separate folder, you can use a couple of methods. The first is the
AppDomainSetup.PrivateBinPath Property. You can use this to set which
folders under the app folder for the program to probe for your
assemblies. I have not used this method. I have used the
AppDomain.AppendPrivatePath method which I see is now marked as
obsolete.

You can also add an entry to the app.config file which specifies where
the app should look for assemblies:

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>

All of these methods only probe folder that are below the main app
folder.

Hope this helps

Chris