-X:PreferComDispatch is gone. We used to support using either the normal .NET typelib approach for com interop or the more dynamic form of COM interop we have now. We no longer use the normal .NET typelib option.
My guess is that we can close most of these bugs because we think the new way is correct and effectively accepted the breaking changes. I think the goal for COM interop should be to be compatible w/ CPython using pywin32. So if the bugs represent an incompatibility vs. CPython we could keep them, otherwise close them. Unfortunately fixing these might also be breaking changes so we'll need to be careful there too so we're not constantly breaking COM interop. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Richard Nienaber Sent: Sunday, January 16, 2011 1:23 AM To: Discussion of IronPython Subject: [IronPython] Issue Triage I've closed the following issues: test blocking: support setting field of value type when calling ctor<http://ironpython.codeplex.com/workitem/24008> keyword argument is also treated as args for params array<http://ironpython.codeplex.com/workitem/24000> unable to invoke delegate object with method which takes ref args<http://ironpython.codeplex.com/workitem/24009> binder does not handle argument list with keyword and tuple correctly for .net methods<http://ironpython.codeplex.com/workitem/24001> tracking: wrong message when calling System.Activator.CreateInstance(None)<http://ironpython.codeplex.com/workitem/24007> clr.AddReference need invalidate the cached rules related to NamespaceTracker<http://ironpython.codeplex.com/workitem/24012> Questions: * Incompatibility between CPy and IPy in the way REG_EXPAND_SZ works in _winreg module.<http://ironpython.codeplex.com/workitem/24042> It seems to me that in this case that IronPython was doing the right thing, and CPython was doing the wrong thing. REG_EXPAND_SZ<http://msdn.microsoft.com/en-us/library/ms724884(v=vs.85).aspx> seems to mean that environment variables should be expanded when the value is inserted into the registry. I've assumed here that even if CPython does the wrong thing, IronPython should follow the behaviour of CPython (and closed the issue). * Code has recently been added to fix this issue: types in assemblies loaded with .AddReferenceToFileAndPath() are not importable if they reference other assemblies<http://ironpython.codeplex.com/workitem/25124> Should I close this one as well or does this need to make it into a build first? * -X:PreferComDispatch I have come across quite a few issues where there are inconsistencies when IronPython is started with/without the '-X:PreferComDispatch' switch (like this one<http://ironpython.codeplex.com/workitem/24013>). If I look at the IronPython console help this switch is absent and attempting to run it gives me the error 'File -X:PreferComDispatch does not exist.'. Is this option no longer available/supported? If not, what should be done with these issues? Richard
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
