Well, as many of you have known, I’ve been working on projects that involve the dark side - that being Microsoft projects. Yes, this means I’ve been working on .Net applications in both Visual Basic and C#. The C# applications are kinda fun to work with, but I still maintain that VB is a ridiculous language, despite the fact that both VB and C# compile to the same intermediate code.
In any case, I’ve been working on a legacy application that uses Crystal Reports to handle it’s reporting. For anyone looking for an opinion on Crystal Reports - don’t get it and don’t even think about touching it with a 10 foot pole. It’s nasty, bulky, and extremely difficult to install and configure with applications appropriately. This is the whole purpose of this post.
This application is being run on a Windows Server 2003 w/ Service Pack 2 server behind a firewall accessible only through VPN. Visual Studio .Net and Crystal Reports 8 and 10 are installed on the server (read below why this is, I won’t explain here). This project has no project or solution file, as it was written in 2003 and the developer in-charge had a certain way of running projects for the web, which was not the most ideal. Needless to say, he’s no longer with the group. :-D
When trying to run the application, I get the following nice 500 level error message from IIS:
Fun. So, I spent about 4 hours yesterday and an hour this morning looking up what the possible answer could be. One of the first things I see on Google is people mentioning the addition of certain Merge Modules to the solution for the project. Such an example can be found on the vbCity/devCity.Net Forums. However, this solution doesn’t apply in my case because of the following reasons:
- We aren't using solution files.
- I've never seen any merge module packages installed or added to any part of the large project.
- We aren't "deploying" the application, but rather are putting it on a server that is setup like the developer workstation, ie: Visual Studio .Net (2002) is installed, the developer edition of Crystal Reports 8 and 10 are installed.
Please refrain from making comments regarding all of the atrocities listed above. I understand that this project is awry and should be scrapped, remade, yadda yadda. However, I have voiced these concerns to the appropriate individuals and we have to get approval from our customer before proceeding with said fix.
So, what other possible solutions for this problem could exist, I wonder? More Googling yields a potentially worthwhile solution which requires access to the registry. That’s fine with me, as I’m used to working in the registry. This BusinessObjects Knowledgebase article stated that I need to modify the following 2 registry keys and give access to the user that ASP.NET is running as. The keys are:
When I gave the ASP.NET user read access to the files, I then reloaded the page and got the same error message. Reading the article further revealed that I had to register the keycodev2.dll file via regsvr32. Well, upon issuing the following command:
I get the following error message:
The knowledgebase article then stated that I needed to look at another Knowledgebase Article which turned out to be total nonsense. So, back to Google.
I then found this absolutely brilliant article that discussed a potential solution to the error listed above. However, this sent me jumping through hoops to try to look at the dependencies of the keycodev2.dll file and then try to monitor the registry entries that were being hit, only to reveal no such luck. So, I continued looking for another solution online and found yet another Knowledgebase article that discussed a fix when deploying a Crystal Reports application. This didn’t resolve or even come close to the overall issue, but I finally found a PDF article that was right up the alley of what I was trying to do, especially in terms of hosting the application. Unfortunately, it contained the same bit of information that the first knowledgebase article had in it. But, there was something in the article that made me realize what the problem was - access to the registry.
I had known this entire time that my user account had Administrative privileges. Unfortunately, Administrative privileges doesn’t always mean that everything is readable and writable by the Administrator. Sure enough, when I looked back at those registry keys listed above, neither had even read access for the Administrator. I quickly gave the Administrator account Full Control and made sure it permeated to all subkeys under each of those keys listed above. I reran the regsvr32 command listed above and v’oila! The DLL registered successfully!