Yes, you shouldn't have to go thru all of that. You need the vfpt?.dll runtime as well as the language runtime. You'll need: yourdll.dll, yourdll.tlb, and yourdll.vbr. BTW, all of these files should be the same version/sp of vfp. Create a physical directory on the new computer to contain these files. REGSVR32 yourdll.dll. Create a virtual directory in IIS over the physical directory and make it a "pooled" or "high isolation" application (right there in the IIS console). Now if you need to replace it, you just push the "Unload" button for this virtual directory. Note that all of these steps can be automated: you can create an Installshield app to copy and register the needed files and even to set up the virtual directory. I created a project hook (in the downloads here) that automatically unloads the dll before you recompile the project that creates it...
>We have successfully built a web service DLL ... yeah ... the problem we are having is publishing it. To make a long story short, we've had to install VFP on the web server and build the .DLL on that macchine to get it to work.
>
>Our process is:
>
>1. IISRESET /RESTART
>2. Build DLL directly to the installation subdirector from the VFP Installation on the server.
>
>Obviously we are missing something as this should not be a requirement to publishing a new version of a DLL. We did check the Generate New Component IDs.
>
>What we think we should be able to do is stop and restart the web server to release IIS' hold on the dll. Compile the dll on the development machine and copy the dll to the installation directiory.
>
>Can someone that has a clue tell me what I am doing wrong?
>
>Thanks,
>
>CTBlankenship