I'm using InstallShield 2013 (Basic MSI Project) to create installation package for my product.
Product requires DirectX End-User-Runtime to be installed, so I created custom prerequisite for DirectX in my InstallShield solution.
I don't want install DirectX End-User-Runtime every time I install my product, so I want to add a condition for DirectX in Prerequisite Editor. My product is a 64-bit application and it requires some directX files in C:\Windows\System32 folder (At least I know that it won't work without D3DCompiler_43.dll and D3DX9_43.dll).
So, I'm adding conditions for my prerequisite:
Install DirectX End-User-Runtime if files
[WindowsFolder]system32\D3DCompiler_43.dll and
[WindowsFolder]system32\D3DX9_43.dll
are missed on target box.
I tested my installation package on two 64-bit Win7 boxes. DirectX Prerequisite condition works fine on the first box - it installs DirectX only if both D3DCompiler_43.dll and D3DX9_43.dll are missed in C:\Windows\System32. But problem appears when I install the same package on the second 64-bit box: for some reasons prerequisite condition doesn't work properly there - it tries to find D3DCompiler_43.dll and D3DX9_43.dll not in C:Windows\System32 but in C:Windows\SysWOW64 folder.
Can someone explain why it looks in SysWOW64 even if I hardcode path to C:\Windows\System32?
And one more question - probably someone knows a better way how to check if DirectX End-User-Runtime is installed on target box? I found similar topic here check registry for DirectX End-User Runtime, but I cannot understand how and where in Prerequisite Editor can I use LoadLibrary("d3dx9_43.dll") function...
In InstallShield 2013, there are 2 types of prerequisites:
- Setup Prerequisites install before the main install
- Feature Prerequisites install only if that feature is selected for
installation.
You can't call a DLL in a Setup Prerequisite, because a setup prerequisite runs before your MSI, and therefore before any of your custom actions.
If you create a Feature Prerequisite, you can set a custom action to call a DLL (such as d3dx9_43.dll that you mentioned). I am not familiar with this DLL, so I can't tell you what your custom action would look like. You can turn on or off this feature based on the result of your DLL call.
Related
So, I tried installing Microsoft DirectX 2010, when I was setting the directory of in the installer I put it to the wrong directory that I wanted it in. Now, every time I open the installer, it doesn't give me an option to change the directory, it just says continue and install. If anyone has a solution to this that would be really nice.
EDIT: Also forgot to note that when I installed it on my D: drive (its supposed to be on C: ) I get the error code S1023
The S1023 issue is detailed in this post. Because the setup just outright failed, and it's built on ancient pre-MSI technology, you need to clean out the old installation manually.
Delete the failed install directory
Using regedit to delete HKCU\Software\Microsoft\DirectX SDK, HKLM\Software\Microsoft\DirectX SDK. If you are on a x64 system (which I hope you are), also delete HKLM\SOFTWARE\WOW6432Node\Microsoft\DirectX SDK.
Edit your system environment variables and remove the entry for DXSDK_DIR.
The DirectX SDK is deprecated. If you are using VS 2012 or later -or- the Windows 8.0 SDK or later, and you are using DirectX 11 or DirectX 12, then you don't need it. See Microsoft Docs.
There are a few cases where it's still legitimate to use the legacy DirectX SDK as covered in The Zombie DirectX SDK, but for the most part you should avoid using it for new projects.
If you are trying to get an old game to work, try installing the latest DXSETUP/DXWSETUP but keep in mind that it doesn't actually install DirectX at all. See Not So Direct Setup
UPDATE: There are now really no reasons to use the legacy DirectX SDK at all. See Where is the DirectX SDK (2021 Edition)? for the overall status and details.
For legacy D3DX9/D3DX10/D3DX11, use the Microsoft.DXSDK.D3DX NuGet package per this blog post. No need for the legacy DirectX SDK or to use legacy DXSETUP for this solution.
For XAudio2 on Windows 7, use the Microsoft.XAudio2.Redist NuGet package per Microsoft Docs.
I have an old software that uses DirectX 9. It's quite obsolete but there are still people using it.
Win10 does not come with DX9 preinstalled and I want to add it to my installer. So far I see that there's a large (100mb) DX package from Microsoft that contains all the versions and builds of DX9 and 10. (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en)
Among the many version, I see, for example, "Jun2010_d3dx9_43_x86.cab" that contains the .dll, .cat and .inf. I'd say that this is sufficient for what I need so I'd add this to my program's installer (inno-setup).
I am a bit outdated on DX and DLLs knowledge. Can someone give some pointers on how to proceed and if it's right installing only one of that dll?
Thanks!
DirectX 9.0c does in fact come with Windows 10. Starting with Windows XP Service Pack 2, the "DirectX End-user Runtime" never installs DirectX on any version of Windows. The only way to update "DirectX" is to install a Service Pack, a Windows Update, or move to a new version of Windows.
See Not So Direct Setup for the full story here.
Your old application, however, likely does rely on some optional side-by-side components like D3DX9, D3DX10, D3DX11, XAudio2_7, XInput1_3, D3DCompile #43, Managed DirectX 1.1, or other thing that is only deployed by the legacy DirectX End-User Runtime. In that case, you should download the latest DXSETUP package (the April 2011 refresh of the end-of-life DirectX SDK June 2010 release on MSDN).
You can then configure a minimal package that will deploy just the DLLs you actually use. For example, if you used the D3DX9 June 2010 DirectX SDK for a 32-bit application, but that's all you needed, you can get away with an install package of just:
dxsetup.exe
dsetup32.dll
dsetup.dll
dxupdate.cab
Jun2010_d3dx9_43_x86.cab
Of course, if your application is old enough to be using a previous version of D3DX9, then you need to figure that out and use the right .cab.
See Where is the DirectX SDK? as well.
Let's say we have a team that works on many different projects. Each team member uses different set of visual/non-visual controls/components during it's development cycle. Since Delphi requires each component to be compiled and installed globally in the IDE, how to manage this situation while working with project which was started by the other team member?
It would be great if I could checkout the sources of a project from the version control and have the ability to compile it immediately. I don't care or sometimes don't know what visual or non-visual components are required for this project, I guess they all should be included in the project sources.
Maybe there are some tools which could read main project file or directory and compile/install all the needed components on project loading (and uninstall them when project is closed)?
How do you handle this issue in Delphi?
In our company, we have the same problem.
We solve this by forcing everyone to have all necessary library paths added to their delphi ide.
We are using an additional sdk/framwork repository which containins all components/sdks/frameworks of everyone .
We keep a single text file, listing all libs with its version, install infos, etc.
Everyone checks their wanted libraries, so we do not have double libraries or different versions.
Since we all work under Windows and since Delphi keeps its paths and (afaik) installed-components informations in the registry, we extracted these informations.
We store for each used delphi version a .reg file within the sdk repository trunk.
So, if someone changes a framework, he updates the informations for everyone in the .reg files and commits it.
now, if someone wants to setup their dev-machine, they check-out the sdk, adds the e.g. xe2.reg informations to their registry, then check out the project and ... tada. compiling.
We have not tried to extract the "installed components" packages. thats on our to-do list.
An alternative would be to keep a batch file for building and installing all sdk packages at once. But i do not know if installing components via commandline is possible in delphi.
Something like the JEDI installer would be nice. The installer detects installed Delphi versions and builds & installs everything nicely.
A freely configurable version would be nice, so add all sdks -> install on each version.. perfect.
Anyone who wants to compile a given project must first install any components that project is using. There is no getting around that, unless the project directly includes the components source code and instantiates the components in code instead of using a DFM. AFAIK, there is no IDE tool that will automated component (un)installation on a per-project basis for you.
It's very wise to constraint which components and libraries that will be used by your team. If each member decide which component they will use, your final executable or packages will grow a lot and you can have some incompatibilities between libraries.
Besides, you can have extra costs buying and updating libraries that are very similar. Remember that each time Delphi is updated, you should buy new licences from most of that libraries.
So the best approach is:
ask which libraries each developer are using and discuss with them the real need of each one;
catalog those library required and install them on the machine that you will compile your final code;
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".
Is there a way to select designtime packages on a project bases?
Packages are very useful in large project to keep the build time acceptable, but they are a real pita in those large projects too. When one developer adds a new package, it breaks to build for all other until they install the new package on their machine. And then there is versioning of the packages ...
So has anyone a proper solution for this? (it has been bothering me for years now)
At my previous job I wrote a little tool to help us with versioning packages. I really should recreate that tool in my spare time and make it available. The tool was not hard to write though, so maybe you can implement something like it yourself.
Basically it worked like this:
Subversion repo with all the packages in subfolders. Each package folder in the repo had the same subfolders: Lib (for DCUs), Source, Help (if needed)
In the root folder of the repo sits the tool together with an XML file.
The XML file specified all needed information for each package: which folder contained DCUs, which folder contained source, which command needed to be run for the help.
The tool reads in the XML and displays a checklistbox of all the available packages. Installed packages (read from the BDS registry) are marked checked.
The user can make a selection of which packages to install/uninstall.
The tool adds/removes the necessary keys in the BDS registry. It adds the DCU/Lib folder into the search path of the IDE, it adds the source folder to the IDE browsing path, and it registers the help command with a custom IDE expert (This expert provides an extension to the default help menu to launch the help for all the installed packages)
The tool would even check for conflicts and dependencies between packages. For example both version 3 and 4 of Raize Components were available which could not both be active at the same time. Dependencies checking was useful for in-house components that derived from TurboPower AsyncPro (lot of in-house components relied on serial communication via AsyncPro)
A possible extension would have been to be able to save/load the selection of packages and store that selection with each project so you can have only the packages loaded that are needed for a particular project.
I implemented all this when the company was moving from Delphi 5/7 to Delphi 2007. We had a lot of problems with package versioning before and wanted some way to version all the different packages.
This approach offered some nice advantages:
When bugfixes had to be made or new versions of third-party packages were released, one person had to commit the changes to subversion. All the other devs could just do an update from subversion and have the latest version without any problems.
When new component packages would be added to the environment, one person had to commit all the files, change the XML package list and then the other devs could do an subversion update and run the tool to integrate the package easily.
All third-party and custom in-house components were now versioned easily.
By including the DCUs (and other binaries) in the subversion repo, we ensured that all devs used the same compiled version. Before it was possible that different compilations used different settings which caused some components to behave differently.
When all the other devs finally installed Delphi 2007, their packages were setup in less than 10 minutes (most of the time spent downloading everything from the subversion repo; the tool itself could install 20 packages in less than 2 seconds). Before, with the manual installation of all packages for Delphi5/7 it could take up to 2 days to get everything installed.
This wasn't just used for some in-house components alone, the repo also included some of the big component packages: Raize Components, JCL/JVCL (Using their installer instead of the tool though), DevExpress Quantum Grid 3 and 4, TurboPower AsyncPro
This is not easy too do. You can do it though, with the use of a custom registry hack, and a specific bds shortcut per configuration you are interested in:
To use, just create a new shortcut and
modify the command line to pass e.g.
-rMyAlternateBDSReg. Then after launching that once, the reg entry is
created and they can configure that
alternate registry all they want,
deleting packages, etc, without
worrying about messing up the default
install.
From codegear
If you set up a configuration for each project, you can then start the appropriate shortcut for the given project. It's not automatic, but it is better than having everything there all the time.
A nice side effect is that the load times will be improved.
We put the source for our packages in source control along with a batchfile that rebuilds them. If there is a change in the tree for packages then we rebuild them. This doesn't address installing new packages, but there are registry hits that can take care of that, so it is possible that we could include .reg snippets maybe to handle that.