Using MIDL/VS2008 to generate REF DLL for binary compatibility, How to?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Anand Hariharan - 15 Apr 2008 23:11 GMT

At the outset, sorry for the cross-post; it is IMHO that this post is
relevant to both the groups I have posted it to. If you think
differently, please feel free to set follow-ups as appropriate. Thank
you.

We have a VB6 project that has become a kitchen sink. We are stuck
with it, because many other VB6 projects reference it. Basically we
are entrenched into VB6 to an extent that even while we invested
several man hours to move VC6 projects (elsewhere) to VS2008, we are
forced to continue sticking with VB6.

This kitchen sink becomes a problem when we hit the "zip code" error
(i.e., "Unexpected error (32810)"). The *ONLY* resolution when we
encounter this, we have noticed, is to recreate the reference DLL
using "No compatibility" (Project compatibility does NOT work). Of
course, the problem is that when we do this, we have to update the
Reference GUIDs of all the projects that depend on it.

We are looking for epiphanies on how to resolve this.

One thing that I have been pursuing for the last two days is to try
and create the reference DLL driven by an IDL file. I generated the
IDL file from the OLE Typelib viewer, methodically removed all the
importlib(tlb) statements to import "idl" statements, and finally got
a VS2008 solution that generates a DLL. The problem here is that VB6
complains

"A compatible ActiveX component must be a Visual Basic Executable".

whenever I use the DLL generated by VS2008 as the REF DLL for binary
compatibility.

I have tried monkeying with several VS2008 project settings (notably
MFC and ATL settings) but to no avail. Any insights / help
appreciated.

- Anand Hariharan

Reply to this Message

Ken Halter - 15 Apr 2008 23:41 GMT

> This kitchen sink becomes a problem when we hit the "zip code" error
> (i.e., "Unexpected error (32810)"). The *ONLY* resolution when we
> encounter this, we have noticed, is to recreate the reference DLL
> using "No compatibility" (Project compatibility does NOT work). Of
> course, the problem is that when we do this, we have to update the
> Reference GUIDs of all the projects that depend on it.

Are you trying to build an entire group of projects?

I've been dealing with projects that consist of *many* VB6 dlls here for the
last 13 years and that's the first I've seen of that error... It does show
all over google, though so it's not new and not dotNet related, so....

I personally don't build group projects. I build one at a time, in reverse
dependency order.

As far as interface compatibility goes, as long as the "REF DLL" (I call it
a model.... what ever <g>) contains *all* publics, you should be fine. The
first time you forget to update that model, you're hosed... so, I created an
add-in that monitors this stuff for me. There are utilities in that add-in
to inspect and compare typlib's between any 2 dlls (results shown in a
treeview), so it's been very handy and I definitely "eat my own dog food"...
but, here's a page (below) I put together that outlines the basics. At the
bottom, there's a link to that add-in, which is a fully functional demo,
so... it may help narrow down exactly what's changing between builds.
http://www.vbsight.com/BinaryComp.htm

Signature

Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

Reply to this Message

Anand Hariharan - 16 Apr 2008 00:13 GMT

On Apr 15, 5:41 pm, "Ken Halter"
<Ken_Halter@Use_Sparingly_Hotmail.com> wrote:

Thanks for your reply, Ken.

> > This kitchen sink becomes a problem when we hit the "zip code" error
> > (i.e., "Unexpected error (32810)"). The *ONLY* resolution when we
[quoted text clipped - 4 lines]
>
> Are you trying to build an entire group of projects?

Just one VB6 project that depends upon several other DLLs. These
DLLs, in turn are generated by other VB6 projects or C++ solutions.
The hierarchy runs several levels deep.

> I've been dealing with projects that consist of *many* VB6 dlls here for the
> last 13 years and that's the first I've seen of that error... It does show
> all over google, though so it's not new and not dotNet related, so....

Definitely not .Net related, and no, not new at all. It's one of the
many times when it starts to feel like the last straw on the camel's
back. Am sure, we will land up breaking compatibility and going down
the old road of updating the reference GUIDs in the projects that
depend upon this project.

> I personally don't build group projects. I build one at a time, in reverse
> dependency order.

That is what we do here, at least in principle. This is a *HUGE*
product though (several hundred man years, no exaggeration).

> As far as interface compatibility goes, as long as the "REF DLL" (I call it
> a model.... what ever <g>) contains *all* publics, you should be fine. The
> first time you forget to update that model, you're hosed...

Sadly enough, am aware by sheer experience. In this case, it is not a
question of forgetting to update the model of this VB6 project, but
rather one or more DLLs that we depend upon messed us up.

