Delphi – Why Delphi says “Unit xxx compiled with a different version of yyy” if all the paths are correct

1. You should explicitely compile packages - just compiling package files is not enough and as you have noticed leads to problems. In modern Delphi versions you can create a project group (not sure about Delphi 7) that contains an application and packages you want to develop with the application, and you can easily switch between them and complile packages without need to close/reopen the application.

2. BlgPackage should not have an access to MyControls package sources (through "Library" path or by using the same directory), it should access only already compiled MyControls package, else the files from MyControls are compiled every time you build BlgPackage and the compiled files are stored in BlgControls DCU directory

ADDED

The "Library" path should lead to compiled files (.dcp, .dcu) and (if needed) resource files (.res, .dfm) only - it is enough to compile applications and packages that requires "MyControls" package. You can set the directory for compiled files directly in the package settings, and you should copy the resource files (if you need them) to the same directory manually. This directory should be included into "Library" path, or else you can use a directory already contained in "Library" path.

The "Library" path should not lead to source files (.pas) if you don't want these files to be compiled every time you build your BlgPackage or an application that requires "MyControls" package.

Where you point your library path is not half as important as where you point the output paths for the compiled files, both dcu/dcp files and exe/bpl files.

Every project should have its own output paths. If you do that, then even when you point your library path to the source files, the binaries will be in a project specific folder and therefore can never interfere with other projects.

Be careful using the global (environment options) library path. Mine is actually entirely empty. Not even the standard Delphi folders like $(BDS)\Lib are in there. Why? Because it ensures that each project needs to make its dependencies on libraries explicit in the dproj. And that means that you can load and build projects needing different versions of the same library without getting errors because your environment paths is pointing to a different version of the library than the version your project needs. Which also helps greatly when debugging because the debugger will always use the version your project says it needs, instead of what the global environment path happens to be pointing to.

If any of your libaries have visual components, you still don't need them on the global environment paths. You only need to make sure that the IDE uses the bpl's from the version that you use most. It really doesn't matter whether that is an old one or not (apart from the fact that it may cause changes to the contents of dfm's, but source version control should help with that). You only need the bpl's in the IDE so that it won't barf at you when you load a form. In fact my IDE's usually don't have any third party components installed (even though the projects use them), but then I do not do much dfm work and when I need to change code in a form's pas file I just tell the IDE to ignore all errors (but keep the references! in the form's unit) and revert any changes to the dfm's upon submit.

Oh, and I always compile from source. That way if I get a patch for a single file in a library, I do not have to go through an entire install process, I don't even have to re-compile the components packages. I can simply put the updated source file in the proper folder and continue like nothing has happened.

Also, I do use relative paths in all of my projects. I know some people have suffered with that, but I have never encountered a problem. Possibly because I never open any files by double clicking in the Windows Explorer, but always from within the IDE or possibly by drag-n-drop from the Explorer to view a (previous version of) file without making it part of a project. Relative paths make it loads and loads easier to make copies of a project, have any number of workspaces (Perforce), and switching between them without having to "fix" the paths in the dpr.

All of the above are practices I have picked up working with many different projects, regularly having to change back and forth between versions of our own code, which often involves switching between library versions as well.