ok, so far for the library assembly. let's now see what the package assembly offers us. as soon as you select the new package option, you get a different view in the project manager, as shown in figure 4 (compared to figure 3).
a delphi 8 for .net package automatically gets the borland.delphi.dll assembly added to the requires list, so we won't get any problems with duplicate borland.delphi.system namespaces if we want to use it in a delphi 8 for .net project later. and we can add units to the contains node, like the hardcore.delphi.final.issue unit with our trandomnumber class. compiling the package will lead to a package1.dll assembly of 6.5 kbytes big. hmm, i've seen that number before. that's exactly the same size we ended with when building the library1.dll assembly - only took it three steps to get it right.
the package1.dll assembly can be used in any development environment, including delphi 8 for .net, but it has the slight disadvantage that you need to deploy all required units together with the assembly. in this case, that's only the borland.delphi.dll (with the delphi 8 for .net system unit), but as soon as you include some vcl units, then you also need to add the delphi.vcl.dll assemblies to the requires list, since you cannot implicitly import units into the package. in fact, the original delphi 8 for .net would only give you warnings if you tried to implicitly import units into the package, but after the first update, the delphi 8 for .net compiler already turns this into errors. this will help to enforce the explicit linking of external references, so you will never get duplicate linked units like you can get with the library assemblies.
using package1 assembly
so, just as an example, let's see how easy we can use the package1 assembly in a delphi 8 for .net application. start a new project - winforms or vcl for .net - and right-click on the project node to add a reference. in the add reference dialog, select the package1.dll assembly to add it to the reference list. you can now right-click on the package assembly again, and note two special options. there is copy local option, which is already checked. this means that the external assembly will be copied to your project directory, to ease the deployment later. the other interesting option is the link in delphi units, and is only available for assemblies build with delphi 8 for .net. it offers us the ability to do the reverse of using external packages: link in all delphi 8 for .net assemblies and result in one big executable. note that this should only be done with executables, and not with libraries since we've just seen that these should use references as much as possible to be useful in the first place.
adding the package1 assembly to the references list is one thing, but that doesn't ensure that we can use the trandomnumber class. we now have to add the namespace (that defined the trandomnumber class) of the package1 assembly to the uses clause. that namespace is hardcore.delphi.final.issue, since it was unit hardcore.delphi.final.issue that contained the definition and implementation of the trandomnumber class. so, add hardcore.delphi.final.issue to the uses clause of the project (you may want to rename the hardcore.delphi.final.issue.pas unit on your machine to make sure delphi isn't cheating and using the unit source code instead of the imported namespace from the package1.dll assembly).
now that the namespace is available, you can get to the trandomnumber class, create it, call the random10 method, or even derive a new class from it. the latter is also possible it you're creating a new package assembly, adding the original one to the requires list, and defining a new tbetterrandomnumber class derived from trandomnumber.
to summarise the differences between a package and a library: if your assemlby (.dll) is built from delphi library syntax, there is no delphi symbol information available, so our view of the dll will be limited to what delphi can represent in clr metadata. we will lose delphi language specific details such as virtual constructors, virtual class functions, and set types, to name a few. the recommandation from the delphi r&d team is to build .net assemblies using the delphi package syntax, and link against it using the .dcpil.
back to the library
