See also our Knowledge Base.
32-bit and 64-bit issues
.Net installation
File installation
File registration
Shortcut installation
Application registration during installation
This doesn't require anything special. Our installers run on both 32-bit and 64-bit versions of Windows and will install both 32-bit and 64-bit programs without further ado. (Although 64-bit applications will only run if installed on a 64-bit system, they can be installed on a 32-bit system if you wish.)
If you need to create a pure 64-bit installer, for example to run in a 64-bit Windows Preinstallation Environment (which doesn't have a WoW64 layer), then set Install on: x64 Windows only in the Build Configuration.
That depends on your application, not on the Windows target. If it's a 32-bit application, it must be installed under Program Files (32-bit); if it's a 64-bit application, then it should go under Program Files (64-bit). At installation time, the installer will then use the correct folder on the target system. See Files and Folders for details about these magical folders.
By using a suitable prerequisite on the Prerequisites page. We have predefined prerequisites for all current .Net releases; each prerequisite will check for the presence of its .Net version on the target system, and automatically download and install the correct .Net redistributable if the required version is not present. This also takes into account x86 (32-bit) versus x64 (64-bit) versions of the .Net runtime.
That depends on your application, not on the Windows target. If it's a 32-bit application, it must be installed under Program Files (32-bit); if it's a 64-bit application, then it should go under Program Files (64-bit). At installation time, the installer will then use the correct folder on the target system. See Files and Folders for details about these magical folders.
By using our GiveAccess tool. Include that in your installer, then run it in a Run Program action during the MainInstall action sequence. The Run Program action attributes should be similar to this:
Finally, move the action up (Ctrl+Up) until it appears immediately after the predefined CreateFolders action.
The short answer: don't set it; instead let the user choose. However, if you really must, then create a new Set Variable action in the DoFirstInstall action sequence on the Action Sequences page. Place this action before the predefined SetInstallDir action (use Ctrl+Up to move the new action up after creating it). Set its attributes as follows:
This always was tricky, but it has become more complicated since Windows Vista. The short answer is: don't use files that must be writable to all users. Instead, split your application data into read-only data that you place in or near the application's installation folder, and writable data that you duplicate for each user in the user's private folders such as My Documents or the per-user Application Data folders.
If your application absolutely, positively must use data that is writable to all users, and you are prepared to inflict the resulting security violation onto your customers, then install the data files in a subfolder of the All Users Application Data folder and use our GiveAccess tool to change the permissions on your data files to allow access to Everyone (SID S-1-1-0). See How do I change the access permissions on a file or folder? for details.
Note that doing so will make your application ineligible for Windows Logo compliance.
(A better design is to create a separate program that runs as a service and regulates access to the writable data on behalf of all users, like a database server does. However, this requires a considerable amount of extra implementation effort.)
By setting its Registration: Use DllRegisterServer attribute. In most cases, the InstallMate Builder environment will already have set this attribute for you. And yes, this works for both 32-bit and 64-bit DLLs. (64-bit DLLs can only be registered successfully on a 64-bit Windows system, obviously.)
By creating a shortcut on the Files and Folders page, in one of the All Users or Current User subfolders. See Installing Shortcuts for details.
By creating a shortcut to <TinProductFolder>\Setup.exe with the /remove option on the Files and Folders page, in one of the All Users or Current User subfolders. See Installing Shortcuts for details.
By creating a shortcut to <TinProductFolder>\Setup.exe on the Files and Folders page, in one of the All Users or Current User subfolders. See Installing Shortcuts for details.
Note: We are referring to things like license registration or activation for your application, not to DLL registration.
By enabling this on the Product Registration page in your InstallMate project. This in turn displays the Registration information dialog box in the installer with fields for the user's name, company, and registration code.
By using an extension DLL and implementing handlers for the InitRegistration, CheckRegistration, and ApplyRegistration messages. Note that there are 3 distinct phases (initialization, checks on the user's input, and finally storing the registration info).
The C:\Program Files [(x86)]\ InstallMate 7\Tix folder on your system contains the source code for a complete extension DLL. You only need to edit the following functions in the TixHandlers.cpp file:
_TixOnInitRegistration() _TixOnCheckRegistration() _TixOnApplyRegistration()
In your implementation, you can use the iTixRuntime callback interface. Also check out the files TixUtils.h and TixUtils.cpp; these contains lots of helper functions that may be useful and only use the Win32 API.
After you have built your extension DLL (in 3 versions: ANSI/32, Unicode/32, and Unicode/x64; all predefined in the Visual Studio projects), you must add it to the installer on the Installer Options page, Advanced... options.