Migrated a Setup project from VS2008 to VS2010 and set RemovePreviousVersion=True so as to effect a Major Upgrade. The MajorUpgrade finishes with files being removed from the application folder.

Cause

Component GUID's are changed when setup projects are migrated from VS2008 to VS2010. InstallValidate marks components to be installed locally, RemoveExistingProducts that run at sequence 6550 ends up removing these components.

Resolution

* Manually change the component GUID's to be the same as that of VS2008 (this might not be a feasible solution)

* Resequence RemoveExistingProducts right after InstallInitialize (sequence number 1525). This ensures that older files are removed and reinstalled by the newer version.

Contributor  :  Ravi Shankar 

The application manifest is being built using mage.exe

After the application and deployment manifests have been built successfully application is attempted to be installed, it comes up with error

Error Message:

ERROR SUMMARY

                Below is a summary of the errors, details of these errors are listed later in the log.

                * Activation of https://NGIMSMOKECRMDB.parttest.extranettest.microsoft.com:555/NgimMsCrmClient/NgimMsCrmClient_DAILYBUILD.application resulted in exception. Following failure messages were detected:

                                + Deployment manifest is not semantically valid.

                                + Deployment manifest is missing <compatibleFrameworks>.

Solution:

GenerateDeploymentTask will need the TargetFramework attribute to be set.

This can be done by setting TargetFrameworkMoniker input parameter in GenerateDeploymentManifest to ".NETFramework,Version=v4.0"

An example of how this looks is as below.

<Project DefaultTargets="NgimCustomBuild" xmlns="https://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion ="4.0">

<GenerateDeploymentManifest 

      AssemblyName ="$(AppName).application"

      TrustUrlParameters="true"

… …

      TargetFrameworkVersion="v4.0"

      TargetFrameworkMoniker=".NETFramework,Version=v4.0"

… …

      ></GenerateDeploymentManifest>

Contributor  :  Ravi Shankar 

Bug in ClickOnce due to Registry reflection disabled in Win 7.

Programmatic updates with ClickOnce run under Wow64 on Win 7 X64 and cannot write the registry information for the file associations under the 64 bit registry nodes.

Bug not fixed yet, workarounds involve either disabling programmatic updates for Win 7 X64 and have users upgrade the application from the installation URL. OR Release a X64 build for X64 bit machines.

Contributor  :  Ravi Shankar 

Using VS Setup project to deploy an application that uses COM component. The COM component is being registered by setting vsdraCOM. When the application is installed on the target machine the registry codebase for the COM component is pointing to the sourcepath.

We first set the register property for the COM component to DoNotRegister. Used regasm from the Visual Studio 2005 command prompt with the following parameters.

Regasm.exe /regfile: /codebase

This would generate a reg file under the specified path. Now manually edit the reg file to replace the codebase information and change it to [TARGETDIR]

Save the reg file and do the following in Visual Studio Setup project.

Right Click On the setup project goto View and select Registry editor. Right Click on Registry on Target machine and select Import. Point to the modified reg file and rebuild the project.

Contributor  :  Ravi Shankar 

The property values are initialized to 1 in the property table. The Setup project builds the MSI with CustomActions in the InstallExecuteSequence that reset these property values to Null. Its only in the UI when the CheckBox dialog is created the actual property values are set. Therefore no matter what values we pass from the command line to the properties they are always getting reset to Null and never being set to the desired values.

The condition I had to use was CHECKBOXA1<>””

had to remove some entries from the InstallExecuteSequence and the Property tables. This I have done using a post build event as below.

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `InstallExecuteSequence` WHERE `InstallExecuteSequence`.`Action`='CustomCheckA_SetProperty_CHECKBOX1'"

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `InstallExecuteSequence` WHERE `InstallExecuteSequence`.`Action`='CustomCheckA_SetProperty_CHECKBOX2'"

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `InstallExecuteSequence` WHERE `InstallExecuteSequence`.`Action`='CustomCheckA_SetProperty_CHECKBOX3'"

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `InstallExecuteSequence` WHERE `InstallExecuteSequence`.`Action`='CustomCheckA_SetProperty_CHECKBOX4'"

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `Property` WHERE `Property`.`Property`='CHECKBOXA1'"

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `Property` WHERE `Property`.`Property`='CHECKBOXA2'"

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `Property` WHERE `Property`.`Property`='CHECKBOXA3'"

cscript //nologo "$(ProjectDir)WiRunSql.vbs" "$(BuiltOuputPath)" "DELETE FROM `Property` WHERE `Property`.`Property`='CHECKBOXA4'"

Contributor  :  Ravi Shankar 

Thanks,
Aditya Hari

After the installer has been built and the application installed. Launching the application brings up a series of Windows Installer resiliency that continues for a long time before the application is finally launched.

You are registering  your .Net components using the registry table by using regasm to import the registry keys manually into Visual Studio Setup project Registry editor.

Regasm is creating keys under HKCR\CLSID\{GUID}\Implemented Categories that have a null value (not even a default value).

The property "Always Create" for the registry keys is by default set to False. Since the HKCR\CLSID\{GUID}\Implemented Categories values are null they are not created during install.

