So there is this little known tool that ships as part of the framework SDK. It is referred to as the assembly linker, but on disk it’s called al.exe. I like to call it just ALink. So what’s the point of a linker that doesn’t really link? I’ll tell you. First of all, by it’s size you can probably tell, al.exe is little more than a command-line driver for the real ALink (which is actually part of the framework redist and is called alink.dll). In the native work you static and dynamic linking. In the managed world, you only have dynamic (ignoring managed C++ for a moment). Even for dynamic linking there is some goo that has to be stuffed in the binary, like the file to link to, and a bunch of function names and stuff so the OS can apply fix ups to the binary when the DLL gets loaded (sorry if this is a review for most of you). Well in the managed world we have assemblies, not just DLLs. And those assemblies have a lot more baggage that needs to be taken care of besides just a filename. ALink is mostly used by the C# and VB compilers to generate proper assembly references, or at least that was ALink’s primary purpose. After a while, it has slowly become a common dumping ground for features that needed to be shared between VB, C# or even C++ (yep, the C++ compiler and linker also use ALink).
Well, before I bore anybody to death I’ll stop right there. And no this is not an April Fool’s joke (I’m just not that creative). If you want to hear more about nitty-gritty history and implementation details like this. Send me feedback, otherwise I’ll try and stick to funnier stuff like iterators, and my front lawn.