Thanks Dino! That fixes it. In case anybody is interested, I originally came across this problem while trying to host IronPython. In order to get workaround #1 working in a hosting situation, you'll need to do the following:
IronPython.Compiler.Options.ImportCompiledModule = false; Thanks again, Tony Dino Viehland wrote: > 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 > _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
