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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony
>> Djordjevski
>> Sent: Monday, April 23, 2007 12:36 PM
>> To: [email protected]
>> 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
>> [email protected]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
