Miscellaneous Frequently Asked Questions

Please note that the import features in Advanced Installer (the Repackager, the Import MSI feature etc.) are intended to be used to get a starting point for your installation package, not to completely reproduce other installation packages. The Repackager tool captures only the effects of the installation (the changes made on the system). If the original installation package executes custom code (programs, scripts etc.) then only the effect will be captured (registry entries, files and folders etc.). Also, after repackaging an installation some adjustments may be necessary in order to obtain a working installation package.

When repackaging in Hyper-V machines the process could hang on waiting for the Advanced Installer tools (osprovision) to get installed. This usually happens because autorun is disabled by default on Hyper-V machines.

To get past this issue you can browse to This PC / My Computer and double click the Advanced Installer tools image that gets mounted automatically. Another way is to copy and install osprovision.exe from the following location, then save the snapshot:

C:\Program Files (x86)\Caphyon\Advanced Installer 13.0\bin

Once the tools are installed the repackaging process can continue.

This could happen when the setup to be repackaged resides on a drive root of the host machine. Due to a limitation in the our Repackager's design, it cannot handle this situation. As a workaround you could move the setup in a subfolder of the drive root.

Another posible cause of this error could be if the Integration Servicesare disabled on the guest virtual machine. Please make sure these services are enabled. The "Data Exchange" and "Heartbeat" services are especially important.

Organization view uses a native TREE control that does not support multiple components selection.

However, a workaround to select multiple components in the Organization view is the following:

• Select a component.
• From the context menu, use the Add to list OR press F4. This will add the component to a list that appears under tree, at the bottom of the page. Repeat this step for every desired component.
• On the bottom view is the list where components were added. From the context menu options you can select the common properties for those components.

During an uninstall, Windows Installer removes only the data registered into the MSI file. All other data created by custom actions, by the installed application or by the user is not registered in the MSI, therefore it will not be removed. If you want to also delete this data, you need to use the "Uninstall Cleanup" wizard available from the context menu when a folder is selected in the Files and Folders Page.

When launching an installation, Windows Installer calculates the space required by adding the size of the resources which will be installed with the size needed for rollback. Also, some space is required for the installation script and for the cached package. Additionally, the installation runs from a temporary copy of the package, therefore more space is required. Basically, an installation requires much more space than just the size of the files it creates.

An installation will require a reboot if it tries to overwrite a file which is in use. After a reboot is performed, the file will no longer be used and Windows will be able to overwrite it. Windows Installer may also require a reboot if this is explicitly requested by the package through the REBOOT property.

One of the features offered by Windows Installer is self-healing for the installed application. Therefore, if Windows Installer detects there is an important resource missing, it will automatically repair the installation and show a progress bar.

The progress bar may also be showed by an on-demand installation. This is usually caused by an Advertised shortcut.

A log of the installation can be created by using the /L*V parameters when launching the MSI through the Msiexec command line. For more details please see the Create a log How-To or the Write a specific Event in the log How-To.

Sometimes a package cannot be uninstalled (for example, it contains a custom action which cannot run). This broken package can be removed by following these steps:

• open the package's Advanced Installer project
• fix the problem
• build the project
• use this command to recache the MSI:

msiexec /fv <path_to_new_msi>

Note that in the above command you need to specify the modified MSI's actual path.

After the modified MSI replaces the cached one, you can run the uninstall again.

Microsoft has also automatized most common uninstall problems into the Fix it program.

Another deprecated way of repairing a broken installation is by using the Windows Installer Cleanup utility or the "MsiZap.exe" tool from the Windows SDK. Note that these tools remove only the Windows Installer information for the package, the installed resources must be manually removed.

Microsoft has removed Windows Installer Cleanup utility and "MsiZap.exe" tool from the recent versions of the SDK.

The EULA can be very easily displayed using our predefined dialog "LicenseAgreementDlg". All you have to do is add it to the installation dialogs from the Dialogs page. Here are the steps to do that:

• go to Dialog Editor page and right click in the "First Time Install" tree
• from the context menu select option "Add Dialog..."
• select "LicenseAgreementDlg" from the available dialogs list
• now that you added the dialog, you just have to set the according .RTF file that will be displayed during installation

Please note that you should use a valid .RTF file, not just a simple file to which you have changed the extension to .RTF.

After following the above steps you should have a new dialog displayed in the installation sequence containing the text specified by your file.

