The fix for the Delphi 8 compiler to support .NET 1.1 SP1 is not going to be a simple as I had hoped. We can’t just ignore the version signatures of symbols imported from CLR because the Delphi compiler relies on those signatures to distinguish between different versions of overloaded methods. Changing the technique used to discriminate between overloads will require changing the dcu file format, which is where things leave the realm of “simple”.
We’re testing a solution for this issue in the Diamondback compiler currently in active development. So far, it looks solid. The new version calc is independent of token values and survives the token-shuffling transition from .NET 1.1 and .NET 1.1 SP1 (and back).
The current plan is to apply that compiler change to the D8 compiler codebase, rebuild everything, and then republish all the .dcuils and .dcpils that were shipped in the D8 box. That’ll be at least a few MB’s of stuff, and will probably also require that we create an MSI install. For something of this size, an informal build is out of the question.
This is a dcu breaking change. That means that dcuils and dcpils created by earlier releases of the Delphi 8 compiler will not work with this new build of D8. If you purchased or received units without source code, you will need to go back to the original author to obtain new .dcuil and .dcpil binaries for use with the new build of D8. If you have the Delphi source for the components you use, you have no issues whatsoever.
Again, this versioning issue is within the compiler cached symbols only. It does not affect the assemblies produced by the Delphi compiler – they will run great on .NET 1.1 as well as .NET 1.1 SP1, with this compiler change and without it.