Some time back, I checked [u]P</u>roject|<my proj name> Prop[u]e</u>rties...|Component tab|Version Compatibility = [u]B</u>inary Compatibility

Some time later, I changed part of the interface. So now, every time I recompile, I get a warning dialog:

The get property for the 'Path' property in the 'clsElectricalSymbol' class module is missing from a similar declaration in the version compatible component.
Original definition:
Property Get Path As String

• [u]B</u>reak compatibility

I would like to stop getting this warning.

I tried setting compatibility to "No compatibility," recompiling, then setting compatibility back to "Binary compatibility," but when I recompiled after that I got the warning message again anyway. How can I eradicate the configuration that binary compatibilty compares against, and supplant it with the current interface?

Where is your binary compatible file?
After you compile with "No Compatibility" you must copy that file to the directory where the binary compatible file exists. That file is what the compiler is checking against for comaptibility.

One note: Binary compatibilty is not necessary when you are deploying to a small, controlled group. In other words, if you completely uninstall an application before installing the new application, there will never be any conflicts. There are benefits to using binary compatibility in certain situations. But in a corporate situation where the app is used only within a tightly controlled environment and where the dll isn't in general use by numerous applications, it can be more trouble than it is worth.

Woody Z http://www.learntoprogramnow.com

How can I find out where the IDE believes that file to be?

open the vbp file in notepad, and look for the CompatibleEXE32 string
if the file has non path, it is supposed to be in the application folder

It is on the Component tab of the project properties dialog - the same place where you set the Version Compatibility.

There is a textbox at the bottom with a file search dialog button, and the file location will be there.

Woody Z http://www.learntoprogramnow.com

woody, sometimes in that text box the name of the executable is shown without the full path qualifier. this is why I suggested to open the vbp in notepad (I don't always trust the IDE...)

Without the full qualifier, it is the same location as the project. As far as I have ever known, the path to the binary compatible file is relative to the project path (the location of the VBP file).

Woody Z http://www.learntoprogramnow.com

yes, most of the times...

in some occasions, the name of the component shown in the dialog box was shown without any qualifier, so I presumed it was using the project path, and wondering why it was not working. it was only opening the vpb prohect file that I realzed the file was not in the same path, but pointing to somewhere else
how it happened, it beats me. we are a team of developers and sometimes work on the same projects, and more than one time we saw very bad weird things happening in the IDE... sometimes it was our fault, sometimes it really did not have any explanation.

For example, there is one issue we know about: a very old project still uses the old VB5 controls, and almost always the images in the ImageList get lost in the IDE after running the project (for some reason the IDE does not like the old controls, and ends up corrupting the .frx files). We know that, so we 1) open the project 2) check out the file and modify the images 3) check in to make it write only 4) run. The reason why we are not changing the project is that it was rewritten in C#, but we still have to maintein our old customers...

this is why our job is soooo fun: we don't get bored

I suspect that the full path is shown if it is not the same as the running process's current path. This is certainly the way it is in the recently used file list of Word.

Of course, there are several ways to change this path that the OS keeps track of. In Word, you can specify whether opening a doc changes the current path or not. You can change it explicitly through the VBA behind Word (in as much as the commands executed there execute in Word's process space), and so on.

Perhaps the IDE changes the current path any time a file is saved. (We all love our applications deciding what it is that we must want without ever asking us, don't we?)

Anyway, just to be certain, I will read the vbp directly...

Either way, if you are pointing at an old version of the dll, then your new code will not be compatible with it if you have changed any interface of any class in the project, and includes class level settings such as the instancing property. So if wish to break compatibility by "re-starting" and throwing away the original dll, you just need re-compile using project or no compatibility, place the new dll into some appropriate location, and point the project to it.

I will say, I have numerous VERY LARGE projects that use Project Comptibility, and never use binary compatibility. The projects are re-compiled en mass prior to every release. This solves some problems in deployment, but of course, by using this methodology any deployment always requires a full re-install of everything. However - since our build, as well as our setup is completely automated it doesn't involve any more work for anyone. The main benefit is that there is never any problems due to traditional dll hell with component versions being out of sync.

Woody Z http://www.learntoprogramnow.com