Adding References

[PeterK82]

We are experiencing some problems with our VB6 project; we can't add any more references to DLL's. Currently we have 145 DLL's referenced; visual basic turns 'round and says 'name conflicts with existing module, project or object library'. I tried to get around it by creating a new project adding the new references to it, saving that project, opening that project in notepad and copying the references into the existing project file. I then opened up the existing project with the extra references and VB said 'cannot create reference' and removed the last 7 DLL's referenced. We don't know what to do, it doesn't sound like VB has a maximum limit for references, because that would be stupid. I sounds like a bug where you cannot add anymore references, I've searched Microsoft's web site and found nothing. If someone can shed some light on this topic it would be most appreciated, if all else fails we'll have to change some DLL's to late-binding.

Please respond ASAP.

Cheers.

[jim mcnamara]

There isn't a limit, except in the practical, rational sense. You are overdoing it a bit- your code will be the size of Kansas.

Here's what's happening:
Let's say you have a reference to Forms Library 1.1, and you use it. You have controls that require it. You can't remove it. But, later on you need a SuperX control, which only lives in Forms Library 2.0. You can't add 2.0.

The reason is that you will have mapped two copies of the same COM interface and CLSID into the project. All of the controls from 1.1 are also contained in 2.0, along with the same interfaces.

I'm sure you don't have THIS problem (1.1 and 2.0), but there are COM libraries that reference the same stuff, like different versions of DAO (3.5 & 3.6) for instance.

MSDN will tell you what interfaces and classes each COM library (from Microsoft) exposes. You can also use OLEVIEW.EXE to inquire on your development machine.

[Kronix]

...I'm dying to know what project needs 145 DLLs.

[PeterK82]

It's a business application that stores person’s details and products owned. That's what VB is really for, business apps, the only reason why we have 145 dlls is because we also reference the data layer in the main .exe as well as the business layer. We create both object and pass the database connection thru the business layer to the data layer. To solve the problem we have unreferenced all of our data layer components and made them late bound. You can't tell the difference in performance, which is a good thing, and now we've got more references to use. This program is not even finished, the operators in call centres are using it, but it will also become a marketing tool. This will probably add another 20-30 dlls. The main .exe (client layer) is about 13MB, I think there is about 300,000 lines of code in the .exe. I don't even want to think how many lines altogether including dlls.

[Kronix]

...Gee, and I thought my little app with 2 DLLs was pretty spiffy.

[PeterK82]

In the business world it's pretty hectic, I should know, I've been writing business apps since I was 16. I'm 20 now, so that's 4 years of complexity.

[Arc]

The "'name conflicts with existing module, project or object library'" error is probably where you have 2 DLL's that have a method or something in there that are named the same. I imagine with 145 DLL's that it wouldnt be hard to find 2 that have the same method name.