I have a C# WCF application that references another .NET DLL that is actually a COM+ application.
If I build my C# WCF application, the COM+ DLL naturally gets placed in the output folder.
The contents of this output folder is then used for building the deployment package (MSI).
After the application is installed on the target system, when the WCF application is executed for the first time, and it "uses" the COM+ DLL, the COM+ DLL automatically generates a .tlb file with the same file name. This .tlb file also registers itself and adds entries to the Registry!
This is where problems start to happen. If I uninstall the application, the .tlb file remains because it wasn't installed originally. This results in two potential problems in the future:
- If the .tlb file is manually deleted and the application is then reinstalled, the .tlb file doesn't get automatically generated like it did the first time - probably because Registry entries already exist for it. This results in errors at run-time when the COM+ DLL is used.
- If the .tlb file is left as it is and the COM+ DLL interface has changed between the uninstallation and the reinstallation, the .tlb file is not overwritten with a newly-regenerated updated version. This results in type cast errors at run-time.
I am considering taking the .tlb file that is generated by the COM+ application at compile time and adding that to my WCF project as a resource that is copied to the output folder and picked up by the MSI deployment package so that the correct one is always distributed, installed and uninstalled, without it having to be automatically generated and self-registering.
However, this doesn't feel right.
Could anyone provide an insight into what is happening here and how I could resolve it elegantly and properly? Would it be more elegant perhaps to get the MSI to unregister the .tlb file on uninstallation even though it doesn't get installed?
Thanks, Jason