[IronPython] Problem loading IronPython on Vista 64

[Curt Hagenlocher]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090317/9648b71f/attachment.html>