[IronPython] wierd import problem
Dino Viehland
dinov at exchange.microsoft.com
Mon Apr 23 23:52:40 CEST 2007
It's an alias to run IronPython 2.0 in my dev environment :( I don't think we've actually ported the pre-compiled module feature to the v2.0 branch so this just works there.
Ok, so either this is a bug or a feature depending on how you look at it (we either be ignoring the DLL or our complaining loudly is the right thing, depending upon your perspective). Anyway, I've opened a new bug (#9807):
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9807
There's two work arounds for this issue:
#1) Run w/ -X:NotImportCompiled, this disables this feature which is raising this exception.
#2) Use the assembly object directly instead of importing the namespace:
import clr
asm = clr.LoadAssemblyByName('Foo.bar')
inst = asm.Foo.Bar.Bar()
I've even made sure they work right on v1.1 this time :)
Thanks for the bug report and sorry for messing up the repro. Hopefully one of those workarounds will work for you.
-----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:43 PM
To: Discussion of IronPython
Subject: Re: [IronPython] wierd import problem
Dino,
What's ipyd? I noticed in your example that worked, you ran that
instead of ipy.
Here's the output I'm getting:
C:\Temp\Foo\bin\Debug>dir
Volume in drive C has no label.
Volume Serial Number is 5454-DE81
Directory of C:\Temp\Foo\bin\Debug
04/23/2007 02:55 PM <DIR> .
04/23/2007 02:55 PM <DIR> ..
04/23/2007 02:55 PM 16,384 Foo.Bar.dll
04/23/2007 02:55 PM 11,776 Foo.Bar.pdb
04/23/2007 02:55 PM 16,384 Foo.exe
04/23/2007 02:55 PM 11,776 Foo.pdb
09/23/2005 07:56 AM 5,632 Foo.vshost.exe
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
9 File(s) 1,619,872 bytes
2 Dir(s) 91,054,919,680 bytes free
C:\Temp\Foo\bin\Debug>ipy
IronPython 1.1 (1.1) on .NET 2.0.50727.42
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: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module;
try again after deleting it.
>>> ^Z
C:\Temp\Foo\bin\Debug>ipy
IronPython 1.1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('Foo.Bar')
>>> 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.
>>> ^Z
C:\Temp\Foo\bin\Debug>ipy
IronPython 1.1 (1.1) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference('foo.bar')
>>> 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.
>>> ^Z
The last example was a "shot in the dark" attempt to see if case had
anything to do with the AddReference. I didn't actually expect it to work.
Dino Viehland wrote:
> 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
> _______________________________________________
> 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