> so, I created an
> add-in that monitors this stuff for me. There are utilities in that add-in
[quoted text clipped - 4 lines]
> so... it may help narrow down exactly what's changing between
> builds.http://www.vbsight.com/BinaryComp.htm

Am not sure I can convince my management w.r.t licensing terms that
you may have. Am afraid I am not even in a position to download and
see what your add-in has to offer.

Would appreciate any help.
- Anand

Reply to this Message

Anand Hariharan - 15 Apr 2008 23:44 GMT

On Apr 15, 5:11 pm, Anand Hariharan <mailto.anand.hariha...@gmail.com>
wrote:
(...)

> We have a VB6 project that has become a kitchen sink. We are stuck
> with it, because many other VB6 projects reference it. Basically we
[quoted text clipped - 22 lines]
> whenever I use the DLL generated by VS2008 as the REF DLL for binary
> compatibility.

Reply to this Message

Ken Halter - 16 Apr 2008 00:07 GMT

> So, I suppose my question should be rephrased as "How do I setup
> project settings in VS2008 for an (essentially) IDL only project, so
> that it generates a DLL that has only dependency viz., MSVBM60.DLL?".

Not sure about VS2008 stuff. This and all other groups on the MS server that
start with "microsoft.public.vb" are for pre-dotNet versions of VB.... all
dotNet groups contain the word "dotnet" or "vsnet" in their names

Signature

Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

Reply to this Message

Ralph - 16 Apr 2008 01:39 GMT

On Apr 15, 5:11 pm, Anand Hariharan <mailto.anand.hariha...@gmail.com>
wrote:
(...)

One quick follow up observation:

Per 'Depends.exe', the DLL generated by VB6 has only one dependent DLL
(even if the VB project includes many many references) viz.,
MSVBM60.DLL. However, the DLL generated by the VS2008 project lists a
few system DLLs such as Kernel32.dll, oleaut32.dll, user32.dll, etc.

So, I suppose my question should be rephrased as "How do I setup
project settings in VS2008 for an (essentially) IDL only project, so
that it generates a DLL that has only dependency viz., MSVBM60.DLL?".

Of course, if I am barking up the wrong tree, then I would appreciate
if someone could enlighten me on how to fix this "fragile" VB6 project
so that it does not throw "Unexpected error (32810)" upon the
slightest of provocation.

thank you,
- Anand Hariharan

======================================

I was kind of with you for awhile there and Ken's advice was good, but now
I'm lost again. <g>

Back to basics (pun intended) - Is this correct ...
1) You have a VB project that produces a single ActiveX Exec or ActiveX Dll
(which is it?) that other VB6 projects reference. Call it "Alice", the other
project "Bob".
2) You when you change Bob, all of sudden Alice produces Err:32810.
3) You can fix Bob if you break Alice's binary compatibility, recompile, and
then rereference all the little Bobs to now point to the new Alice.
4) This is annoying and you want to keep the release of Alice binary
compatible with all the Bobs.
5) VS2008 is only in the picture because you want to use its IDL editor to
create a typelib so everyone can compile with it and maintain binary
compatibility with Alice. ie. Somehow circumventing whatever troublesome
'feature' Alice has that is causing problems.

I hate to be the bearer of bad news, but I doubt if having something
'in-between', so to speak, (Item #5), is going to help anything unless you
are lucky, and it turns out to be one issue that can be fixed that way. You
have to find out the specific places that are causing Alice to be so
annoying and fix them separately. As Ken noted - the possibilities are
large, as any number of issues may be at fault. Having a middle man will
only fix a few of them, but more often will only mask the problem until the
next time.

So do you feel lucky? <g>

Such issues were relatively common back when we were mixing VS5 and VS6 code
or passing around different 'system' structs and such, but generally
disappeared as everything settled down to one WinAPI and VB SPs. So maybe
poor Alice just needs a make-over.

My suggestion: pick your two best VB and COM people and lock them in a room
with Alice and Bad Bobs, and don't let them out, or bother them until they
isolate the exact trouble spots. Then do whatever hack is appropriate for
each issue, and don't be surprised if the 'fixes' are as varied as the
problems. Possibly requiring changes to Alice and Bobs.

Expensive, but you can either pay the price in one hit or dribble twice as
much money away (like you have been doing) over the long term. <bg>

-ralph

Reply to this Message

VB Forum / COM / April 2008

Using MIDL/VS2008 to generate REF DLL for binary compatibility, How to?