When the application is launched, Windows installer spawns resiliency to find this registry key for each component being registered.

Resolution

Set the "Always Create" property for the NULL value registry keys to True.

Contributor  :  Ravi Shankar 

Upon uninstall the data files appear to be removed, however when a new version of the application is installed the older data files are still referenced by the application.

Due to file virtualization on Vista, when an application is launched as a standard user and if the application needs to write files into protected folders such as ProgramFiles it creates a VirtualStore under the Users Appdata folder.

The Virtual Store is not removed upon uninstallation of the application. This is by design.

The recommendation is to not write data files into ProgramFiles folder.

Please see More information section to read more about UAC dev requirements and File virtualization on Vista.

Resolution

* Do not use System Protected folders to install Data Files.

* [CommonAppDataFolder] may be used for such reasons.

CommonAppDataFolder resolves to the following locations on XP and Vista respectively.

<Root Drive>\Documents and Settings\All Users\Application Data

<Root Drive>\Program Data

More Information

New UAC Technologies for Windows Vista - https://msdn2.microsoft.com/en-us/library/bb756960.aspx

The Windows Vista UAC Dev Requirements document may be downloaded from - https://download.microsoft.com/download/5/6/a/56a0ed11-e073-42f9-932b-38acd478f46d/WindowsVistaUACDevReqs.doc

MSI built using WiX Installer consists of Actions that require elevation.

The CustomActions are not designed to run under SystemContext.

The installation/uninstallation will have to be done using an Admin command prompt. The uninstallation using Add/Remove Programs will not work due to it being not elevated.

WiX does not generate a bootrapper setup.exe that can be used with an embedded manifest to say RequestedExecutionLevel = "RequireAdministrator"

Also uninstallation using Add/Remove Programs will not run elevated and fails.

Resolution

Use the steps below to change the Uninstall registry key for the package you are installing such that Add/Remove programs will use a Custom Script (executed from an elevated command shell) to uninstall the product.

1.      Install your package on the system.

2.      Take a backup of the registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Your product}

3.      Uninstall your package.

4.      Set the ARPSYSTEMCOMPONENT property to 1 in property table within your package. For more information https://msdn.microsoft.com/en-us/library/aa367750(VS.85).aspx

5.      Import your backup registry keys to registry table within your msi package.

6.   In the registry table change the keys to a new guid  such as Software\Microsoft\Windows\CurrentVersion\Uninstall\{Add New GUID} and remove WindowsInstaller=1 from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Your product}

7.      Add elevate.vbs file in the msi package

To create Elevate.vbs

Set objSh = CreateObject("Shell.Application")

objSh.ShellExecute "msiexec.exe", "/x {Product Code}" , "", "runas", 1

8.      In the registry table modify the "UninstallString" value to cscript "[TARGETDIR]elevate.vbs"

Now try installing and uninstalling the Msi package. I attached one sample msi package called Scripting_Elevation_setup.txt (rename it to .msi) which runs with elevated privilege from ARP on Vista. Let me know how it goes.

NOTE: Its highly recommended to set all CustomActions requiring elevation with the TypeNoImpersonate bit such that they run with elevated privilages.

Vista is capable of requesting for elevation when it determines a need for that.

The above is only a workaround that was implemented for the customer since the original developer of the MSI was not available to troubleshoot.

More Information

Set No Impersonate to run Custom action on Vista

https://msdn.microsoft.com/en-us/library/aa368069(VS.85).aspx

Custom action on vista

https://blogs.msdn.com/heaths/archive/2006/09/26/Custom-Actions-under-UAC-in-Vista.aspx

Elevation through Script on Vista

https://blogs.msdn.com/aaron_margosis/archive/2007/07/01/scripting-elevation-on-vista.aspx

the Visual studio 2005 always complained the error message "Entry point ‘xxxxxx’ not found in module ‘xxxxxx’ for custom action ‘Primary Output from xxxx’ " and stopped the building.

-If you are using VS 2008. It will build the Application with couple of warning. But this application will fail during install again

Cause

This is a Limitation of Microsoft Visual studio 2005 - It cannot find correct entry point when You build Native Custom action dll.

It gives Error during Build

Limitation of VS 2008 - It passes the Build but still cannot find the entry point correctly. so custom action won’t be successful

Resolution

First you should use an MSI editor (such as Orca.exe) to look at your built MSI - you'll see a series of tables, like a database.

The "CustomAction" table contains all the custom actions in your MSI (some of these are built-in - not all rows here are your own custom actions). Look at the "Target" column - some rows will have a string here similar to this: "_FunctionName@4", where "FunctionName" is the name of the entrypoint of the DLL that this custom action will execute. This is case-sensitive, so don't forget to preserve case. You should update the "Target" column to be just the name of the entrypoint you expect, without the "_" or the "@4". So as an example, you would change "_Install@4" to "Install".

Once you have learned to alter the MSI the way you want it with Orca (and tested installing it), you can create a post build script which will modify your MSI using SQL statements, so that the custom actions will be re-prioritized for you automatically each time you build it