Download Torrent Rad Studio Com O Delphi Xe4 2012 Com
Fanny Lococo
Now I could solve that problem. Actually, as we are using .net dll in Delphi exe, we can catch the exceptions from Visual Studio for unmanaged codes inside Hydra for delphi. I did some changes inside Visual Studio. Go to project -> projectproperties -> Choose Debug mode -> Choose Start External Program -> Browse the Delphi exe file path. Then go to Debug -> Exceptions -> Check Common Language Runtime Exception.That's all. Then when you run your .net project it also run Delphi project and catch the exceptions of unmanaged codes inside Delphi.
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.
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.
You may only use this software if you are an authorized licensee of an Embarcadero developer tools product. This software is considered a Redistributable as defined in the software license agreement that comes with the Embarcadero Products and is governed by the terms of such software license agreement -studio/rad-studio-eula.
Updates and additional software for RAD Studio users are available on the registered users download page at _studio. More major new feature upgrades are available only to users with current maintenance agreements. Notifications for those upgrades are delivered via email and the upgrades can be downloaded via the Maintenance Portal web site by following the instructions in the email.
aa06259810