Are you incrementing the version number in the COM DLL? I would think that that's crucial in order for the installer to detect the changes?

Another option: Skip the Interop assembly and go with dynamic typing in .NET 4.0. This removes the interop assembly and provides direct access (w/o strong typing however) for the COM DLL. One additional benefit is that dynamic will work with nested FoxPro types where Interop assembly imports will only give you top level properties and returned nested objects as 'object'.

+++ Rick ---

>>>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.