Delphi IDE uses InstallAware as installer in last few releases (2010, XE, XE2, XE3, XE4). Using the normal setup.exe installation will copy a few GB of files into c:\programdata if you install all the IDE releases.
The installer consumes disk spaces quickly especially for users who use an SSD hard disk that is expensive.
Is it possible to setup the Delphi IDEs without copying files to c:\ProgramData? Is it advisable to delete those files manually after installation too? Uninstalling a previous version of the IDE does delete these files but as component maker, I need those IDEs for testing.
Partial answer here.
Is it advisable to delete those files manually after installation too?
Of course, official answer is NO. But you actually can delete these files at the cost of losing installer's "Repair" capability. (Repair is standard MSI feature, and InstallAway is merely yet another front-end for MSI). Also, it will render any manual restoration of particular file impossible, since files are stored in encrypted 7-zip archives on distribution medium (yet another unfriendly feature).
Unfortunately, I do not know any way to disable creation of such local copy of distribution medium.
Related
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)
Delphi IDE uses InstallAware as installer in last few releases (2010, XE, XE2, XE3, XE4). Using the normal setup.exe installation will copy a few GB of files into c:\programdata if you install all the IDE releases.
The installer consumes disk spaces quickly especially for users who use an SSD hard disk that is expensive.
Is it possible to setup the Delphi IDEs without copying files to c:\ProgramData? Is it advisable to delete those files manually after installation too? Uninstalling a previous version of the IDE does delete these files but as component maker, I need those IDEs for testing.
Partial answer here.
Is it advisable to delete those files manually after installation too?
Of course, official answer is NO. But you actually can delete these files at the cost of losing installer's "Repair" capability. (Repair is standard MSI feature, and InstallAway is merely yet another front-end for MSI). Also, it will render any manual restoration of particular file impossible, since files are stored in encrypted 7-zip archives on distribution medium (yet another unfriendly feature).
Unfortunately, I do not know any way to disable creation of such local copy of distribution medium.
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've got a Delphi 2007 VM which includes a reasonably up-to-date Report Builder and Dev Express Suite. I use it for a particular project for a particular client.
For that same client, I also have a D5 VM which just so happens to use a (different, older) version of Report Builder and a different (older) version of some of the Dev Express components.
It would make testing and general maintenance of my work for this client a lot more straightforward if I could install D5 (and the versions of the components it uses) onto the D2007 VM, and have one 'uber VM' that contained everything for that client. Naturally I'd have to keep the various versions of the components 'separate'.
Hope you haven't all drifted off to sleep with boredom yet - just wondered if there were any tricks or tips I should be aware of before I try to do this. I figured that putting D5 onto the D2007 machine would be easier (larger existing VM drive etc, plus avoiding the process of re-registering a D2007 installation etc), but in if would be easier to add D2007 to D5 then I could do it that way round I guess.
Any advice? :-)
Multiple Delphi versions do coexist quite nicely if you install them in the correct order, newer versions after older ones. This is something that holds for VMs just as for real machines. If you have a VM manager with snapshot capabilities you could try to install Delphi 5 over Delphi 2007 and see whether anything breaks - if so you simply revert to the snapshot. However, since setting up a new VM isn't a big task I would do that instead and install Delphi versions in the recommended order.
Multiple versions of component sets can be installed as well, each into its own directory. Only one of them can be registered inside one IDE, obviously, but you can use different versions for different IDE versions. If you have an installer that gives you trouble you can always install Delphi and the component sets in one account and develop in another account. Installers do generally write only to the machine and current user registry hives, so running Delphi in another account allows you to install packages manually. Be sure to build the packages in Delphi-version-specific directories - even though most packages have version-specific package files all other source files have the same name and need to be rebuilt for each Delphi version.