[IronPython] Problem loading IronPython on Vista 64

Tue Mar 17 18:02:42 CET 2009

OK - did that.

Microsoft.Scripting.dll is reported in fuslogvw as being loaded
successfully!  The error is still reported in the application though, and
there are no other binding entries for IronPython.dll and friends.

If I attach to the process in VS and look at the loaded modules,
Microsoft.Scripting does not appear in the list - very confusing.

I have created a simple console application to test out referencing IPy and
this works fine.  So I guess I will just have to spend some more time
looking into why this particular application is problematic.

Many thanks,

Matt

2009/3/17 Curt Hagenlocher <curt at hagenlocher.org>

> You might want to consider logging all binds and not just failures.
>
>
> 2009/3/17 Matt Channer <mchanner at gmail.com>
>
>> I did try Assembly.LoadFile but this returned null, maybe for the same
>> reason that I was seeing initially - whatever that is :-)
>>
>> Fuslogvw now seems to be reporting binding failures (the setting I have is
>> to Log bind failures to disk).  Interestingly, none of the dlr / ipy
>> assemblies are being logged here.
>>
>> I will write a simple test app to see if that exhibits the same problem.
>>
>> Thanks for the help!
>>
>>
>> Matt
>>
>>
>>
>> 2009/3/17 Curt Hagenlocher <curt at hagenlocher.org>
>>
>>> Your explanation for the SysModule error sounds right -- if you use
>>> Assembly.LoadFile instead, you'll probably avoid that exception.  What
>>> settings are you using in fuslogvw?
>>>
>>>
>>> 2009/3/17 Matt Channer <mchanner at gmail.com>
>>>
>>>> Hi,
>>>>
>>>> The machine is pretty clean and has no dlr / ipy assemblies in the gac.
>>>>
>>>> fuslogvw is not showing anything for me at the moment so I need to
>>>> investigate that a bit more.
>>>>
>>>> I think the error in the SysModule constructor is because I used
>>>> AppDomain.CurrentDomain.Load(byte[]) to try and work around the original
>>>> issue (this was done in an AssemblyResolve event handler).
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>> 2009/3/17 Curt Hagenlocher <curt at hagenlocher.org>
>>>>
>>>> I don't know why there would be a difference between 32-bit and 64-bit,
>>>>> but do you possibly have a copy of any of the IronPython bits in your GAC?
>>>>>  As to the "invalid path" error, you're probably getting it from the line
>>>>>
>>>>> prefix =
>>>>> Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
>>>>>
>>>>> which is consistent with some kind of assembly-loading weirdness.  Odd
>>>>> that nothing shows in fuslogvw.
>>>>>
>>>>> 2009/3/17 Matt Channer <mchanner at gmail.com>
>>>>>
>>>>>>  Hi!
>>>>>>
>>>>>> I am using IronPython 2.0.1 in a hosted environment (c# application
>>>>>> running on 64 bit Vista).  This works well when the application is compiled
>>>>>> as a 32bit process, but I am getting the following error when running as an
>>>>>> x64 process:
>>>>>>
>>>>>> *Could not load file or assembly 'Microsoft.Scripting,
>>>>>> Version=0.9.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of
>>>>>> its dependencies. The specified module could not be found.*
>>>>>>
>>>>>> Fuslogvw is not helping at the moment (nothing is reported there).
>>>>>> All ipy \ DLR assemblies are in a sub directory which is included in the
>>>>>> assemblyBinding section of the apps config file (the error remains if they
>>>>>> are in the exe directory as well).
>>>>>>
>>>>>> I tried a workaround (read: hack) by handling the AssemblyResolve
>>>>>> event on the app domain and loading the files from a known directory.  The
>>>>>> problem I then encountered is an exception in the
>>>>>> IronPython.Runtime.SysModule constructor (line 46) as it sets the prefix
>>>>>> variable to the directory containing the assembly, which fails as the
>>>>>> Location is empty.
>>>>>>
>>>>>> Below is the full exception:
>>>>>>
>>>>>> *Microsoft.Scripting.InvalidImplementationException: Type
>>>>>> 'IronPython.Runtime.PythonContext' doesn't provide a suitable public
>>>>>> constructor or its implementation is faulty: The type initializer for
>>>>>> 'IronPython.Runtime.SysModule' threw an exception. --->
>>>>>> System.TypeInitializationException: The type initializer for
>>>>>> 'IronPython.Runtime.SysModule' threw an exception. --->
>>>>>> System.ArgumentException: The path is not of a legal form.
>>>>>>    at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
>>>>>>    at System.IO.Path.GetDirectoryName(String path)
>>>>>>    at IronPython.Runtime.SysModule..cctor()
>>>>>>    --- End of inner exception stack trace ---
>>>>>>    at IronPython.Runtime.SysModule.PerformModuleReload(PythonContext
>>>>>> context, IAttributesCollection dict)
>>>>>>    at IronPython.Runtime.PythonContext..ctor(ScriptDomainManager
>>>>>> manager, IDictionary`2 options)
>>>>>>    --- End of inner exception stack trace ---
>>>>>>    at Microsoft.Scripting.Utils.ReflectionUtils.CreateInstance[T](Type
>>>>>> actualType, Object[] args)
>>>>>>    at
>>>>>> Microsoft.Scripting.Runtime.LanguageConfiguration.LoadLanguageContext(ScriptDomainManager
>>>>>> domainManager, Boolean& alreadyLoaded)
>>>>>>    at
>>>>>> Microsoft.Scripting.Runtime.DlrConfiguration.LoadLanguageContext(ScriptDomainManager
>>>>>> manager, LanguageConfiguration config)
>>>>>>    at
>>>>>> Microsoft.Scripting.Runtime.DlrConfiguration.TryLoadLanguage(ScriptDomainManager
>>>>>> manager, AssemblyQualifiedTypeName providerName, LanguageContext& language)
>>>>>>    at
>>>>>> Microsoft.Scripting.Runtime.ScriptDomainManager.GetLanguageByTypeName(String
>>>>>> providerAssemblyQualifiedTypeName)
>>>>>>    at
>>>>>> Microsoft.Scripting.Hosting.ScriptRuntime.GetEngineByTypeName(String
>>>>>> assemblyQualifiedTypeName)
>>>>>>    at IronPython.Hosting.Python.GetEngine(ScriptRuntime runtime)
>>>>>>    at
>>>>>> Idbs.ActivityBase.DataImport.Scripting.ScriptingHosts.PythonScriptingHost.CreateEngine(String
>>>>>> configurationFile) in
>>>>>> C:\svn\xe\branches\anaconda\Shared\ImportProviders\PythonScriptingProvider\ScriptingHosts\PythonScriptingHost.cs:line
>>>>>> 148
>>>>>>    at
>>>>>> Idbs.ActivityBase.DataImport.Scripting.ScriptingHosts.PythonScriptingHost.ScriptCanMapByIdentifiers(String
>>>>>> configurationFile) in
>>>>>> C:\svn\xe\branches\anaconda\Shared\ImportProviders\PythonScriptingProvider\ScriptingHosts\PythonScriptingHost.cs:line
>>>>>> 52*
>>>>>>
>>>>>> So my first question: how come the assemblies are not being found?
>>>>>> Secondly, is the exception in SysModule something that I should log?
>>>>>>
>>>>>> Kind Regards,
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090317/64a9f70a/attachment.html>