I've taken over a legacy application and I have the exe created. If I can configure the BDE then in theory it should be possible to run this. Someone indicated that Delphi needs to be installed in order for the app to run. I'm unsure of that - it doesn't quite make sense to me as there is an exe file. Any input from Delphi experts would be appreciated.
Roddy
If the application uses the BDE then the BDE has to be installed before the exe can run. The BDE files are not linked into the exe.
A Delphi installation normally also installs the BDE. This might give the impression that Delphi has to be installed to run the exe, but that is not true.
According to the deployment licence you have to use something like InstallShield Express that comes with Delphi to create some setup for the BDE, but I might be mislead here. You may even try to google for a BDE installer or have a look at this question.
Your application should work without installting Delphi if it wasn't built to use runtime packages(BPL files).
If it was built to use runtime packages, you'll need to deploy them with your application. Since all delphi's runtime package are installed with Delphi, that may give the impression that installing delphi is required for the application to run, which is not the case.
You might however need to install delphi to retrieve the required BPL files.
BPL files are special DLL files that delphi can refers to instead of linking all code into the .Exe, making EXE files much smaller.
So if you manage to get the BDE up, create the right aliases in it, and get all required BPL(if any), the application should start up correctly.
1 last thing that might need to be deployed with your application is midas.dll. (If the application use, for exemple, Tclientdataset)
That's all I can think of for now...
It seems very awkward to me that Delphi needs to be installed to run your application. Maybe your application is build with runtime packages which means you have to include the bpl's the application depends on, but Delphi itself should not be needed.
You can test this yourself, just run the app on a computer without Delphi installed. When it gives an error about a bpl not found, you have to find that bpl and add it to the directory where your application is located.
Uwe has the answer here. if your application uses any of the data components provided by Delphi it will almost always require the BDE to be installed and other drivers if for example you are talking to Oracle then the Oracle OCI drivers must be installed.
You do not need Delphi to install the BDE but you need to find the BDE installer and have it installed. MANY programs out there use the BDE and not just Delphi since it was licensed by many companies.
Related
I've created some components in Delphi and I would like to give them to somebody else for use, but without source code.
I use the latest version of Delphi (10.2 Tokyo).
What are the steps I need to follow? Thank you!
If you want to share components in Delphi without source code, you must ensure that the other user has the exact same version of Delphi as you have[1]. This won't work with a different version. Note that it does not have to be the same SKU, i.e. you can have Professional or Community and the other can have, say, Enterprise. Only the version (e.g. Berlin 10.1, Tokyo 10.2, etc.) is important.
Then you can either
put them in a package and distribute the bpl and dcp files.
distribute the dcu files.
or both (preferrable)
Note that the user will have to install these. There are instructions in the help files on how to do that (no link, sorry, as the DocWiki seems to be down right now). Note that the package must be in one of the paths in the Windows DLL search order.
You could of course also write an installer, using one of the installer creating applications like InnoSetup (no association), but that is a topic of its own.
[1] That is the reason that many Delphi developers prefer components or classes with source and would not accept or buy one of these without source. Having the source also allows you to fix little bugs.
I have a virtual machine with the delphi xe2 installed and expired, I would like to know how export all components used in my projects from this machine to other that has the delphi xe2 installed and activated.
I done it:
I copied the program folder into my new machine, also was exported the register from the virtual machine and installed. I copied the *.bpl files from the system32 folder to the other machine.
I imported a project from virtual machine that works normally, and in my new machine occur many problems with components not found.
How can I solve this?
Notes: I have only this project in this virtual machine, I bought it.
I dont have many knowledges in Delphi. I am starting. I'm a Java Developer.
Thanks
Come to think of it: what is expired? If Delphi XE2 is expired, it is probably a trial version (which is usually an Architect SKU). You can not copy its components and use them. They will not work in a normal environment. Otherwise, someone could buy the much cheaper Professional and simply copy everything from the (Architect) trial version over to their Professional install and use them. The trial components are not compatible with anything but the trial of the same version.
If you mean third party components: usually, these components are installed with an installer. Copy these installers to your other installation and install them like before.
That is perhaps a bit slower, but the only proper way to do this. Anything else means fuddling with the registry and perhaps .ini files and what not, and a lot of frustration etc. The installers know what to install and how.
Your project sources can simply be copied over as they are, i.e. copy the entire directories. But first install all necessary components. If you used components from a trial version, and your XE2 doesn't have them, you must abandon them.
try 3rd party tools calling CnPack Wizard for copy configuration.
mostly BPL's are located in C:\Users\Public\Documents\Embarcadero\Studio\15.0\Bpl where 15.0 -- Delphi version number (15.0 is XE7)
My general question is how do you troubleshoot "My BPL won't load due to a dependency that just won't go away, no matter how much I clean up and recompile". Update You may think you have a clean recompiled system, but thanks to the inverse-miracle that is Windows and its file system virtualization mis-features, you haven't.
When I try to load my designtime package (in this case named dclFsTee.bpl) into my Delphi IDE (it's the fast report 4 teechart wrapper component package), it complains:
The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ...
That tee7100.bpl is not referenced on any DCP or DCU file on my system THAT I KNOW OF. But clearly, something is wrong, and I can't find the problem.
All Delphi users face a hundred "won't compile or won't load" problems with BPLs. The universal refrain when asked what to do is to clean up your computer.
However, I've now spent hours cleaning up my computer, and while everything compiles file, clearly there must be something out of date hiding somewhere, because the resulting BPL file that I'm trying to load still wants to load a version of a TeeChart BPL that I removed from this system days ago, along with every trace I could find.
The traces of TeeChart stuff in Delphi 2007 that I removed include everything in the $(BDS)\Lib and $(BDS)\Lib\debug folder, and all DCP and BPL folders on the system. Also every TeeChart-unit-named dcu file is gone.
Once you've gotten to the end of the road, what do you try next? (Format the hard drive, buy new computer.) Seriously. I think I'm a smart guy, but I have a 1 tb hard drive, a library path that runs to 80+ folders, and a source code repository that seems to be well organized, but clearly something is hiding where I can't find it.
I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains any old TeeChart BPLs or DCP files from the "tee chart tee7100.bpl" version that ships with delphi.
I have run the "recompile.exe" wizard that comes with teechart, which appears to just run MSBuild and build the packages, after writing a {$DEFINE x} declaration to the tee.inc files (there are two of them in the source distribution).
However, somehow, silently it seems like one of the implicit imports into one of the packages is drawing in some stale file which has not been rebuilt, and which therefore tries to load the tee7100.bpl. The new bpl name is tee911.bpl.
Rather than ask the pretty-specific-to-fastreport question, I'm only mentioning it as a specific instance of a general world of hurt that I have faced dozens of times while developing in Delphi.
I'm only giving the fast-report details so you can see that this is in fact a specific instance of a general problem that one faces sometimes inside Delphi IDE when dealing with a component source code or package, or set of packages, with dependencies. Cleaning up your computer so that your code even builds can be tricky.
So here is my Delphi package-to-package-dependency-resolution question:
What is the most effective way to find or trace implicit-load-of-some-no-longer-wanted BPL-problems so that my code (which builds and compiles just fine!) will actually load into the Delphi IDE. The BPL file that results from running Recompile seems to be linking properly to the right DCP files, and no old/stale DCP or DCU files are present. The new DCP file name is tee911.dcp, for instance.
Can you get somehow, any idea of what package is actually stale, and what is being read and linked and imported statically when the .bpl links? (I'm thinking maybe like a special MAP-like file for BPL files?)
Update After many hours of fighting with this, and using every trick I know, I realized I hadn't checked for some VirtualStore related issues caused by file virtualization in Windows 7. That means that Windows 7 lies to the programs that run on top of it. It gives you another version of the file, that isn't the one you want. This can be deadly in several ways; One; You recompile a BPL but that's not the one that loads. The BPL that was killing me was in the SysWow64 folder that was part of the VirtualStore. Note that the virtualstore basically makes phantom files appear that are only there if you're a certain "low privelege" program, which Delphi 2007 on Win7/64 bit, apparently is. To remove BPL files in your SysWow64 VIRTUALSTORE folder for your current user account:
del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl
... Some days I just hate Windows architecture. Anyways, I'm not going to put the above as the answer, because I'd like to know if anyone has a better way or any tip or suggestion that might help next time.
Okay nobody else answered so I'll put this here to be helpful for future people:
-- Remember Windows VirtualStore when cleaning up broken systems which have old versions of DLLs on them including TeeChart, FastReport, Indy and so on which tend to be involved in messes because they can exist both as "out of box packages that ship with delphi" as well as frequently installed as upgraded versions if you purchased and installed them from the vendors directly, or third, you may have your own compiled copy in your company's mega-component-pack-directory.
-- When searching for duplicate or out of date BPLs, doing a file search in windows doesn't look in the virtualstores, you'll have to locate and zap the whole virtualstore area for your process or user, or program, manually.
The second level of this issue is this:
The dependency graph for FastReports is complex:
It depends on Indy and you might have your own version of Indy, and Delphi itself has one, and other things on your hard drive might have their own copy of Indy.
It supports various editions of TeeChart, including the binaries that come with Delphi, and perhaps the Standard version or other purchased version of TeeChart that you might have bought from Steema.
It uses a precompiled header include file to do the compilation and not just ONE but TWO different copies of an identically named include (.inc) file.
When you use their own compiler tool (recompile FastReport) it works pretty reliably but isn't the best for when you want to build everything in your project from a single build script, thus the source of my problem.
The key is to learn everything there is to know about the dependencies of all the components in your giant pile of packages, and to organize your system cleanly so that you don't have old stuff (like Indy and TeeChart bpls, dcp, or dcu files) lying around. Cleaning that up is quite a complex job if you don't know what you're doing.
A utility to really remove all traces of the version of Indy and TeeChart that ship with your system, and the "Embarcadero edition" of FastReports is key to getting this situation resolved. A general tip is that "if a version of X ships with Delphi and you are going to install a new version, prepare to suffer until your system is really cleaned up".
A really amazing technique to avoid all this crap is to just not install Indy, FastReport or TeeChart (uncheck them or skip them) during your initial Delphi IDE install, then install them yourself, one by one, from sources. Just because a version comes pre-installed in Delphi doesn't make that a good thing. (Update: You can no longer unselect Indy during install, it's part of the base Delphi product since at least Delphi XE8. A clean-up utility to remove the built-in Indy from Delphi's own lib dirs is necessary for anyone who builds their own.)
Another really amazing technique is to run the Installers for commercial components on a virtual machine, then just collect up the pascal source code and transfer that onto your clean development machine, and build it yourself. That way you can avoid the terrible things that happen when you've got BPLs and stuff scattered around your system, and even installed into C:\Windows\System32 (on 32 bit systems) and C:\Windows\SysWow64 (the equivalent path on 64 bit systems).
put that BPL (tee7100.bpl) under $(BDSCOMMONDIR)\Bpl
for XE: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\8.0"
for XE5: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\12.0"
The other issue that can cause this, is not having the folder where you've stored your .bpl files in your system path.
This happens because Delphi attempts to call the WinAPI function LoadLibrary with a file name, instead of an absolute path. So if Windows can't find the file, Delphi can't load it.
See this forum post for more information.
This seems to be an issue in Windows 7, though not in Windows 10.
I am trying to create an installation disk with InstallAware Express for my Delphi 2010 application. I have selected (checked)
CodeGear Database Express12
CodeGear Visual Component Library 12
for Application Runtime.
When I try to build it, I will get an error message
Error during build: No files matching pattern "C:\Windows\system32\*120.bpl"
The message will go away if I un-check the above runtime but of coz the program will not run.
Can someone please tell me what I am doing wrong?
Also... I have use their scan file button to scan the dependent files base on my application.exe and installaware put a list of files in the $TARGETDIR$, should I leave them there or I am suppose to move them to various folder (e.g. some of the files are from the windows\system32 directory...)
Thanks a lot.
FWIW, one of the great things about Delphi is that you can pretty much install on any system without worry if you turn off the "build with packages" option. This would eliminate the need for these files, and solve your problem, and also make the application more robust against updates and changes. IMO packages are only needed if you are building multi-module applications which are more advanced, and in that case you wouldn't want to be using any Express installer.
You can manually add the files.
To find out which VCL packages your application uses, open the project in the IDE. Use the menu item Project->Build project to rebuild your entire application, and then use Project->Information to view the information dialog. The list of packages actually required by (and therefore needing to be distributed with) your application are listed there.
Where to install them on the destination system depends on why you're using packages in the first place. If you're using runtime packages simply to reduce the download size for your users, and the packages will only be used by this single application, put them in the same folder as your application ($TARGETDIR$). If you're using them because you've got several different applications, and they'll all be installed in different locations but use the same runtime packages, install them in the System32 folder ($SYSDIR$, if I remember correctly).
InnoSetup works fine with runtime packages manually added, btw, especially if you use the excellent (and also free) ISTool IDE. (Not affiliated in any way; just a happy customer.)
Did you have Delphi 2010 installed on this machine? If so, you should see several bpl files under C:\Windows\system32 folder.
I created a project in Delphi 7, How to save the project with all packages, to be ready to use on other computers that do not have installed by default those packages. Maybe somebody knows a good tutorial. Sorry for the question if I formulated it incorrect.
Sorry, but that is not how Delphi works. Packages are separate from projects that use them. There is no way to tell the IDE to save them all together. You will have to deploy the packages themselves onto the other computer and install them into the IDE before you can then open any projects that use the packages.
To run the build application in Delphi 7 on another computer you only need to copy the exe to that other computer. There is no need to collect packages, the Delphi compiler creates an executable that works standalone.
If you used a ClientDataSet than make sure that in your source you have incluced MidasLib in your uses, if you do not than you have to supply Midas.dll also.
That should be all.
If this does not works, than tell us what error message you get when running the built application on the other computer.