Borland Delphi 10 Lite 3.0.rarl
Sandrine Willert
Marjan, the main issue is the Design time packages, which then in turn reference runtime packages. If those are not on the system path, delphi cannot load them. It's a limitation of the windows loader, not delphi. Anyway, we're straying way off topic here, the main issue is delphi messes with the path in a bad way, with bad side effects.
Strange. I got an email with your response to my comment, but I don't see it here. Anyway...
"Marjan, I do know a thing or two about working with delphi runtime & component packages.. been doing it for a long time. Of course we build third party libraries and components from source. Do you seriously (on your dev machine) have a copy of everything in the output folder of every project? Having more than one copy of rtl160.bpl etc on your machine is just asking for trouble (dll hell). "
Of course you do, that's why I was surprised...
No, I don't ... because we don't build with packages. However, if we did, yes I probably would.
I like it when I can press a single button, or run a single script and be absolutely for sure that any app I subsequently start is using _only and exactly_ what I just built and so is completely unaffected by whatever else have on my (dev) machine.
Having multiple copies of a single dll is not what is known as "dll hell".
Dll hell is when you put all dll's in a single folder (such as windows\system) and give all versions of a dll the exact same name. That way you can't have multiple applications dependent on the different versions of a dll. Upgrading one of the applications can then break another when it installs a newer version of that dll.
Since Delphi supported versioning in the name of the build target, that problem has gone and you can indeed put all packages in a single folder. But when you do, your application - and/or your dev environment - becomes dependent on the environment's path. And your application can stop working because somebody else (like Embarcadero) was less than civil when amending the path to suit their needs.
I don't much like trouble shooting these kinds of problems and while I probably wouldn't suffer them (or easily solve them) on my own development machine, I prefer to have a development environment that is as close as possible to the "real" installation at one of our customers. In fact our source control is set up to include a folder that exactly mimics our application's folder as it would be after a clean installation on a customer's machine. It helps to avoid a lot of those "it works on my machine" situations.
Also, having everything together for every version / branch on my dev machine gives me the freedom to use a single name or use versioned names for dll's or packages. And I like my freedom .
Oh, and you don't have to change the system path when you install your application (as Embarcadero shouldn't do either). Just put a cmd file along side your application in your application's root folder and put all dll's in a bin sub folder. Start your app through the cmd file and set the path in there before you start your exe. That way you can always have a "clean" path regardless of what the environment's path is. Of course all your application's shortcuts should point to the cmd file instead of the exe.
Marjan, I do know a thing or two about working with delphi runtime & component packages.. been doing it for a long time. Of course we build third party libraries and components from source. Do you seriously (on your dev machine) have a copy of everything in the output folder of every project? Having more than one copy of rtl160.bpl etc on your machine is just asking for trouble (dll hell).
KM, yes I came across that post today whilst searching.
This is a very good tool.
I have to access to a special sqlite-db with many TEXT colums, and I tryed many delphi components.
This was the only tool that give me access to this db.
Very fast and very simple
Thanks