Wasting a whole week because of some "Borland feature"

Late last year, by accident I discovered this "Borland feature" whereby Delphi.Net compiler will suck the type and all its necessary supporting types from one assembly and dump them into the assembly you are referencing it, if you do not declare the depending assembly in the project.

One respondent to my blog said:

This is a common mistake that many people make, so don't feel bad. Let me explain. When you referenced the Borland.Vcl.Forms unit and did *not* reference the Borland.Vcl.dll assembly, you linked into your application a new and distinct copy of Borland.Vcl.Forms and all the types therein.

This same exact scenario is possible using C# simply by including the same class into to two different assemblies or in an assembly and an application.

This sounds too illogical as one cannot compare source file binding as in C# to one that transfer chunks of IL code from one assembly to another in complete disregard to the ECMA-CLI specification in relation to the definition of type.

Perhaps Borland/CodeGear can post some example how I could achieve this without source file in C#.

Anyway, I then outlined a number of scenarios that this "Borland feature" will get developers into deep trouble.

I have unfortunately (but fortunately for Borland) that I missed a few. My colleague, a Delphi programming veteran of more than 10 years, fell into one that I did not reported and it took 2 developers one whole week to unravel this mystery.

In the end, the trusted Type.AssemblyQualifiedName confirmed the minefield.

The scenario was compounded by another Type-dropping bug. The .Net architecture we tried to realise involved a number of assemblies (some are packages while others are executable assemblies being use as if they are dll assemblies).

This Type-dropping bug for some reason causes the types to be rammed into the assembly referencing the types via the Delphi Metadata as oppose to the IL metadata. Lutz Reflector confirmed the bug had discarded the expected types.

Because Borland's relying on Delphi metadata as opposed to IL metadata, Delphi.Net compiled and produced assemblies. But at run time, CLR ruled the world and the assemblies thus produced bite the dust.

All without informing the user of this wonderful feature during compilation. This stealthiness is mainly my complaint as Borland is free to add whatever it sees fit to violate ECMA creating .Net incompatible assemblies. It has lots of warning about platform depending features being used.

But it must also allow and in fact encourage the user to choose to comply with ECMA so that what one produces will play well in the .Net world. Their compiler does not have a switch to turn this feature on or off.

This kind of stupidity, which benefits very few, caused 2 senior developers' one whole week and I am sure there are many other victims like me. We knocked up a C#/VS2003 solution that mimicked the architecture in less than 15 minutes to confirm the architecture was sound.

Of course VS2003/C# does not have this Type-dropping bug. I could as well use C# Builder to perform this validation check. It is not a VS verse C# Builder contest.

One of the alleged benefit of this "Borland feature" is to allow developer to choose how to deploy the application - one executable and a bunch of DLL's or all in one.

While I do not dispute this alleged benefit in Delphi.W32 land (there is no standard of any sort in that area), doing this in CLI is not only wrong, in clear violation of ECMA standard, but also totally unnecessary.

The reason is that you could either use ILMerge or Borland's own version DILMerge. It is better for Borland to discard this dangerous practice, to promote the use of these tools and to encourage Delphi developers to write proper .Net assemblies.