Following MS' advice we have stripped most files from the DX installer contents for our D3D9 application, getting it down to 5Mb in total.
But now I;d like to package these files into a single installer, like the redistributable installers MS themselves provide... so it can be run as part of our application install process, with /silent switch, without manually having to unpackage the files and delete them.
Is there a simple, standard way to do this so that the packaged DXSetup.exe is run?
Or is all this too complex and we should just unpack the files, run DXSetup.exe and then delete the files after installation?
Its better to use the installers that MS provide, usually is what Apps do, if the problem is space you could always use web installer its 300kb but will require the user to have an internet connection.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en
On the other and if you're using DirectX SDK
there is a folder "redist"
and in it there are setup's of DX,
you can distribute them with your app,
and your Setup has to call the dxsetup.exe
Related
I'll be reinstalling Windows and I wondered if there's a way to backup/restore Delphi license info so I don't "lose" one of my installations for that.
In other words - is there a way to uninstall Delphi, reinstall Windows, reinstall Delphi without that being treated as a "new" installation?
[I want to completely wipe out my computer and start out from scratch. I'll be reinstalling XE5, XE7, and 10 Seattle.]
The .slip files used for registration info are in C:\ProgramData, in either the CodeGear or Embarcadero folders depending on which version of the IDE you're using.
I've successfully copied the files from these folders to a thumb drive and moved them to a new computer. Note that part of the registration information is the local computer name, so in order to work on a different machine (or a clean Windows install on the same machine) the computer name needs to stay the same. Just name the computer the same, copy the .slip files to the same location on the new machine, and then install Delphi/RAD Studio.
To be on the safe side, I always copy the entire folder (including all subfolders and their contents) to make sure I've gotten everything the IDE needs.
I had a similar problem when renaming my Windows 10 computer. Apparently the license is bound to the computer name. I had to re-register Delphi after renaming my computer but failed because of the limit of my license key.
Solution was renaming back my computer and renaming C:\ProgramData\Embarcadero\.cgb_license.corrupted and C:\ProgramData\Embarcadero\.licenses\.cg_license.corrupted to files without the .corrupted as suffix. My licence slip file was C:\ProgramData\Embarcadero\.2016_2.#############.slip.
I made an application with ADO Component and connect to Oracle with it, I don't have any problem when I run it in another machine.
But, when I use ODAC component and TOraSession and connect with it via Direct Connect and run it in another machine I faced to this error:
The Program Can't Start Because dbrtl70.bpl is missing from your Computer. Try to re installing the Program to fix it
As I investigate, dbrtl70.bpl is Delphi package file in System32 folder.
I want to know how can I solve this problem.
I'm going to take a wild guess and suggest that you have a 64 bit machine. You've copied the .bpl files into the 64 bit system folder (System32) where your 32 bit Delphi 7 program cannot see them. Put them in the 32 bit system folder (SysWOW64) instead and all should be well.
To learn more about the issue, read up on the File System Redirector.
If you don't want runtime packages, and all your dependencies support being built without using runtime packages, then simply uncheck the use runtime packages option.
My app was asking for a .bpl package when run on other machines.
Cancelling 'link with runtime packages' didn't solve it until I deleted the runtime packages listed in 'runtime packages'. Then it was OK.
I have Python 2.7 installed in "C:\Python27". Now I run 1st demo of Python4delphi with D7, which somehow uses my Py2.7 install folder. If I rename Python folder, demo can't run (without error message). I didn't change properties of a demo form.
What part/file does py4delphi use from my Python folder?
python4delphi is a loose wrapper around the Python API and as such relies on a functioning Python installation. Typically on Windows this comprises at least the following:
The main Python directory. On your system this is C:\Python27.
The Python DLL which is python27.dll and lives in your system directory.
Registry settings that indicate where your Python directory is installed.
When you rename the Python directory, the registry settings refer to a location that no longer exists. And so the failure you observe is entirely to be expected.
Perhaps you are trying to work out how to deploy your application in a self-contained way without requiring an external dependency on a Python installation. If so, then I suggest you look in to one of the portable Python distributions. You may need to adapt python4delphi a little to find the Python DLL which will be located under your application's directory. But that should be all that's needed. Take care of the licensing issues too if you do distribute Python with your application.
I have some installers like
JDK
Apache Tomcat
MySQL
MySQL GUI, etc.
I want to bundle all these installers together into a single .exe file, So that a single exe will in walk through all of the installers one by one. The result will (hopefully) make installation of many packages as painless as possible for the user.
MySQL installers were in .msi format. I converted them into .exe by using an MSI to exe converter.
I'm able to find many setup creators, but I don't think they'll do what I want. How can I bundle all of these packages together under a single installer? Is there a tool that I can use to do this?
I got some useful links http://en.wikipedia.org/wiki/List_of_installation_software , Refer this question
I searched a lot, but all are guessed answers. Help me to find the exact answer.
An MSI is a Windows Installer database. Windows Installer (a service installed with Windows) uses this to install software on your system (i.e. copy files, set registry values, etc...).
A setup.exe may either be a bootstrapper or a non-msi installer. A non-msi installer will extract the installation resources from itself and manage their installation directly. A bootstrapper will contain an MSI instead of individual files. In this case, the setup.exe will call Windows Installer to install the MSI.
Some reasons you might want to use a setup.exe:
Windows Installer only allows one MSI to be installing at a time. This means that it is difficult to have an MSI install other MSIs (e.g. dependencies like the .NET framework or C++ runtime). Since a setup.exe is not an MSI, it can be used to install several MSIs in sequence.
You might want more precise control over how the installation is managed. An MSI has very specific rules about how it manages the installations, including installing, upgrading, and uninstalling. A setup.exe gives complete control over the software configuration process. This should only be done if you really need the extra control since it is a lot of work, and it can be tricky to get it right.
.msi files are windows installer files without the windows installer runtime, setup.exe can be any executable programm (probably one that installs stuff on your computer)
MSI is an installer file which installs your program on the executing system.
Setup.exe is an application (executable file) which has msi file(s) as its one of the resources.
Executing Setup.exe will in turn execute msi (the installer) which writes your application to the system.
Edit (as suggested in comment): Setup executable files don't necessarily have an MSI resource internally
MSI is basically an installer from Microsoft that is built into windows. It associates components with features and contains installation control information. It is not necessary that this file contains actual user required files i.e the application programs which user expects. MSI can contain another setup.exe inside it which the MSI wraps, which actually contains the user required files.
Hope this clears you doubt.