Re: Component Compatibility.....

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"John Morley" <jmorley@xxxxxxxxxxxxxxxxxxxxxx> wrote in message news:u6jQhmIgIHA.4164@xxxxxxxxxxxxxxxxxxxxxxx
Hi All,

I have a program that is comprised of four "components" (2 DLLs and EXE's). Occasionally, changes are made that break the compatibility between the components. At that point, it seems to take an act of god, and the efforts of one part-time guy to square things away. The part-timer wants to imply that this is all some sort of "black magic" or some such (job security?), but I can't believe its that difficult. Can someone run through the steps that must be taken to restore compatibility amongst the various components of a multi-component project? Looking at the various project files, I can see that he's got 'Reference' directories in each project folder, and the component compatibility seems to be set to 'Binary Compatibility'.

From watching him before, it seems like he went through a process something like this:

1. Start at the lowest level component project, and compile with 'No Compatibility'. Copy the compiled result to the 'Reference' directory.
2. Recompile with 'Binary Compatibility' using the file in the 'Reference' directory as a reference.
3. Move to the next higher component level project, and repeat.

Of course, all dependencies are referenced prior to running each component of the project.

I must be missing something because this isn't working.....

Ideas, suggestion, education are all welcome!

Thanks,

John

I'm pretty sure the recommendation in the VB6 docs are that breaking compatability should be a conscious design decision. Further, when you do so, you should rename the project, possibly with a version number appended.

This means your Fred10 library becomes Fred11 and gets all new ClassIds and ProgIds (Fred10.InfoClass becomes Fred11.InfoClass, etc.). When you have a hierarchy of libraries and programs it all flows uphill of course. We see the same thing with Microsoft's MSXMLxx libraries. Updating client source can be as easy as replacing the library's reference and then at worst doing a global replace to catch fully-qualified types and CreateObject() calls. I still do a "diff" compare afterward myself, sometimes a replace can zap something unintended.

This lets you take control of versioning explicitly and at the same time avoids the need for version-dependent ProgIds (which VB's DLLSelfRegister logic and thus regsvr32.exe can't handle anyway). Of course you *could* go that route instead in theory by taking more control of component registration.

In addition you gain the ability to have multiple COM-versions of a library installed at once w/o SxS, etc. fiddling. When you support VB programs you often find that not everyone having troubles is running the latest and greatest. This way you can test without needing a raft of VMs or repeatedly installing and uninstalling various versions.

Don't try to version these programs and libraries as a group though. Each one needs to run on its own version cycle. Not every library will break compatability at the same time, and I tend to re-use a lot of libraries for multiple applications myself.

.

Relevant Pages

  • RE: Maintaining Maximum Platform Compatibility
    ... So with thoes references there should be any compatibility problems? ... The missing reference error will show up when the code is ... In this case Late Binding is really the only good option. ... Just compile the code with the libraries you need and voila, ...
    (microsoft.public.excel.programming)
  • RE: Maintaining Maximum Platform Compatibility
    ... So unless the reference problem returns ... So with thoes references there should be any compatibility problems? ... In this case Late Binding is really the only good option. ... Just compile the code with the libraries you need and voila, ...
    (microsoft.public.excel.programming)
  • Re: Library Database
    ... That's if you're doing it the way the Help file documents, ... You have to close the database to get rid of the reference. ... I've never had references to these libraries. ... There is a section entitled "Library Database ...
    (comp.databases.ms-access)
  • Re: Access 2003-Access 2002 Incompatibility
    ... Microsoft ActiveX Data Objects Recordset 2.7 Library ... The first one corresponds to msado15.dll (and adds the ADODB reference), ... There are two ADO type libraries. ...
    (microsoft.public.access.conversion)
  • RE: Built in function errors.
    ... Control reference, ... updating the software on the client computer and reselecting all ... reselect libraries simply makes the application not worth building using ...
    (microsoft.public.access.modulesdaovba)