Jon H

Jon H

  • NA
  • 18
  • 0

Legacy VB6 app replacement.

May 12 2011 4:58 AM
Hi Guys,

We have an application that depends on a 3rd party. This dependency is managed via a vb6 'wrapper' dll for the third party using COM. What we need to be able to do is replace the 3rd part dll with our new one and not have to recompile the wrapper, or change any references.

I have written in C# .NET most of the necessary that emulates the interface/s that the 3rd party app exposes, and when I open the wrapper app in code and change the reference to point to my app rather than the original 3rd party it all works well. NO other code changes are made or required - just the reference change.
I need to take this a step further. I need to be able to load our original VB6 wrapper app and have to 'use' the new C# .NET dll which is exposing everything(almost everything) the original did. I have used ProgId, Guid and namespace so that when the registered dll is viewing in say RegDllBView they appear identical (with the exception of the threading being different).
When I open the legacy vs the new in dllexp the exposed functions are identical with the exception the new one does not expose( DllUnregisterServer,DllRegisterServer,DllGetClassObject,DllCanUnloadNow) but I have read that com interop takes care of those?

Problem is when i register the original wrapper with my new 3rd party I get 'Runtime error '430' Class does not support automation or does not support expected interface'

I have tried everything! I have even nicked the idl for the dll I am trying to replicate and used it whole sale for what I am replacing with. I just keep getting the same automation error. I am alittle worried that dllexport of the old and new differ by the dll register etc calls. Are these defiantly generated?
Any help gratefully received!


Answers (2)