Now here comes the fun part. If you open the DLL project, modify the code without removing or modifying the DLL's methods, and recompile the DLL, the executable program will still run and will use the DLL's new code.
For example, if you change the * to + in the DoCalculation function, the main program will still run. If you enter the numbers 4 and 5, the original version of the DLL returns 4 * 5 = 20. The new version returns 4 + 5 = 9. The main program will display the new result without knowing how the value is calculated.
Note that you must not change the DLL's public interface. You cannot remove or modify the declarations of any public functions, subroutines, variables, properties, etc. You can add new public properties, functions, and methods without breaking backwards compatibility. Later you will not be able to remove them, however.
If you break compatibility, you'll get an error when the main program tries to use the DLL's methods. If you try to remove a method from the DLL and then recompile it, Visual Basic will warn you that you are breaking compatibility. You'll need to remove compatibility, rebuild the DLL, then open the main program, set a reference to the new DLL, and recompile it.
Dominic Olivastro uncovered this update:
For the record this is what MS says about the problem in Q166470.
Resolution
To work around this problem, copy the ActiveX executable or DLL to a
separate directory. Set binary compatibility to the copied file, and
compile to the original directory. This procedure is described in
Microsoft Visual Basic Books Online.
Status
Microsoft is researching this problem and will post new information here
in the Microsoft Knowledge Base as it becomes available.
More Information
While this behavior is not always encountered when compiling, you should
follow the procedures in the RESOLUTION section above in all projects
where you set binary compatibility.
|