short problem: mad* packages required by other installed packages will result in those packages cannot be found error on IDE startup.
As I've been able to dig into it, I saw that the design time packages are loaded "first" (as in before other needed stuff, whatever that is, probably environment options; and during add-on loading) and from using sysinternals process monitor I noticed that there are only 2 sets of path that are being searched for, for required packages (maybe the first set is composed of multiple sets, I have no idea, just guessing, but it's a short set):
- some internal "delphi" paths (which include the %BDSCOMMON%\BPL and %WINDIR% and %SYSTEM32% and alike (I've done this research a few weeks ago and I'm quoting from memory so don't be surprised if I get some of these paths wrong)
- the actual %PATH% system variable
now, for someone who knows the internals of the delphi IDE and what dirs it uses and so on, this probably is not a complete and fully correct information, but it's what I noticed and deduced.
The thing is that the IDE library path is NOT used. Thus, mad* packages are not found (actually, any 3rd party package that is required by a design time package installed and enabled in the IDE which stores its BPLs in some other location; which makes this post not a bugreport against madCollection)
now, the key issue here is that I've set up my packages in a way that they require mad* packages (no way around this, unfortunately). And I *think* I've done this a little while back, in D2009 (which I used last year). I know the packages were setup up like this during D2009 dev, and the mad* dependency was added a bit later, but I don't remember if that later was during D2009 or after I switched to D2010 (and I don't have the time resources to setup a vm with d2009 and test if it works there or not).
what I am interested in, and asking you since I figure you know better, is where are these paths (used during package loading) read from? Is this some "raw" environment which later gets updated with EnvOptions.proj? If so, where is it read from? I have a "hack" batch file that loads my project group into the IDE, setting %PATH% prior to that to include tha mad* packages, but that's just a hack. I'd like to get a real solution to this
(1) Close all Delphi projects.
(2) Go into the list of loaded packages.
(3) Check the required mad* packages.
(4) After that check your own packages.
Doing this will restore the correct loading order. Unfortunately you'll have to do that once every time you install a new madCollection version.
Not sure about how to handle this better. I'm trying to avoid storing my packages into the system32 folder, I think that would be an awful solution.
you're right, placing in system32 is a bad idea however you might want to try fiddling with the [HKEY_CURRENT_USER\Software\CodeGear\BDS\$(DBS_VER).0\Known Packages] registry key and just placing the madexcept entries as first below the delphi packages (I know, for non-bds it's another key and you'll probably have to write delphi version dependent code but that's just the ugly part of things).
Another idea is to have the installer "save" the original place and insert the entries in the same position. That way upgrades won't break things.
So my quick solution, given that this now happened with another project, was to close delphi, export the Known Packages key to a file, delete all the keys in it (except default), open the export file and move the madcollection packages rig after the delphi ones, and before "my" packages, then import the file.
I cannot find your "(2) Go into the list of loaded packages." Where is it located in the IDE? What I can find is Component | Install Packages, which lists packages in alphabetical order.
As for the registry Known Packages, the order of keys in the exported file is different from what I see in Regedit. So I am hesitant to make any changes.
In Project Options, Runtime Packages, remove madBasic_, madDisAsm_, and madExcept_ from the Runtime packages list. This causes the compiler/linker to include the components in these packages in the exe, so the bpl does not need to be loaded.
I edited the "All configurations" Runtime package list.
The Runtime package list is long and has no apparent order, so you have to search for the mad* packages.
This only affects the current project.
I still get the error "The code execution cannot proceed because madDisAsm_.bpl was not found. Reinstalling the program may fix this problem." with "Link with runtime packages" selected and MadDisAm_ in the Runtime package list.