[IronPython] Some new bugs with asssembly loading...

Wed Jan 4 18:21:33 CET 2006

Hi Steven,

When trying to load the aforge.imaging.dll, I get an exception (below). The bugs in IronPython are:

a) we don't tell you about the exception and fail to add clr.References
b) on your second try we succeed loading the assembly because we already have it in our internal cache (regardless of the previous failure).

Moreover, the only way to load the libraries correctly (and this may be limitation of CLR) is to have them in the same directory as IronPythonConsole.exe (see below for the list of folders CLR scans, looking for AForge.Math - they are IronPython directories, not directory where your Imaging dll came from. I don't know (yet) what to do about this one, but will track it down. After my initial discussion with Jim it seems result of our change in the way we load assemblies - Dino already posted comments on the alias.

I am going to checkin a fix for the exception so you get reasonable error message in your case. If you like, you can then use our internal build (\\ironpython\python\latest) but as for the references between Imaging and Math, the only workaround for now is to place the dlls into the directory alongside IronPythonConsole.exe

I hope this helps
Martin

The assembly with display name 'AForge.Math' failed to load in the 'Anonymous' binding context of the AppDomain with ID 1. The cause of the failure was: System.IO.FileNotFoundException: Could not load file or assembly 'AForge.Math, Version=1.0.2195.15851, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'AForge.Math, Version=1.0.2195.15851, Culture=neutral, PublicKeyToken=null'

Assembly manager loaded from:  C:\WINNT\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  D:\Ip\IronPython\Public\IronPythonConsole.vshost.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = REDMOND\martmaly
LOG: DisplayName = AForge.Math, Version=1.0.2195.15851, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///D:/Ip/IronPython/Public/
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\WINNT\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///D:/Ip/IronPython/Public/AForge.Math.DLL.
LOG: Attempting download of new URL file:///D:/Ip/IronPython/Public/AForge.Math/AForge.Math.DLL.
LOG: Attempting download of new URL file:///D:/Ip/IronPython/Public/AForge.Math.EXE.
LOG: Attempting download of new URL file:///D:/Ip/IronPython/Public/AForge.Math/AForge.Math.EXE.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Steven Drucker
Sent: Tuesday, January 03, 2006 4:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Some new bugs with asssembly loading...

Ok, but I'm not sure why my situation is different. I've tried this over and over, and I keep getting the same behavior. The References are not updated until I do it twice, and I can't import my assembly.
Could it be something odd about the assembly (this worked fine in ip version 0.9.6)? In fact, if I simply run the 0.9.6 version of IP, it still works just fine.

It looks like I've got the most up-to-date CLR.
Other potential things that could be different?
--S

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Martin Maly
Sent: Tuesday, January 03, 2006 4:31 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Some new bugs with asssembly loading...

Hi Steven,

I am not observing the first and second set of the problems you reported. My assembly has name c.d.e.dll and adding reference to it works just fine. It shows up in the References right away also.

>>> import clr
>>> clr.AddReferenceToFile("D:\\Ip\\IronPython\\c.d.e.dll")
>>> clr.References
(mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, c.d.e, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null)

As for the import, we do have a bug that affects global-level types in the referenced assembly. Types that are enclosed in the namespace can be imported without problems:

>>> import N
>>> N.C.M(1,2)
2

Where the assembly c.d.e.dll was compiled from:

namespace N {
public class C {
    public static int M(int a, int b) {
        return a * b;
    }
}
}

Excluding the namespace N will break if I try to do corresponding:

>>> import C
< Exception here >

Martin

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Steven Drucker
Sent: Tuesday, January 03, 2006 3:55 PM
To: Discussion of IronPython
Subject: [IronPython] Some new bugs with asssembly loading...

A number of bugs seem to have been introduced with the new assembly loading code:

First off, my assemblies will no longer load if they're named x.y (for instance, I was using an assembly that was named Aforge.Imaging). This will break since the code does a .split('.') to find all the names to load.

Second, the first time that I call AddReferenceToFile doesn't effect the clr.References list at all, but it adds it the second time. See the following snippet.

---------------
C:\SHO\private\sdrucker\vizdiff>ip
IronPython 1.0.2194 (Beta) on .NET 2.0.50727.40 Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.References
(mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Sy stem, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
>>>
clr.AddReferenceToFile('C:/code/iplab/AForge/Imaging/bin/Debug/AForgeIma
ging
.Dll')
>>> clr.References
(mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Sy stem, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
>>>
clr.AddReferenceToFile('C:/code/iplab/AForge/Imaging/bin/Debug/AForgeIma
ging
.Dll')
>>> clr.References
(mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Sy stem, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, AForgeI maging, Version=2.2.0.27774, Culture=neutral, PublicKeyToken=null)
>>>
----------------

Third, this breaks when I try to import the file. (No module named
AForgeImaging):

>>> import AForgeImaging
Traceback (most recent call last):
  File , line 0, in input##12
ImportError: No module named AForgeImaging
>>>

Any assistance would be appreciated...
--S

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060104/47783ebe/attachment.html>