Yes, the current implementation is not ideal. There are 3 ways to load assemblies in .NET: Load, LoadFrom, and LoadFile. - In order to use Load, the generated assemblies have to be strong named; which means the ironpython dlls has to be strong named too. - If an assembly with the same identity is already loaded, LoadFrom returns the loaded assembly even if a different path was specified (from http://msdn2.microsoft.com/en-us/library/1009fa28.aspx). This blocks loading different copies of __init__.exe. - The current implementation chose LoadFile, however it prevents us to call GetCustomAttribute on the loaded assembly for some reason.
In the future, we will probably look into LoadFrom, and explore approaches to differentiate identities of __init__.exe (and other possible assemblies with same name), and check some kind of custom attribute. Ideally, we should try to keep the pre-compiled modules' back compatibility for minor version update. For now, the current setting should give you the least surprise: - you won't get MissingMethodException when IronPython.dll changed some APIs. - you will always see the updated behavior when .py source is updated. I will file a work item to track such upgraded-ironpython scenario. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill Sent: Monday, January 22, 2007 8:03 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? At 09:24 PM 1/22/2007, Keith J. Farmer wrote >the upgraded-ironpython scenario > >>>> I do not think this is supported. The pre-compiled module has much >>>> dependency on IronPython.dll. Some emitted calls in those modules could be >>>> changed (or removed) in the next version of IronPython.dll. > > >That makes me itch... I understand runtime dependencies, but the >binaries-only deployment scenario just dropped in value if they are completely >invalidated because the runtime undergoes a minor rev (or is otherwise >touched). > >Would it be possible for the runtime to query the assembly to determine if >it's compatible or not? Some sort of poor man's static analysis (eg, a >manifest of API dependencies could be generated when the assembly is stored to >disk, and if the runtime doesn't find any in the list that match any breaking >change from the producing version, it accepts it). > > >________________________________ > >From: [EMAIL PROTECTED] on behalf of Haibo Luo >Sent: Mon 1/22/2007 4:44 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import >pre-compiledmodules > > > >If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should >expect an exception? > >>>> Yes > >[snip] J. Merrill / Analytical Software Corp _______________________________________________ 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
