Circumventing vb6 binary compatibility [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

This is more or less an academia question to help me better understand this process... not so much a request to figure out how to get around binary compatibility so no need to explain why I shouldn't try this :)

Let's say I create and compile a dll in vb6 that has no public members. Actually, I think it might not allow you to compile without at least one, so let's say we create a single public method, but it's only there so that the dll will compile and we otherwise ignore it.

Now say I set the project compatibility to this dll, and I never, ever under any circumstances update this dll or change the compatibility to an updated version of the dll.

In this scenario, I am thinking that vb6 would never throw those breaking compatibility error messages, and would continue to use the same UUID for the dll on each compile even when you do actually break compatibility.

However, I am thinking that the values generated for the classes you create in that dll would change each time. And even though you wouldn't have compatibility issues for compiling that dll, you would still eventually run into compatibility issues for projects that reference this dll.

Does that sound about right?

Answer 1

I think your logic is right. Although you might as well just use project compatibility?

I don't know why you would ever want to do this, but you do say it is an academic question!