Binary Compatibility! 1

[petecass]

I have used three dll's in my applications for years. I currently have two working appllications that use the same three dll's, using only project compatibility.
If I changed any of the dll's I would just recompile both applications and send out.
This has been ok so far as the two applications were never on the same system.
Now I have a third application out and one of my clients needs all three appliactions on the same system. But reading about binary compatibility makes my head hurt.

Can someone confirm the following:

If I change all three dll's to binary compatibility and copy the current dll into a folder under the dll project, recompile with binary compatibilty.
Then recompile all three applications.

What do I do on the target system?

It currently references the dll's in it's own directory. do i need to unregister the dll's and then copy the dll's into the system directory.
(p.s. changing the other applications to install the dll's into the system directory on setup)
and then re-register the dll's now residing in the system directory?

Then just install the other two appliactions?

 

[Sheco]

They don't need to be in the system directory.

They only need to be in the place where the registry expects them to be.

 

[ArtieChoke]

You will probably need to unregister the old ones and register the new ones, as the class ID will most likely change. The only difference is the compatibility mode. Whatever you did before in terms of setup still works.

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[petecass]

I have now recompiled all dll's with binary compatibility.
Running on the development system. No problems.
Then I made a change on one of the dll's (not braking compatibility or changing the interface in any way) and after compiling this dll (but not the application) and then run the application I get automation error 430. WHY?

 

[ArtieChoke]

You need to make sure it's still compatible with the previous version. When you select the binary compatibility option, there is a textbox that allows you to list the dll file that it should be compatible with. You need to make a copy of the original dll file (it can't be done on the same file you are creating) and store that file in a sub-folder of your project. Then select it for compatibility (asumming you didn't already do this).

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[petecass]

Yeah. Did that. After doing major changes on dll's compiled as project compatibility. copied those into a sub-directory called binary. recompiled all with binary compatibility. Then made a change on one dll to test (this was within a sub no interface change) then recompiled this dll. Expecting the application to run without having to compile!
I am right in my assumption that with all dll's compiled with binary compatability and then compiled applications.
That if I then made a slight change (no interface changes) then I should not have to recompile any application. Yes?

 

[Sheco]

The old dll that works with the old application, it is the ones that needs to be in the textbox.

You compile it so that your new changes are binary compatible with the old dll.

 

[petecass]

There seems to be a slight misunderstanding here. Let me recap.

1) Dll's currently using only project compatibilty.
2) Therefore made a copy of these current dll's to a subfolder called binary.
3) Recomplied all dll's using binary compatibilty.
4) Recompiled applications.

Ran applications. No problem.

5) Made a slight change to a dll. Recompiled not breaking compatibility.
6) Overwrote previous dll with new version.
7) Ran application. Got Automation error 430.

i.e. Only by recompiling the application could I get it to work. Which is no different from project compatibilty.
Q. Should I have to recompile an application if a slight change to a dll does not break the dll's compatibililty with previous version?

 

[ArtieChoke]

A. No, you shouldn't. But the problem is you are creating the binary compatibility the second time around to the project compatible files. You need to move the 1st set of recompiled dlls that you set to binary compatibility to the binary dir.

Let's see if I can explain it (assuming I can remember what's going on - doh! ).

When you create a dll file, it gets a unique class id. What you are doing with binary compatibility is retaining that id. Even though you set the new dll to be compatible with the project level compatible dll, it creates a new class id that points back to the original dll. When you recompile based on the original dll, it creates a new class id within the current dll and retains the old dll ids also. Maybe this will help:

1st time thru:
org dll id new dll id
11111 22222

2nd time thru:
org dll id new dll id
11111 33333

Now, your current application was compiled with class id 22222, and you've put out a file with the same name, but class id of 33333. There is no 22222 to link up with (it uses the id, not the dll file name), so error 430.

So if the dll file is truely compatible, it should keep the same class id (or at least reference the previous ones). So if you have compatibility to the one with id of 22222 and the new one has id 33333, it will still work.

Give it a whirl and let us know how it turns out.



"I think we're all Bozos on this bus!" - Firesign Theatre

 

[petecass]

See your point!

Oncce started with binary compatability it will keep id's, whereas i went straight from project to binary.

Cheers