The Windows Installer engine does not support mixed 32/64-bit packages. However, we implemented this feature in Advanced Installer by using the EXE bootstrapper. Therefore, a mixed 32/64-bit package will work as expected only when it is used through the EXE file.

When a package is installed, Windows caches the MSI by placing it in the Windows\installer folder. During this process, all the unnecessary information is removed in order to decrease the size of the file. When a Repair is called, some data required may not be found in the cached MSI. In this case, Windows Installer will prompt the user for the original package in order to retrieve the data it needs.

To trigger a self-healing, an Advertised Shortcut must be present in the MSI. If an Advertised Shortcut is present in a feature, during the first launch, it checks all the key paths for the current feature and all its subfeatures. However, if the MSI contains multiple features, this does not check the missing key paths in other features, only the feature of which the Advertised shortcut is launched.

By default, the paths used in an Advanced Installer project are relative to the project file. Therefore, when you move the project file you also need to make sure you move the files used in the project in order to maintain the relative paths.

The type of the paths (relative or absolute) can be changed in the Project Settings tab of the "Edit Project Settings" dialog. You can get to this dialog by using the "Project" -> "Options" menu in Advanced Installer. Note that you can also use path variables instead of relative paths.

Advanced Installer allows you to create or modify registry entries through the Registry page. When you create a new registry value, you can specify [ProductVersion] in the Data section of the Edit Registry Entry dialog. This way, the registry entry will contain the version of the package.

• "Shortcut Target field - The Target entry of the Shortcut table must be a valid feature name/foreign key (Identifier data type) in the Feature table."
  The solution for this error is to enable the "Advertised shortcut" option from the shortcut's properties dialog. You can access this dialog from the shortcut's context menu or by double-clicking it in the Files and Folders page.

The information displayed on the security dialog is collected from the digital signature of the package. In this particular case if you set the “Description” field from the Sign EXE, MSI or MSP files with a digital signature it'll display the correct package name.

This is useful when setting a folder's permissions for example. It is known that in Windows Installer only Everyone and Administrators are the same for all languages and all other account names should be localized.

Advanced Installer automatically performs the localizations when using one of the following "Users and Groups" properties:

• USR_ANONYMOUS
• USR_GUEST
• USR_ADMINISTRATOR
• USR_KEY_DISTR_CENTER_SERVICE
• USR_NETWORK_SERVICE
• GRP_GUESTS
• GRP_USERS
• GRP_AUTHENTICATED_USERS
• GRP_POWER_USERS
• GRP_LOGGING_USERS
• GRP_MONITORING_USERS
• GRP_REMOTE_DESKTOP_USERS
• GRP_DOMAIN_USERS
• GRP_DOMAIN_COMPUTERS
• GRP_DOMAIN_CONTROLLERS
• GRP_RID_INCOMING_FOREST_TRUST_BUILDERS
• GRP_REPLICATOR
• GRP_RAS_SERVERS
• GRP_PREW2KCOMPACCESS
• GRP_NETWORK_CONFIGURATION_OPS
• GRP_ACCOUNT_OPS
• GRP_SERVER_OPS
• GRP_PRINT_OPS
• GRP_BACKUP_OPS

You can experience this behavior when using multilingual packages.

The solution is to set the same ProductCode for all languages from the Product IDs Tab.

This is a widely used approach and can be achieved by enabling Use a single "Uninstall/Change" button instead of separate buttons for each operation option in the Product Details Tab from Product Details page.

The modifications to the environment variables do not result in an immediate change. The list of environment variables is loaded when the process is initialized but not refreshed. To have the newly created environment variable, you can have a custom action that forces a refresh of the environment variables. You need to broadcast a settings change message to all windows in the system so that any interested application can perform an update.

To solve the issue create a custom action that contains the code below which forces the operating system to refresh the environment variables.

SendMessage (HWND_BROADCAST, WM_SETTINGCHANGE, 0, (LPARAM)"Environment")

This may happen if you set by default the installation behavior of your feature to Disabled. As a workaround solution you can set it to Not Installed.

A feature will be installed if at install time its install conditions are evaluated to true. At install time the feature install conditions are evaluated during the "CostFinalize" standard action, before the installation UI appears. During this standard action the feature state (Installed, Not Installed or Disabled) is set accordingly with its condition evaluation. Afterwards if the evaluation of the feature condition changes, for instance during installation UI, Advanced Installer uses its own custom action (Update Features Install States) to update the feature state accordingly with its new condition evaluation.

