package madExcept_.bpl/madBasic_.bpl/etc cannot be found
package madExcept_.bpl/madBasic_.bpl/etc cannot be found
this is D2010. not sure if it applies to other versions. and it's not a bugreport (not for madCollection, at least)
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
Thanks.
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
Thanks.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
This usually occurs if you have installed your own packages, and the update to a newer madCollection version. In that case your own packages are being loaded first, and since the mad* packages are not loaded yet, Delphi complains. What I'm usually doing in this situation is 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.
(5) Done.
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.
(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.
(5) Done.
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.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
ah, now I understand where my issue is coming from. I wrote an automatic build ... "script" (more like a library) and one of the things this does is that it "registers" the known packages. Unfortunately for me, this was placing madexcept as the last thing to load. This script is pretty old but it worked fine when I wrote it because none of the packages actually depended on madexcept. Time for a rewrite
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.
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.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
It just happened again and completely forgot about this issue. Good thing with google
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.
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.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
Sounds like a good "trick"...
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
I am having the problem with Delphi 10.4.1
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.
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.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
Yep, "Component -> Install Packages" is what I mean.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
I have not found a solution for loading the bpl. But, I have found work around.
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.
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.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
Oh, then your problem was quite different, actually. This thread is about the Delphi IDE starting up with a complaint. Your problem seems to be with your own EXE starting up with a complaint.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
I did not see that the origin problem was related to the IDE. That is why the suggestions did not do anything for my problem.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
Yep. A possible solution for loading the bpl is to either add a PATH to the folders where those bpls are stored, or to copy them into the same folder as your EXE file.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
I have copied the bpl files to my program's EXE folder and a folder in the system path.
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.
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.
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
Which BPLs exactly did you copy?
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
The ones the program complains about. madBasic_.bpl, madDisAsm_.bpi, and madExcept_.bpl
Re: package madExcept_.bpl/madBasic_.bpl/etc cannot be found
I assume that's a typo and you meant "madDisAsm_.bpl" instead of "madDisAsm_.bpi", right? I'm asking because madDisAsm_.bpi also exists.