Here is a strange issue I've run into. I have a DLL that is reaching 1.5 MB in size. It is written in VB 6.0. Up until now it is Binary compatible. However, when trying to compile or even just open DLL, at the point where VB 6.0 checks the compatibility DLL we get an error: Error loading a DLL. When we cleaned it up a little so that it scailed back to 1.3 MB the issue stopped. Now the DLL has grown to 1.5 MB again and the issue has begun occurring again. If we set the DLL to no compatibility, everything is fine. Can anyone shed some light as to what size barrier we might be running up against?

Hello Yehuda,

yes, I saw that problem with an ocx of mine that is now at 1.3MB of size, an enumeration type was causing the compilation to fail. I fixed the problem (as you did) cleaning up the project.

VB has a lot of limitations (see the chapter "Visual Basic Specifications, Limitations, and File Formats" in the msdn vb6 documentation) but unfortunatelly it is not easy to point out what which one is involved in the specific case. Size matter (sorry I coudn't resist the joke :) but only because of the projects internals. Probably is a combination of more than one, because otherwise the compiler is able to give a more specific error.

 Sorry, but I cannot give you more input than this... what I end up doing is 'ok, this project is done', create a new project and have the old and new working in tandem. Which is always a good idea anyway, in the COM world (well, it applies in .net too)

Marco

Marco,

The strange thing is that it has no effect on the DLL itself. It is only an issue if we try to make the DLL Binary Compatible. We are considering our options. At the minute we broke compatibility to clean the DLL, so compiling it with no compatibility is not a problem. However, in the future we would like to maintain compatibility on this DLL and we would like to know what we are dealing with so we don't run into the issue again.

Yehuda

Yehuda,

did you take a look at your dll's typelib (before breaking compatibility) using OleView?

This is how I found my problem, I saw that the declaration of one of enumeration types was wrong. To fix the problem, I got from SourceSafe the latest version that was still correct. From that point, I never had that problem again.
It is really very easy to corrupt a binary when building inside the IDE (well, maybe not that easy but possible.) A corrupted dll can still work, but cannot be used for setting compatibility. Before making any component I always exit VB and build with a fresh new one (golden rule)

Marco

I have several old dlls from before the compatibility break. Some we can view and some we can't. How can I detect any issues that might be causing our problems?

Thanks,
Yehuda

Does that mean that OleView fails to open the file?
Marco

I had a similar problem. It was because I had 2 differente version register, even if I only had one copy of the DLL.
To correct the problem:

1- Unregister your DLL
2- In your registry, remove all entery of your DLL in the branch HKEY_CLASSES_ROOT\CLSID
3- Recompile your DLL with out Compatibility.

This should correct all of your future problem.

Also, to prevent this from appenning again, try to folow these advise:
1- To compile, only use a dedicated computer, no programming on that computer
2- Once in a will, check the branch HKEY_CLASSES_ROOT\CLSID to make sure that your DLL is only register once.

Stéphane

Oleview opens but when I try to open the typelib I get a message that it cannot open the file.

Stéphane,

We originally thought it might be this issue. However, we tried that on several machines with no success.

To All:

The newest development in this strange case is last night one of our programmers tried to compile with compatibility last night so we could do further research on the issue and it worked without any issues!!! We are now monitoring the situation and we will keep you posted as things happen.

Thanks for all your help so far.
Yehuda

OleView failing to open the typelib is a very bad sign... that also explains why you cannot compile with binary compatibility. Probably the programmer that was able to recompile had an earlier 'good' version of the dll registered in his/her computer.

Although Stephane's idea is good, it is not always practical. Say I change the interface (without breaking compatibility). In this case I need to recompile the dll on my computer to get a new release version and check it in, unless I check in the code and wait until the next 'official' compilation in the 'official' computer, that sometimes is not practical when many developers are waiting for each other to finish... But this is where the problem raises. If I recompile in the IDE after having used it for hours doing frequent debugging, edit and continue and/or worse hitting the stop button while debugging, I am making a dll with a IDE that is in a really bad state. This is why, in my previuos post, I suggested to recompile or with a fresh new IDE or, even better, by a dos shell. Even better following Stephane suggestion, if possible. And, nonetheless, dll's hell is always behind the door :)
Keep up posted,
Marco