Embarcadero Rad Studio Xe Lite 15.0.3890.34076 Portable
Phyllis Sterlin
Comments on this post have gotten way off topic. For the record, our products all install their executable files in their own install folder (apart from one com dll shared between finalbuilder and automise). Closing comments now.
The solution to avoid "DLL hell" is exactly to have each application DLLs available to that application only - or use strong named ones in a "global" area - to ensure each application uses only the DLL it is designed for.
"DLL hell" was caused by sharing DLLS and having multiple copies of the same DLL available somehow for each application, and which one was actually used depending on "run time" conditions like the system path variable, and/or the order of installing applications because each installer happily overwrite others.
While MS can install its runtime in the Windows system directory - but it does use strong names too - others can't (and shouldn't) so easily. Thereby or you do install in the same application directory (or below it), or install in *your* "common" directory (under common files, for example) and set the application DLL search order to use that path as well (there's an API for that... or other methods to alter the path see my previous post)
Having executable files (and remember DLL - including BPLs - *are* executable files) in user writeable folders is huge security risk.
Once where disks and memory were small are over, and there's really little need to try to minimize the space used by application files and trying to load the same DLL in memory once - that was the reason to try to share DLLs as much as possible, leading to "DLL Hell" because there were no good rules to perfom it - not that too many developers abide to Windows programming rules and guidelines, many still use those barely valid for Windows 3.0
Ah, yes of course. Now I understand. And now I understand why it isn't a problem for me. I don't have design time components installed...
Don't do much UI programming and if I do have to change a form unit I can get away with ignoring the dfm related errors as long as I don't have to change the visual layout... :D
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.
@Vincent - Glad to see the junction trick solved your path problem. Now if someone would only write a nice graphical tool to automate the process ;) That has been on my list for a long time, but I never seem to find the time.
@KM - The path length limit lives on even in the latest versions of Windows. I know because I it has been a thorn in my side for years. Interestingly, installing new software will often push Windows over it's max limit and cause the path to become effectively empty. Still in the registry, just not loaded into the environment when new processes are started. Rebooting the PC usually resolves the issue until the next install. Apparently a longer path can be loaded at boot time for some reason.
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.
"Scott, if you use runtime packages you do need those entries on the path (for third party packages)."
??? Why ???
Your application shouldn't be dependent on the environment path of the machine on which it is running.
Any run time packages and other resources (dll's, images, the whole she-bang) your application needs should be in the same folder as the application itself.
Yes, that means building everything to the same location.
Should not be a problem as you should be building your libraries (both your own and third party ones) from source anyway.
So add the packages you need to your project group, set their output location to be the same as that of your application and just build (all).
There are several better ways, IMHO:
1) Remove all nasty program specific entries, and use specific .cmd files to setup the environment for specific applications. It's also very useful if you use different versions, you are sure to work in an environment setup up for a specific version and not calling something of a previous/later version, depending on what app was installed last. Delphi already offers a "RAD Studio command prompt" - that's what you should use to invoke command line tools.
2) Use the App Paths subkeys in the registry ( -us/library/windows/desktop/ee872121(v=vs.85).aspx)
3) Applications should set their pown DLL search paths if DLLs/BPLs are not in the same folder, and don't rely too much on environments paths that may be altered and make them load the wrong DLL.
4) Set needed environment variables used while working in the IDE into the IDE settings
Otherwise it all comes down to lazy and outdate programming habits...
All those paths are really nonsense because you can just extend the path from within Delphi itself via options - environment variables (like Scott said). Only runtime packages are a spoiler if you try to run outside Delphi or need to compile from the command line.
Scott, if you use runtime packages you do need those entries on the path (for third party packages).
Taz, I used to do that, but the length limit applies to the expanded value so it doesn't work.
KM, I tried that, on my windows 7 x64 machine, if I open a cmd window, and type set, the path shows as truncated. I also had all sorts of problems with my machine because of the path truncation. I could not find a difinitive answer on the microsoft site, some pages say env variable can be 2047 chars, some say 1024. I've had this problem several times over the last few years, each time after installing a new version of rad studio.
I'm not sure why they add them to the system path anyway.
I Rip them out.
In the IDE go to tools / options / environment variables.
Add a new user variable called "Path"
Add all the BDS paths followed by ";PATH"
This method works especially well with multiple versions installed.
It is not true that the maximum path size is 1023 characters. Actually, the limit is 32k. In pre-Vista/2008 OS, the whole enviroment block is limited to 32k - thereby not allowing large environment variables, but that limit is now lifted (unless you're so stubborn to keep on using outdated and unsupported OSes...). Some tools and application may not allow more than 1023 characters in the path variable, but that's just a tool/application limitation (due to an old, no longer valid limit), not one of the system. You can edit directly the system path in the registry and use a far longer one, but beware some older, bad written application may break.
About the Delphi bad behaviour, I'm not sure it that code is in Delphi or InstallAware.
References:
-us
-us/library/windows/desktop/ms682653(v=vs.85).aspx