Unfortunately, due to a limitation of the Windows Installer API our custom action cannot update the state of a feature whose state was originally set to Disabled. This is not allowed by Windows Installer. So, the only workaround to avoid this limitation would be to set by default your feature installation behavior to Not Installed.

This behaviour may occur when running on Windows Vista or above with User Account Control enabled and you try to access a network drive from an elevated process. The problem occurs because User Account Control treats members of the Administrators group as standard users.

For details, please check the Programs may be unable to access network locations in Windows Vista or newer operating systems.

Depending on what type of virtual machine you are using, there are multiple scenarios on why you receive this.

On HyperV and vSphere:

• The host and virtual machine must be on the same subnet
• The connection must be trough IPv4. We do not support IPv6
• Some devices like routers/switches (even if they are virtualized) or firewall might prevent the communication between the host machine and virtual machine

On VMWare Workstation, we establish a connection with the virtual machine using VMCI sockets. However, there might be cases where, for example, a Windows update corrupts the VMCI driver and thus the connection fails. In our latest Advanced Installer releases, we automatically detect if a VMCI connection could not be made and attempt a TCP/IP connection as we do for HyperV and vSphere.

This usually happens when the lightweight edition of Visual Studio 15 release preview is installed. The extension requires features from the full edition to work as expected.

You may receive the Failed to open the solution file [...]. Invalid file format error message during the import of a Visual Studio solution if you are using the Express edition of Visual Studio. In the Express edition of Visual Studio some features that are required to import a solution are missing, thus the import operation fails.

The issue appears when trying to install/configure a different product or build a setup project after installing Visual Studio as a prerequisite.

This issue might also trigger Visual Studio to begin a repair operation that hangs and because Windows Installer allows only one operation at a time any other installations are blocked.

There are cases where, if you use merge modules in your setup project and have Visual Studio installed on your machine, upon built, a Visual Studio repair operation is triggered. Sometimes the repair operation might fail, and the build operation of your project will not finish.

To check the exact cause of your problem, follow the steps below.

1. Open Event Viewer
2. Expand Windows Logs and click Application
3. Check Warning
4. Write MsiInstaller in the Event sources
5. Write 1004 in event IDs
6. Click OK

The warning should state that a resource/folder does not exist. Example: The resource 'C:\Windows\Microsoft.NET\Framework\URTInstallPath_GAC\' does not exist.

This means that the installer is looking for the above path and cannot find/create it.

The path may differ according to the Visual Studio version you have on your machine.

To fix this issue, you must create the missing resource/folder at the mentioned path.

To learn more about this issue see Microsoft's blog post.

This can happen when using Advanced Installer special properties in your condition. These properties usually have AI_ prefix and some of them only get resolved when referenced from a Smart Condition Edit Control.

The workaround for this limitation is to use the properties in a condition field which is a smart condition control. For instance you can create a dummy custom launch condition that will never trigger.

Just go to "Launch Conditions" page -> "Custom" tab and add a new launch condition like this:

• Condition: (AI_DETECTED_MINOR_UPGRADE) OR (1=1)
• Description: Dummy launch condition used to resolve the AI_DETECTED_MINOR_UPGRADE property. This launch condition will never be triggered.

To integrate Advanced Installer into Azure DevOps Server (TFS) Server, follow the steps below:

1. Have a Visual Studio Online account
2. Deploy an agent on Windows
3. Install Advanced Installer Visual Studio Plugin on your host agent
4. Install Advanced Installer Tool Installer on your host agent
5. Configure the build process similar to how is shown in the 'How to use' section

Excel-DNA is a project that integrates .NET into Excel. To easily distribute this type of project, for example a Microsoft Excel Add-on, check out the following article about how to use Advanced Installer for an Excel-DNA project.

This message is a standard HTTP response with the code 403. For details, check the HTTP Status Codes article.

Basically, the permissions on your server prevent the Updater from accessing it. Make sure that the URLs you are using work in Internet Explorer on a clean machine.

To learn how to fix this issue see our article about false positive virus detection.

Starting with Advanced Installer 15.4 the Windows Mobile CAB project type has been removed from the Windows Store section.

