Now that you know the basic terminology we can begin exploring the situation I found myself in that called for this descent into DLL Hell. If you have not reviewed the terminology yet I strongly encourage you go back to Part 1 and do so. In fact it’s not even encouragement. Stop reading and go read it.
The whole labor started with a Custom Authentication Provider for an FTP Server. Nothing too terrible except this server was setup using IIS 6 (the current version is 8). From here it’s just a slippery slope. Fortunately that means less walking and none of that messy business of crossing a river of sticks or paying two gold pieces to get ferried across.
The majority of the problem was due to the fact that IIS is a pre-compiled application and is not open source, therefore you have to compile your Custom Authentication Provider into a DLL and register it in the Global Assembly Cache (GAC) so other applications can use it. Since the GAC is global, Microsoft felt it necessary to include security measures i.e. Strong-Naming. The problem with requiring strong-named assemblies is any third party assemblies referenced also must be strongly named. That’s all good and dandy until the Third Party doesn’t offer a strong-named version of their assembly. Fear not, that’s one of Cerberus’ heads and I’ll be teaching you how to force it into submission. What all this means is minor changes, like changing port numbers in your database connection string requires new assemblies be compiled, named, versioned, and registered in the GAC. This is what I call a Rube Goldberg setup.
The second set of problems were caused by a series of upgrades I had performed about a month prior in conjunction with a database upgrade. The database required a new driver, which required a newer version of the .NET Framework and that meant the old DLL would no longer work. Why would the old DLL not work you ask? Good Question! Let me say it in bold since the documentation barely mentions it,
“by default assemblies will only run under the same .NET Framework Version used to compile it.”
Basically, the .NET Framework targeted in Visual Studio i.e. the *.csproj file had best be installed on the computer this assembly will run on otherwise you have just entered the first ring of Dll Hell. I also had the privilege of dealing with such an old version of Microsoft Server the new .NET Framework version wasn’t compatible with the OS. Are you seeing the Herculean feat developing?
If all that were not enough, I had two more problems. The first being all the original developers had either left the company or had not worked on the system in years, so there was no Oracle of Delphi to answer questions. The second as every programmer has probably guessed by now, there were no comments…at all…not a one. I was condemned to complete this labor alone.
I don’t mean for this to sound like I am complaining, cause I’m really not. I just want to express I was new to this whole concept. There were very few quality/applicable resources available and that is what really made this difficult. I couldn’t assume anything so I had to track down every unknown and understand it before I could piece the solution together. To not make this entire post about the problems let’s talk about the resolution.
The high level steps were evident.
The path to completing those steps were not so evident. After discovering and understanding the dependencies detailed above I came up with the following steps that would build bottom up and resolve conflicts on the way.
Next time we start on Cerberus’ first head, Strong-Named Assemblies. The rest of the posts in this series will get into the nitty gritty details of .NET assemblies.