---- Reported by gert.driesen@pandora.be 2004-07-27 00:54:38 MST ----

There's a regression in Mono 1.0 (Windows) with regards to loading 
assembly references from directories containing dots that are added to 
the privatebinpath.  This used to work fine in previous versions of Mono 
(eg. 0.28).

I have been able to reproduce this issue using both Mono 1.0 (release) 
and Mono/cvs on Windows.  Its working fine on Linux though.

I attached a repro involving three assemblies :

assembly a (exe)
                  -->    assembly b (library)
                (loads)                       -->    assembly c (library)
                                          (references)

Now, because of Mono bug (57602), the complete tree of dependencies will 
be resolved when an assembly is loaded. In this case, it means that when 
assembly b is loaded, Mono will immediately try to resolve the reference 
to assembly c.

In the repro I attached, assembly a and b are located in the same 
directory, and so Mono should have no problem loading assembly b. 
However, I've stored assembly c in a subdirectory in order to demonstrate 
the loader issue. In order to allow Mono to resolve the reference to 
assembly c you can add the subdirectory containing assembly c to the 
privatebinpath.

In th repro, you can do this by passing the name of the subdirectory that 
you want to append to the privatebinpath as argument to a.exe :

Usage : mono a.exe <path to append to privatebinpath>

For example :

$ mono a.exe a.b

This would/should instruct Mono to also check for referenced assemblies 
in subdirectory 'a.b', but, as you'll notice, (if you're using Mono on 
Windows that is) Mono cannot resolve the reference to assembly c if that 
assembly is located in a directory containing dots :

Adding a.b to private bin path.

** (a.exe:1384): WARNING **: Could not find assembly c, references from 
D:\mono-
test-projects\privatepath - simple\b.dll (assemblyref_index=1)
     Major/Minor: 0,0
     Build:       0,0
     Token:

Unhandled Exception: System.IO.FileNotFoundException: File 'b.dll' not 
found.
in (unmanaged) (wrapper managed-to-native) 
System.Reflection.Assembly:LoadFrom (string) in <0x00004> (wrapper 
managed-to-native) System.Reflection.Assembly:LoadFrom (string)
in <0x00074> a.SomeClass:Main (string[])


Try renaming the subdirectory 'a.b' to a directory name without dots, for 
example 'ab' and try running the test app again :

$ mono a.exe ab

This will work fine (as the directory does not contain dots).



---- Additional Comments From gert.driesen@pandora.be 2004-07-27 00:55:16 MST ----

Created an attachment (id=166533)
zip file containing repro for this regression




---- Additional Comments From gonzalo@ximian.com 2004-07-29 16:28:19 MST ----

Fixed in 1.0 and HEAD.



---- Additional Comments From gonzalo@ximian.com 2004-08-12 13:19:28 MST ----

Some recent change in mono HEAD made this bug alive again.



---- Additional Comments From gert.driesen@pandora.be 2004-08-12 13:31:00 MST ----

If I'm not mistaken then privatebinpath in general is broken, not 
just paths containing dots



---- Additional Comments From gert.driesen@pandora.be 2004-08-29 12:39:44 MST ----

A much simpler repro on Mono HEAD is :

using System;

public class EntryPoint {
  public static void Main() {
    AppDomain.CurrentDomain.AppendPrivatePath("whatever");
    Console.WriteLine("PRIVATE BIN PATH: " 
	+ AppDomain.CurrentDomain.SetupInformation.PrivateBinPath);
  }
}

On Mono HEAD, you'll get the following output :

PRIVATE BIN PATH:

while on MS.NET and Mono 1.0.x, you'll get :

PRIVATE BIN PATH: whatever

I'm just guessing here, but it might have to do with the fact that 
changes to the private bin path are only processed when the 
application base directory is set, and perhaps something has changed 
here post 1.0.x.




---- Additional Comments From gert.driesen@pandora.be 2004-09-10 01:11:59 MST ----

I think everything was working fine a few days (3-4) before the 
27th. 

But I'm really not sure of this.



---- Additional Comments From gonzalo@ximian.com 2004-09-13 01:23:43 MST ----

Fixed in CVS.

Imported an attachment (id=166533)

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