I have found this remark from Danny Thorpe in the borland.public.delphi.non-technical that explains why Delphi 8 breaks after updating the .NET Framework with SR1. Here is the quote:
Reason: The .NET 1.1 SP1 assemblies (mscorlib, etc) contain new symbols, and the metadata tokens for old symbols have been renumbered. The Delphi compiler uses those tokens in symbol identity calculations that are stored in the .dcpil compiler symbol caches.
Normally, this would not be a problem because an assembly that is modified to contain additional symbols would have a different time/date stamp than the original assembly that the .dcpil file was built from. However, Microsoft service packs do not update the assembly version number or the file date/time stamp even though they change the contents of the assembly.
I openly admit that using the token values in symbol identity calculations was a poor choice on my part. My error was in believing the assembly file timestamp would change if the tokens ever changed. Silly me.
We're working on a solution. It will probably involve either softening the symbol identity calculation to not include CLR tokens at all or changing the version check to tolerate CLR token flutter or some combination of both. I'm hopeful that a solution can be worked out that will not require breaking the D8 DCU format, but I haven't found that solution yet.
I have to give Danny huge compliments for coming forward and admitting that there may have been some design flaws. Even the best developers and architects make decisions that are found to be in error at some later date. We should not condemn them but learn from them. I have full confidence that there will be a fix very soon for Delphi 8. I bet the fix has not come already is due to BorCon happening last week. :)
No comments:
Post a Comment