Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have an old application that I am migrating to new web hosting. I had full access to the old web server, so for that particular site I had to register a DLL on the actual windows 2003 server. The DLL has to do with the FDF toolkit from Adobe ( http://www.adobe.com/devnet/acrobat/fdftoolkit.html ).

The new webhost, which I do not have full access to ( I am using rackspace cloud now ), does not allow me to register DLL's directly on the server.. which makes complete sense. I was told I could throw the DLL's into a bin folder in my application root. I dont believe that this is working. Also, here is a link which describes how your supposed to register the DLL's, http://www.15seconds.com/issue/990902.htm

*Edit: this guy has my exact question without answer :( http://objectmix.com/adobe-acrobat/215497-asp-net-2-0-fdf-toolkit-dll-registration.html

Here is the error I am getting:

Server object error 'ASP 0177 : 800401f3'    
Server.CreateObject Failed    
/pdfinterface/viewPDF.asp, line 26 
800401f3

And here is line 26 and 27:

Set FdfAcx = Server.CreateObject("FdfApp.FdfApp")
Set myFdf = FdfAcx.FDFCreate

Am I basically screwed? I dont think this DLL was designed to be loaded by IIS..

share|improve this question

2 Answers 2

The only way the DLL will work without registering it on the server is if it's managed code for .NET.

You will see wrapper DLL's for ASP.NET but even they need to have the core DLL registered on the server.

Additionally, since you're using Classic ASP, dropping something into the /bin folder wouldn't help, even if it was fully managed.

So, unfortunately your only option, apart from another hosting platform that allows registering DLLs, is to move to a fully management component and calling it from ASP.NET.

share|improve this answer

I think the reason it is failing is because the COM dll is not registered, and it has to be registered somewhere, either on the machine (in HKEY_CLASSES_ROOT) or in a per-user registration (in HKEY_CURRENT_USER\Software\Classes). The latter might be a viable solution. I found a tool that allows per-user DLL registration. You may be able to use it to register the DLL using the credentials under wihch the IIS process runs.

share|improve this answer
    
looks like it only works on windows 2003. im looking at wrapping the DLL for .net. read somethin about that. –  Roeland Oct 15 '09 at 16:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.