The reason this is happening is due to the . in the filename - we end up seeing 
that as an extension and the assembly load request comes in w/o the .DLL so we 
don't try appending .DLL to do the load.  It looks like we need to do that no 
matter what.  You can fix this by just removing the if 
(String.IsNullOrEmpty(System.IO.Path.GetExtension(fullName))) { line in 
LoadAssemblyFromFile in clr.cs.

Unfortunately then you'll start hitting the stack overflow bug that Jon 
reported.  His fix is close to being right, but really it should become:

        private void AddReference(object reference) {
            Assembly asmRef = reference as Assembly;
            if (asmRef != null) {
                AddReference(asmRef);
                return;
            }

            string strRef = reference as string;
            if (strRef != null) {
                AddReference(strRef);
                return;
            }
        }

And AddReference(object reference, string alias) should go away - it looks like 
this one was just missed w/ catastrophic results.

I'm extremely sorry for the trouble here - it's my fault this time.  This 
happened when I completely changed our aliasing support.  I'll make sure we get 
some additional test coverage here so we don't keep breaking you.  And the good 
really good news is that we believe we've got the final solutions for loading 
now so we shouldn't be changing loading anymore before 1.0 (other than these 
bug fixes for the next release, of course).  Again, I'm sorry for the trouble 
here.




Do you want to help develop Dynamic languages on CLR? 
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Drucker
Sent: Wednesday, February 15, 2006 6:11 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 1.0 Beta 3 Released!

 
Also having problems with Assemblies.

I've got an assembly that references another assembly.
Even when I do the following:
import clr
clr.Path = ['C://code//assemblyloc']
clr.AddReferenceToFile('Aforge.Imaging.dll')

I get an error that it can't load 'AForge.Math' . Aforge.Math is in the
given location. In fact, if I just do a
clr.AddReferenceToFile('Aforge.Math.dll'), it works fine.

This was broken in Beta1, fixed in Beta2, but seems to be broken again.
(Or at least, I'm not sure of the proper calling procedure).
--S

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jon Kale
Sent: Wednesday, February 15, 2006 5:35 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] IronPython 1.0 Beta 3 Released!

Trying to add a reference to System.Xml, I get StackOverflowException. 

[] C:\Program Files\IronPython (Thu 16/02  1:19)
>IronPythonConsole.exe -X:TabCompletion
IronPython 1.0.2237 (Beta) on .NET 2.0.50727.42 Copyright (c) Microsoft
Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference("System.Xml")

Process is terminated due to StackOverflowException.

The fix appears to be to change AddReference(object reference):

private void AddReference(object reference) {
    string strRef = reference as string;
    if (strRef != null) {
        AddReference(strRef);
        return;
     }
     AddReference(reference, null);
}

but since this is my first time in the IP code I could well be wrong...
--
Jon

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

Reply via email to