---- Reported by gert.driesen@pandora.be 2004-04-25 08:22:53 MST ----

Currently Mono does not use the semicolon delimited list of subdirectories 
(of the application base) in the privatePath attribute of the 
configuration/runtime/assemblyBinding/probing element to search for 
assemblies.

eg.

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

This will instruct the runtime to not only search the base directory of 
the AppDomain, but also the bin subdirectory of that base directory for 
assemblies.  However, at this time, Mono does not do this.

Notes:

- Directories that are not located under the base directory of the 
appdomain should be silently ignored (atleast, this is what MS.NET does).

- Subdirectories added to privatePath in the configuration file should not 
be reflected in the AppDomainSetup.PrivateBinPath property, and calling 
AppDomain.ClearPrivatePath() does not have any effect on the directories 
added through the configuration file.

I attached a repro for this issue.



---- Additional Comments From gert.driesen@pandora.be 2004-04-25 08:23:29 MST ----

Created an attachment (id=165925)
repro




---- Additional Comments From gonzalo@ximian.com 2004-04-26 10:41:27 MST ----

Ben this is not something we should left out. Many people use this
feature.



---- Additional Comments From gert.driesen@pandora.be 2004-07-30 08:55:14 MST ----

I've split this bug report up into two separate ones :

62135
57612



*** This bug has been marked as a duplicate of https://bugzilla.novell.com/show_bug.cgi?id=MONO62135 ***



---- Additional Comments From gert.driesen@pandora.be 2004-07-30 08:57:09 MST ----

oops, closed wrong bug.



---- Additional Comments From gert.driesen@pandora.be 2004-08-01 05:32:19 MST ----

btw: the attachment is a zip file



---- Additional Comments From bmaurer@users.sf.net 2005-06-29 12:41:39 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO75419 has been marked as a duplicate of this bug. ***



---- Additional Comments From urilith@gentoo.org 2005-07-04 12:20:35 MST ----

Any work on this?  This is a current blocker for my plug-in library,
and its a really ugly kludge to tell people to use MONO_PATH when
it'll work out of the box using the library's search path on Windows.



---- Additional Comments From urilith@gentoo.org 2005-07-06 06:06:25 MST ----

Created an attachment (id=165926)
Patch to fix PrivatePath issues.




---- Additional Comments From urilith@gentoo.org 2005-07-06 06:08:49 MST ----

The above patch fixes the problem for me.  It definitely works for the
Load (byte[]) case, and should work for others as well.

What I did was add a function update_path_env that is nearly identical
to check_path_env in assembly.c.  Instead of checking the environment,
update_path_env takes a MonoString containing the search dirs and adds
those to assemblies_path.  In appdomain.c I added the update_path_env
call in ves_icall_System_AppDomain_LoadAssemblyRaw if
ad->data->setup->private_path is set.  This definitely works for me. 
Out of my 34 NModule tests, 21 pass with a simple nunit-console
NModule.Core.Test.dll, and the 13 that fail are bad test cases, not
the loader.



---- Additional Comments From urilith@gentoo.org 2005-07-06 06:17:34 MST ----

Might be worthwhile to add check_path_env after the call to the load
method, since that'll restore it to the MONO_PATH defaults.  I'm
looking into that now and will provide a new diff if it works.



---- Additional Comments From urilith@gentoo.org 2005-07-06 06:30:50 MST ----

Created an attachment (id=165927)
New version of the patch.




---- Additional Comments From urilith@gentoo.org 2005-07-06 06:32:04 MST ----

The new version removes the static qualifier from check_path_env in
assembly.c and adds its prototype to assembly.h.  This is so we can
call check_path_env in LoadAssemblyRaw after the assembly has been
loaded so that the private path doesnt persist past the appdomain, as
this is incorrect behavior.  Also, this version of the patch actually
compiles :P.



---- Additional Comments From urilith@gentoo.org 2005-07-06 08:06:42 MST ----

Created an attachment (id=165928)
Bah, the second one had both patches together.  This is the actual patch.




---- Additional Comments From miguel@ximian.com 2007-07-12 18:11:22 MST ----

Am wondering if the extra paths should not be an extra argument that
is used to construct the actual assemblies_path array, because it
seems that this information is AppDomain-specific, it should not be
updating a global setting that might cause other appdomains to act on it.



---- Additional Comments From mhabersack@novell.com 2007-08-23 09:26:31 MST ----

Below is a proposed fix to the problem. Please review.



---- Additional Comments From mhabersack@novell.com 2007-08-23 09:27:32 MST ----

Created an attachment
https://bugzilla.novell.com/show_bug.cgi?id=MONO57612.diff




---- Additional Comments From mhabersack@novell.com 2007-08-23 09:49:42 MST ----

An updated version of the patch follows.



---- Additional Comments From mhabersack@novell.com 2007-08-23 09:50:18 MST ----

Created an attachment
https://bugzilla.novell.com/show_bug.cgi?id=MONO57612.diff




---- Additional Comments From gert.driesen@pandora.be 2007-08-23 13:56:13 MST ----

Marek, your patch does not fix the problem for me.

This bug blocked bug(s) 57602 57710 81446.
Imported an attachment (id=165925)
Imported an attachment (id=165926)
Imported an attachment (id=165927)
Imported an attachment (id=165928)
Imported an attachment (id=165929)
Imported an attachment (id=165930)

Unknown operating system unknown. Setting to default OS "Other".