File or assembly name EzyConfig, or one of its dependencies, was not f

[ddoody]

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 directory as the troubled component. This is possibly not the case though, given the message.

Also, as near as I can tell the vb.net component is correctly set up for COM interop (it was upgraded from an old vb6 component). I have no issues compiling the vb6 component against the COM reference exposed by the .net dll and those references are stable across multiple builds.

It may or may not be relevent, but the vb6 dll is an automation add-in to MS Excel. The .net component does not reference Excel or Office.

I am fluent in vb6 but new to .net. Any help to track down the source of this error would be much appreciated.

 

[Qik3Coder]

Couple questions,
When you look under the "References" tab, the EzyConfig dll is there?

As well, could you post the block of code you are experiencing issues with? A code sample helps immensely.

-Sometimes the answer to your question is the hack that works

 

[ddoody]

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 Domains
    g_Groups = New Groups
    g_Streams = New Streams
    g_Menus = New Menus
    g_License = New License
End Sub

These various globals objects are essentially collection classes where the contained items are loaded from XML data held in resources. Nothing very taxing. The XML is loaded using the MSXML2 (v4) COM object due to the application having been upgraded from a vb6 project. I have not yet had the time to convert over to native .NET XML objects.

The reference for "Microsoft XML, v4.0" is flagged with "Copy Local" = True, as is another reference (SharpZipLib). All other references used by the .NET component are standard .NET 2.0 run-time objects.

I hope this is enough info as I'd really like to get to the bottom of this.

Thanks for your reply.

 

[Qik3Coder]

Does your EzyConfig object use any 2.0 objects or the like that are in 2.0 and not generic enough to be in 6.0 code?

I know you can have data mismatch issues between C# and VB.Net, so it wouldn't suprize me if you have something like an Int64 that VB 6.0 just freaks about.

-Sometimes the answer to your question is the hack that works

 

[ddoody]

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.

 

[Qik3Coder]

So, tell me why,

If you have a 6.0 version of the dll and the things that changed were for the .Net upgrade then why you aren't using the 6.0 dll for 6.0 code?

it seems like you are making this more difficult than you have to.

.net 1.1 dlls may be able to use 2.0 dlls, because they are part of the framework, but I don't think you can go that far back.


-Sometimes the answer to your question is the hack that works

 

[ddoody]

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 to compile successfully. Our problems there were to do with the 3rd party components that EzyConfig was using (replaced now by standard .NET code).

So, basically we have to combine vb6 and .NET (or rewrite the entire app in .NET, which is a HUGE undertaking)

 

[Qik3Coder]

You may want to try a quick and dirty calculator .net dll example, and access it in 6.0, to make sure it's not something in the other dlls that is causing your headache.

If not, I did some quick searching and you may need to use COM instead of the dll.

http://msdn2.microsoft.com/en-us/library/x66s8zcd(vs.71).aspx

-Sometimes the answer to your question is the hack that works

 

[ddoody]

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.

 

[Qik3Coder]

So, soory, i am trying to follow this without re-reading it every time.

This dll works with other VB6 projects, just not this one?

-Sometimes the answer to your question is the hack that works

 

[ddoody]

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 are instantiated by the main program and then passed by reference to other components as needed. The other components use these objects but do not create new ones of their own. It is, essentially, a huge global variable.

 

[Qik3Coder]

Yeah, you might want to go back to ground and try getting a basic example working before you keep banging your head against this one.


-Sometimes the answer to your question is the hack that works

 

[ddoody]

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 project is registered and can be seen in the vb6 references dialog. In this dialog it is selected and is not 'missing'. The vb6 component compiles correctly against this reference.

The .NET .dll file is in the same directory as the .tlb and this is the same directory as all of the vb6 components...

Yet, I still get the same error.

This is very confusing. (-:

 

[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 2008 installed at various times (along with many other applications). Perhaps one of those has cause some problem.

 

[Qik3Coder]

working across 4 generations of a product will give you strange behaviors.

If you wind up formatting you box, make sure you start with vb 6 then .Net 1.1, then 2.0 then 3.5 if you try to install the development environments out of order, you will get bixarre behavior, and usually you can't finish the install.

-Sometimes the answer to your question is the hack that works