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 <[email protected]> > You might want to consider logging all binds and not just failures. > > > 2009/3/17 Matt Channer <[email protected]> > >> 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 <[email protected]> >> >>> 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 <[email protected]> >>> >>>> 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 <[email protected]> >>>> >>>> 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 <[email protected]> >>>>> >>>>>> 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 >>>>>> [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 > >
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
