[IronPython] wierd import problem

Dino Viehland dinov at exchange.microsoft.com
Mon Apr 23 23:24:38 CEST 2007


Oh, it seems to be the presence of the '.dll' in the filename (although I still haven't looked too deeply to understand the exception).  See below for the 3 different variations I've tried.  The .NET loader will append .dll/.exe for you automatically.

F:\repro\foo\Foo\bin\Debug>dir
 Volume in drive F is New Volume
 Volume Serial Number is F62E-82C1

 Directory of F:\repro\foo\Foo\bin\Debug

04/23/2007  01:45 PM    <DIR>          .
04/23/2007  01:45 PM    <DIR>          ..
04/23/2007  01:42 PM             4,096 Foo.Bar.dll
04/23/2007  01:42 PM            11,776 Foo.Bar.pdb
04/23/2007  01:42 PM             4,096 Foo.exe
04/23/2007  01:42 PM            11,776 Foo.pdb
04/10/2007  10:17 AM            71,016 ipy.exe
04/10/2007  10:17 AM            62,824 ipyw.exe
04/10/2007  10:17 AM            50,536 IronMath.dll
04/10/2007  10:17 AM         1,373,544 IronPython.dll
04/23/2007  01:45 PM    <DIR>          tmp
               8 File(s)      1,589,664 bytes
               3 Dir(s)  35,566,551,040 bytes free

F:\repro\foo\Foo\bin\Debug>.\ipy.exe
IronPython 1.1 (1.1) on .NET 2.0.50727.1318
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReferenceToFile('Foo.bar.dll')
>>> import Foo.Bar
Traceback (most recent call last):
  File , line 0, in <stdin>##14
  File , line 0, in __import__##7
SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it.
>>> ^Z

F:\repro\foo\Foo\bin\Debug>.\ipy.exe
IronPython 1.1 (1.1) on .NET 2.0.50727.1318
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Foo.bar.dll')
>>> import Foo.Bar
Traceback (most recent call last):
  File , line 0, in <stdin>##14
  File , line 0, in __import__##7
SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it.
>>> ^Z

F:\repro\foo\Foo\bin\Debug>ipyd
IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('foo.bar')
>>> import Foo.Bar
>>> dir(Foo.Bar)
['Bar']
>>>

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski
Sent: Monday, April 23, 2007 2:15 PM
To: Discussion of IronPython
Subject: Re: [IronPython] wierd import problem

Hi Dino,

Sorry, I should have mentioned in my original post that I've already
tried to get it to work with all the AddReference* methods.
AddReferenceToFile was just the last example that I tried at the time I
sent the original post.

Currently I'm still getting the same error.  I've even tried variations
on the assembly name (Foo.Bar.dll vs. Foo.Bar) and the AddReference
always seems to work, it's just that the import has problems.

I've just tried the example on another computer, and it's showing the
same issue.

Thanks for the help,
Tony


Dino Viehland wrote:
> I haven't had a chance to track down what the underlying problem here is (and suspect this is a bug), but is there a reason you can't do:
>
>>>> import clr
>>>> clr.AddReference('Foo.bar.dll')
>>>> import Foo.Bar
>
> This seems to work.  The only reason to use AddReferenceToFile is really if you are dealing with assemblies that live outside of your app domain base.  In that case AddReferenceToFile will attempt to use sys.path to search for referenced assemblies when the CLR loader attempts to load them.
>
> But if you're using this DLL from within your app domain base then doing AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which will succeed and also get the dependencies using the standard .NET way.
>
> Let me know if this is a reasonable workaround for you and I'll continue to look into the underlying issue here.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski
> Sent: Monday, April 23, 2007 12:36 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] wierd import problem
>
> Hi everyone,
>
> I'm seeing a bit of weirdness when trying to import a dll with a nested namespace.  Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace.
>
> OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation)
>
> I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe
>
> Here's the steps to reproduce:
>
>  >>> import clr
>  >>> clr.AddReferenceToFile('Foo.Bar.dll')
>  >>> import Foo.Bar
> Traceback (most recent call last):
>    File , line 0, in <stdin>##14
>    File , line 0, in __import__##7
> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it.
>  >>> for ref in clr.References:
> ...     print ref
> ...
> mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null  >>>
>
> As the output shows, Foo.Bar has been referenced.  So what am I doing wrong that I can't import?
>
> BTW, I'm using IP v1.1 (in case you're wondering).
>
> Thanks,
> Tony
>
> _______________________________________________
> 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



More information about the Ironpython-users mailing list