A Borland feature or bastardation of CLR? Continue...

Further to my previous blog questioning the wisdom of this 'feature', I have adjusted the demo and test out some of the scenarios mentioned.

Here I want to clear up a few things and to posit that this 'feature' creates more trouble than is worth.

I have removed the use of any C# assembly in my demo as it is always safer in highlighting problem in Delphi.Net to leave out C#.

Delphi.Net prevents one to use static linking when building DLL package (Delphi's term for .Net Class library) and only allows VCL.Net application to use static linking.

I will show below that while this is a good move but it will still create a confusing situation and that the compiler should have a switch to flag missing referenced assembly when building application.

It is worth noting that the normal CLR probing algorithm will look for this type "MyDemoLib.MyClass, MyClassLib" in MyClassLib.dll, MyClassLib\MyClassLib.dll, MyClassLib.exe and MyClassLib\MyClassLib.exe before it throws a type load exception, in the absence of any PrivateBinPath specification.

In other words, as far as loading a type is concern, it does not matter if the type is packaged in a DLL or executable assembly. I therefore argue that because of this added flexibility, Borland's porting of their static binding from VCL32 to VCL.Net not only creates an assembly in violation of ECMA-335 but also prevents the assembly from being exploited fully. This will be demanded below.

Moreover, Delphi.Net's prevention of DLL Package from using static binding while permitting application to use static binding destroys the symmetry that is part of CLR standard as demonstrated in the CLR Probing algorithm.

Incidentally when a type is loaded from a Delphi.Net executable, the initialization section in the DPR is completely by-passed. Using .Net executable assembly as a stand alone as well as publishing features that others can load, as an assembly, saves one from distributing executable as well as dll assembly. It also allows one to unit test types inside an executable without having to package them as DLL assembly.

At the moment, Delphi 2006 does not support adding a reference to an application or application project to another .Net project and hence any runtime interaction has to be done using late binding using technique such as System.Activator.CreateInstance(). Visual Studio 2005 is the only one that supports this. So you can effectively directs a VS2005 project to reference a VCL.Net application to use the type inside. In fact, this capability has been exploited to construct NUnit assembly to unit test types inside Delphi.Net application.

Because Delphi.Net/Pascal does not have qualifier to restrict types declared in the interface section to have CLR assembly visibility, all those types, that have to be declared in the interface section so that they can be accessed by types in other units, are free for anyone to use and this makes unit test very easy but creating a very loosely control design in .Net.

Now let consider some scenario.

App1.exe (dynamically linked) using types in App2.exe (statically linked)
This situation will prevent types that depends on VCL in App2 from being used in App1 for reason disclosed in my previous blog.

App2.exe (static bind) using types in MyDemoLib.dll
While Borland tries to make their DLL package to conform to the standard CLI, the MyDemoLib.dll is now prevented from being used in App2 because the above situation would result in two sets of distinct VCL classes.

I suppose in Vcl32 world, one cannot use types in an executable the same way as in .Net supports and as a result, the IPC mechanism insulates the difference.

I am also wondering why Borland or CodeGear prevents DLL Package from using static linking. In Win32, DLL is allowed to use either static or dynamic binding. If Borland is to maintain compatibility with Win32, it should support static binding in DLL. May be VCL32's dll does not have static linking.

As shown, because of the flexibility of the CLR Probing algorithm that does not distinguish DLL assembly from executable assembly as far as type loading is concern, the support of this so-called static binding in Delphi.Net gains nothing but creating compatibility issues for assemblies generated by Borland and ignoring the ECMA-335 standard.