To create a Windows Mobile CAB project you have two options:

1. Install an Advanced Installer version before 15.4 to create the project
2. For Advanced Installer version 15.4 or newer, you can create the project via command-line

AdvancedInstaller.com /newproject "WinCE_CMD.aip" -type "win-ce"

After you create the project via command-line, you can open it in Advanced Installer and start editing.

When using Enhanced User Interface, the REBOOT property should be set only during "Wizard Dialogs Stage" (i.e. before "Paths Resolution" actions group).

In order for your setup to support UNICODE characters, you have to enable “UTF-8 encoding” option from the “Database Encoding” section in Builds Page

This option should be enabled, when you need to use strings containing UNICODE characters in File Removal operations, Text File Updates or XML files handled by Advanced Installer, etc.

Using different Product codes for each language of a multilingual package could trigger some issues.

Most frequently encountered issues for this scenario are:

1. If the setup is installed in a language different than the default project language running the setup a second time after installation does not trigger maintenance mode in the selected language as expected. Instead, the package runs like a first-time installation in default project language.
2. In certain scenarios "This package can only be run from a bootstrapper" error message is displayed when the user tries to uninstall the package from Control Panel using the “Change” button.

In order to overcome these problems, we recommend using the same product code for each language of your package. To achieve this, go to Project->Options->Project IDs and set the same ProductCode for all the languages of the project

When installing a self-hosted agent as a service, it runs by default under the NetworkService account. Make sure you switch it to run under a regular user account.

There are two Advanced Installer extensions for Azure DevOps : Advanced Installer Build and Advanced Installer Tool.

Advanced Installer Tool downloads, installs and registers a specified version of the Advanced Installer on the Azure Devops build environment. This should be used,for example, if you need to build a Visual Studio solution that contains an .AIP project.

Advanced Installer Build downloads, installs,registers a specified version of the Advanced Installer and triggers an Addanced Installer build on the Azure Devops build environment. This should be used if you need to build a stand alone .AIP project in Azure DevOps environment.

In rare situations the icon assigned to a shortcut suddenly disappears. This issue might be triggered by a Windows Installer cache issue. The icons cache is entirely handled by Windows. In order to recover the icon you need to trigger a repair for the package containing the shortcut in question.

Make sure "Enable Controlled folder access" policy settings is disabled. This blocks the installation of all the MSI packages that contain a desktop shortcut.

Yes. Please contact our customer suppport team for details at support@advancedinstaller.com.

Yes. This can be done by navigating first to Launch Conditions under Requirements on the left pane. In the System tab under System Requirements, check box Prevent running if pending system changes that require a reboot are detected.

In some situations, for example when using batch files to automate the build process, the path of the latest version of Advanced Installer should be extracted from the registry.

There are two registry values that are set by Advanced Installer at install/uninstall:

• InstallRoot - which contains the path of the latest version of Advanced Installer present on the machine, for example: "C:\Program Files (x86)\Caphyon\Advanced Installer 16.7\"
• Version - which contains the latest version of Advanced Installer present on the machine, for example: "16.7"

These two values are located in the following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Caphyon\Advanced Installer]

The full path of AdvancedInstaller.com command line tool can be computed like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Caphyon\AdvancedInstaller\InstallRoot] + "bin\x86\AdvancedInstaller.com"

This problem could be caused by the fact that when you use Other Servers option from Edit VM Profiles, the Repackager will copy the whole content of the folder that contains the package to be repackaged.

It is recommended to place the package and its dependencies in an empty folder before starting the repackaging.

Yes, Advanced Installer can run in Docker environment.

You can install using a silent install command line:

msiexec /i advinst.msi /qn

and register it using a command line like this:

AdvancedInstaller.com /register <license_id>

Yes, but only when the legacy setup you need to repackage can run completely silent.

Yes, all setup packages built with Advanced Installer can be installed and run in Docker. You should just use a silent command line to install them.

You can achieve this by going to IIS Web Site Browse, click on the Add button from the Data Output section and choose Web Site Certificates type. Then select a property to store the output.

At run time, after the IIS Browse operation is executed, if the selected IIS Website has an SSL certificate, the above property will be set.

Usually, this error occurs when moving the project to a different machine. The error may occur when the output build location or the cache project point to an invalid location. Check the location of the output build in the Builds view or the location of the cache folder from the Project Options to make sure their paths are valid.