Recent content by ddoody

Further to the previous post... I have tried a test vb6 app and .net dll. It still fails on my PC with the same error. HOWEVER, the test app (and cut-down main app) both work on a different PC! It now seems there is something strange about my development machine. It has had VS2003 and VB...

OK. Have tried your suggestion. I commented out enough code in the .NET component such that it now compiles with NO references required. In my mind, this means it needs no external components other than the .NET run-time files which should be in the GAC. The .tlb file generated by this...

No problem. The dll does not work with other projects. Actually, what I should say is, it has not been tried with other programs as it is its primary program that I am attempting to get working. This component contains the applications configuration (which is substantial). Its major objects...

Sorry. I thought I'd made that clear. EzyConfig.dll IS enabled for COM-interop, as it is still also used by the other vb6 components.

Ah. There's the rub. EzyConfig.dll is a shared component. We have a new component, that MUST be written in .NET, that has to share the EzyConfig objects with the vb6 component. Our original plan was to have the new .NET component use the vb6 version of EzyConfig but we couldn't even get that...

The datatypes should be fine. EzyConfig.dll was a vb6 project that was upgraded to .net via the upgrade wizard. The only changes made post-upgrade were to fix the inevitable upgrade issues. I will double-check though just to make sure.

Hi Qik3Coder, Yes, the EzyConfig.dll is present (and selected) in the references for the vb6 project. As for the code, it is simply: Set g_Config = New EzyConfig.Config and the constructor for the Config class of EzyConfig contains: Public Sub New() MyBase.New() g_Domains = New...

Hi all, I have a vb6 dll that is attempting to call a vb.net (2005) dll via COM interop. The moment the vb6 component attempts to instantiate an object from the .NET dll, the above error occurs. As near as I can tell, all of the non-framework components the .net dll uses live in the same...