Two quick answers:
1. It's not critical, unless you need access COM objects (like
Word/Excel automation or something).
2. The exact same code is in 2.7, and I think it's still active.
3. I can't understand why it would break like that when examining
those assemblies.
Dino? Thoughts?
- Jeff
On Mon, Aug 8, 2011 at 12:27 PM, Igor Brejc <igor.br...@gmail.com> wrote:
> Well in the end I built it from the ZIP package :).
> Anyway, here are some results. IP always breaks down when
> examining System.Runtime.Hosting.ActivationArguments type, on the
> if (type.IsImport && type.IsInterface)
> line. This is the only type the method breaks down on.
> PublishComTypes examines the following assemblies:
> 2011-08-08 20:18:48,971 DEBUG [1]
> Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
> (interopassembly='mscorlib, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089')
> 2011-08-08 20:18:50,490 DEBUG [1]
> Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
> (interopassembly='System, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089')
> 2011-08-08 20:18:51,451 DEBUG [1]
> Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
> (interopassembly='mscorlib, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089')
> 2011-08-08 20:18:52,695 DEBUG [1]
> Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
> (interopassembly='System, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089')
> Questions:
>
> Is there any reason why both assemblies are examined twice?
> How critical is this method for running IP? In other words if I comment it
> out, would IP be able to work normally?
> Is there an improved version of this code in 2.7? The code comments say
> "Since scanning all loaded assemblies can be expensive, in the future, we
> might consider a more explicit user binder to trigger scanning of COM
> types."
>
> One other strange thing: _sometimes_ (looks like randomly), the method
> throws AccessViolationException right at the start,
> when AssemblyTypeNames.LoadTypesFromAssembly() is called on the mscorlib
> assembly. I haven't added any logging in that method, so I cannot say where
> exactly this happens. I can extend the logging if necessary.
> Pasting the method code (without my logging code):
> public static void PublishComTypes(Assembly interopAssembly)
> {
> #if !SILVERLIGHT
> lock (_comTypeCache)
> { // We lock over the entire operation so that we can publish a
> consistent view
> foreach (Type type in
> AssemblyTypeNames.LoadTypesFromAssembly(interopAssembly, false))
> {
> if (type.IsImport && type.IsInterface)
> {
> Type existing;
> if (_comTypeCache.TryGetValue(type.GUID, out
> existing))
> {
> if
> (!existing.IsDefined(typeof(CoClassAttribute), false))
> {
> // prefer the type w/ CoClassAttribute
> on it. Example:
> // MS.Office.Interop.Excel.Worksheet
> // vs
> // MS.Office.Interop.Excel._Worksheet
> // Worksheet defines all the interfaces
> that the type supports and has CoClassAttribute.
> // _Worksheet is just the interface for
> the worksheet.
> //
> // They both have the same GUID though.
> _comTypeCache[type.GUID] = type;
> }
> } else
> {
> _comTypeCache[type.GUID] = type;
> }
> }
> }
> }
> #endif
> }
>
> On Mon, Aug 8, 2011 at 8:35 PM, Jeff Hardy <jdha...@gmail.com> wrote:
>>
>> IronPython_2_6 should be all you need. The rest is the start of 2.7
>> that later got moved to GitHub.
>>
>> - Jeff
>>
>> On Mon, Aug 8, 2011 at 10:50 AM, Igor Brejc <igor.br...@gmail.com> wrote:
>> > Hi Jeff,
>> > One question: I'm looking at the codeplex SVN repository (since I assume
>> > this is where 2.6.2 code still resides). What exactly do I need to check
>> > out
>> > in order to be able to build it? IronPython_2_6 directory or the whole
>> > repository? There seems to be a lot of stuff in the IronPython_Main dir.
>> > Thanks,
>> > Igor
>> >
>> > On Mon, Aug 8, 2011 at 7:17 PM, Igor Brejc <igor.br...@gmail.com> wrote:
>> >>
>> >> Hi Jeff,
>> >> Thanks for responding. I'll update the SO question if/when someone (I
>> >> guess it will probably have to be me) figures out what the problem is.
>> >> One update: we did some more debugging. The user installed IronPython
>> >> 2.6.2 msi (.NET 2.0) and ipy64.exe breaks down when run. I guess this
>> >> excludes any of my code or the fact that IP was used outside of GAC.
>> >> What's strange is that sometimes it's AccessViolationException and
>> >> sometimes NullReferenceException (but the failing method is the same).
>> >> So I guess I'll need to build a custom IP build with some log4net
>> >> logging
>> >> of that method, since live debugging is not a realistic option here.
>> >> Thanks for your help,
>> >> Igor
>> >>
>> >> On Mon, Aug 8, 2011 at 6:12 PM, Jeff Hardy <jdha...@gmail.com> wrote:
>> >>>
>> >>> Hi Igor,
>> >>>
>> >>> The exception is occurring somewhere in IronPython's COM interop code,
>> >>> but I'm not exactly sure why - the code where the exception occurred
>> >>> pulls COM types out of interop assemblies. You'll have to (somehow)
>> >>> figure out what assembly is getting loaded in the AppDomain when the
>> >>> exception happens, which will probably require live debugging or a
>> >>> custom IronPython build.
>> >>>
>> >>> I'm not sure if it's a bug in IronPython, or if there's a squirrelly
>> >>> COM object on the user's machine that causes IronPython to break, but
>> >>> my guess is the latter.
>> >>>
>> >>> - Jeff
>> >>>
>> >>> P.S. I saw your SO question before this, but feel free to keep the
>> >>> discussion where ever you prefer.
>> >>>
>> >>> On Sat, Aug 6, 2011 at 11:12 PM, Igor Brejc <igor.br...@gmail.com>
>> >>> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > I'm developing a cartography application (http://maperitive.net) in
>> >>> > C#
>> >>> > and I plan to use IronPython as a scripting extension of the
>> >>> > application. I've been successfully using IronPython for several
>> >>> > months and most users don't have any issues with it, but a small
>> >>> > percentage of users is having problems.
>> >>> >
>> >>> > With the help from one of them I managed to dig out the exception
>> >>> > stack trace. The exception occurs while calling the
>> >>> > Python.CreateEngine() method:
>> >>> >
>> >>> > System.Reflection.TargetInvocationException: Exception has been
>> >>> > thrown
>> >>> > by the target of an invocation.
>> >>> > ---> System.Reflection.TargetInvocationException:
>> >>> > Failed to load language 'IronPython 2.6.2': Attempted to read or
>> >>> > write
>> >>> > protected memory. This is often an indication that other memory is
>> >>> > corrupt.
>> >>> > ---> System.AccessViolationException: Attempted to read or write
>> >>> > protected memory. This is often an indication that other memory is
>> >>> > corrupt.
>> >>> > at
>> >>> >
>> >>> > Microsoft.Scripting.Actions.TopNamespaceTracker.PublishComTypes(Assembly
>> >>> > interopAssembly)
>> >>> > at
>> >>> >
>> >>> > IronPython.Runtime.Binding.PythonBinder.DomainManager_AssemblyLoaded(Object
>> >>> > sender, AssemblyLoadedEventArgs e)
>> >>> > at IronPython.Runtime.Binding.PythonBinder..ctor(PythonContext
>> >>> > pythonContext, CodeContext context)
>> >>> > at IronPython.Runtime.PythonContext..ctor(ScriptDomainManager
>> >>> > manager,
>> >>> > IDictionary`2 options)
>> >>> > --- End of inner exception stack trace ---
>> >>> > 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)
>> >>> >
>> >>> > I couldn't find anything on Google that would be related to this.
>> >>> > Some
>> >>> > info about the user's environment:
>> >>> >
>> >>> > - Win7 64bit
>> >>> > - Using .NET 2.0-3.5 (not 4.0)
>> >>> > - IronPython is not installed in GAC, the app uses assemblies
>> >>> > locally
>> >>> > on the disk (v 2.6.2)
>> >>> > - The user runs the application as an ordinary user (not
>> >>> > administrator)
>> >>> >
>> >>> > I use Win7 64bit myself, but I didn't have any such problems and I
>> >>> > cannot reproduce this problem on any of my machines (Win7, Ubuntu).
>> >>> >
>> >>> > Thanks for any help,
>> >>> > Igor Brejc
>> >>> > _______________________________________________
>> >>> > Ironpython-users mailing list
>> >>> > Ironpython-users@python.org
>> >>> > http://mail.python.org/mailman/listinfo/ironpython-users
>> >>> >
>> >>
>> >
>> >
>
>
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users
