>>However, if an older version of the service is installed and we attempt an upgrade install, the interop dll does not get overwritten.
>
>Most likely the DLL is in use and can't be overwritten. If it's a service in particular it might be in use from IIS (or whatever hosting executable is running the service) since it's always on.
>
>What are you doing for the 'upgrade install' exactly? I suppose that greatly determines how the process of copying the files and checking versions occurs.

I realize I didn't explain the entire thing clearly, so I'll take a step back.

We have a VFP COM DLL which is being used by our VB.Net service. The DLL is added as an isolated reference to the service, and the interop DLL is generated automatically. When we make changes to the VFP code, the automated build will create a new version of the VFP DLL, check out the DLL from the VB project, copy it, and check it back in. After that, the automated build will increment the version number on the installer project and then build the VB project.

When a newly built install is run on a system that has an older version of the service already installed, it should uninstall the prior version and copy new files down. What I found out is that this works for all files except the interop.