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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [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 _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
