Windows Installer MSI & Clickonce issues

An error occurred while signing: Key not valid for use in specified state

Soumitra Mondal — Wed, 09 May 2012 16:03:00 GMT

When a user tries to publish a ClickOnce application after changing the user account password, it would fail with one of below error messages:

“Cannot publish because a project failed to build.”
“An error occurred while signing: Key not valid for use in specified state.”
“Error msb3482 an error occurred while signing key not valid for use in specified state” Ex. http://msdn.microsoft.com/en-us/library/ms228227(v=vs.90).aspx

Please find the below steps to reproduce the issue:

1. Create a simple Windows Form application in Visual Studio.
2. Without changing any properties of the application, right click the project file and “publish” the application.
(A test certificate is automatically created by Visual Studio and stored under the project folder. )
3. Change the password of the local user account.
4. Logoff from the computer and login back to the computer using the same user account.
5. Open the same project that was created in step1, and without changing any properties of the application, right click the project file and “publish” the application.
6. The above error would occur.

Resolution:

The above issue occurs due to ClickOnce application was not signed with the certificate after re-logging to the system using new user account password. In order to resolve the issue just re-sign the application after re-logging. For example, first time you sign the app using this certificate and publish it. Then change the password for the current user and log off/re-login to the system. Now sign the app again with the same certificate and publish the application. You should be able to publish the application successfully.

"Reference in the manifest does not match the identity of the downloaded assembly"

Soumitra Mondal — Wed, 29 Feb 2012 22:09:04 GMT

You may find the below error message while launching a ClickOnce application: “Reference in the manifest does not match the identity of the downloaded assembly MyApp.exe.”

Log snippet:

ERROR SUMMARY
Below is a summary of the errors, details of these errors are listed later in the log.
* Activation of \\MyServer\MyApp.application resulted in exception. Following failure messages were detected:
+ Reference in the manifest does not match the identity of the downloaded assembly WinApp.exe.

Following errors were detected during this operation.
* [28-Feb-12 10:53:06 AM]

System.Deployment.Application.InvalidDeploymentException (RefDefValidation)
- Reference in the manifest does not match the identity of the downloaded assembly WinApp.exe.
- Source: System.Deployment

Stack trace:
   at System.Deployment.Application.DownloadManager.ProcessDownloadedFile(Object sender, DownloadEventArgs e)
   at System.Deployment.Application.FileDownloader.DownloadModifiedEventHandler.Invoke(Object sender, DownloadEventArgs e)
   at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem next)
   at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
   at System.Deployment.Application.FileDownloader.Download(SubscriptionState subState)
   at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState, AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String targetDirectory, String group, IDownloadNotification notification, DownloadOptions options)
   at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState, ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp)
   at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState, ActivationDescription actDesc)
   at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
   at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

After investigating this issue, I found that this issue occurs due to a manifest being embedded into the executable while building the application. On Visual Studio 2008 onwards, by default it embeds manifest information into assemblies. Hence, the resolution is to include /nowin32manifest switch http://msdn.microsoft.com/en-us/library/bb513864.aspx while building your application. Another approach would be to exclude the embedded manifest file after building the application. In order to do that please open Visual Studio IDE and Open the executable file from the menu (File—>Open—>File). You will find the below screenshot:

Now delete RT_MANIFEST and save the executable file.

Removal of a component from a feature is not supported

Soumitra Mondal — Tue, 27 Dec 2011 18:04:40 GMT

You might observe that files are not being upgraded after applying a small update or a minor upgrade patch. The upgrade log may not show the exact cause of the issue. After investigation, I found some component rule violation in the upgrade package.

To catch the violation to the upgrade component rules you can pass the public property MSIENFORCEUPGRADECOMPONENTRULES (http://msdn.microsoft.com/en-us/library/Aa370093) that will affect any install on the machine. This will cause small and minor updates to fail with either Windows Installer error 2771 if a component is removed from a feature, or error 2772 if the feature tree is rearranged with the exception of adding a new feature as a leaf feature to an existing feature.

For example first install the Target MSI package then run the below command:
msiexec /fvomus Your_Upgrade_Package.msi REINSTALL=ALL REINSTALLMODE=vomus MSIENFORCEUPGRADECOMPONENTRULES=1 /l*vx log.txt

The above command-line tells MSI to update the cached MSI to start the minor upgrade then do a reinstall to actually replace newer files and registry keys. The MSIENFORCEUPGRADECOMPONENTRULES Property will cause the minor upgrade to fail if you violated any of the minor upgrade rules. The log file (log.txt) would show the cause of the issue.

■Remove a component from a feature.
This can also occur if you change the GUID of a component. The component identified by the original GUID appears to be removed and the component as identified by the new GUID appears as a new component.

■Add a new feature to the top or middle of an existing feature tree.
The new feature must be added as a new leaf feature to an existing feature tree.

In the log (log.txt), I found the following information:

MSI (c) (B7:C0) [10:00:00:000]: SELMGR: ComponentId '{1F634567-89CD-ADEF-8179-D4A709CF0DBC}' is registered to feature 'FeatureA', but is not present in the Component table. Removal of components from a feature is not supported!
MSI (c) (B7:C0) [110:00:00:000]: SELMGR: Removal of a component from a feature is not supported

Please note that components can be added to new features - or existing features - but cannot be removed. In order to remove the component or make a change that would otherwise require a change in the component code - which is no different than removing one component and adding another - the ProductCode property must be changed, which constitutes a major upgrade. This applies even with obsolescence and supersedence. If we recall How Patching Works http://blogs.msdn.com/b/heaths/archive/2005/09/12/464047.aspx that when we obsolesce or supersede a previous patch Windows Installer removes the patch transform from the in-memory view of the product. This effectively removes a component from a feature or features and violates upgrade components rules.

As per the MSDN doc http://msdn.microsoft.com/en-us/library/Aa367850 the product code must be changed if any of the following are true for the update:

•Coexisting installations of both original and updated products on the same system must be possible.
•The name of the .msi file has been changed.
•The component code of an existing component has changed.
•A component is removed from an existing feature.
•An existing feature has been made into a child of an existing feature.
•An existing child feature has been removed from its parent feature.

In order to resolve the issue, try one of the steps:
• Don’t remove the component from the existing feature in the upgrade package
• Change the product Code in the upgrade package which would be a major upgrade.

An error occurred while signing: SignTool.exe not found.

Soumitra Mondal — Mon, 28 Nov 2011 17:33:00 GMT

While publishing a ClickOnce application using Visual Studio 2010, it may fail with the following error message:

Error 1 Cannot publish because a project failed to build.
Error 2 An error occurred while signing: SignTool.exe not found.

Build output:

Building WindowsFormsApplication...
Error: Cannot publish because a project failed to build.

The signtool.exe is located at the following location:

%programfiles(x86)%\Microsoft SDKs\Windows\v7.0A\Bin for x64 system

%programfiles%\Microsoft SDKs\Windows\v7.0A\Bin for x86 system

Please make sure that the file is available there. Signtool.exe is part of the windows platform SDK. If the file is not present on the system, please install/repair windows platform SDK OR copy the file from a working system.

Now try to publish the ClickOnce application. If you still find the same issue, please check if you installed the Microsoft .NET Framework 4.5 Developer Preview on the system. The Microsoft .NET Framework 4.5 Developer Preview is a prerelease version of the .NET Framework, and should not be used in production scenarios. It is an in-place update to the .NET Framework 4. You would need to uninstall this prerelease product from ARP.

After uninstall please reboot the system and install the .Net Framework 4.0 RTM. It can be downloaded from the following link also: http://www.microsoft.com/download/en/details.aspx?id=17718
Then launch Visual Studio 2010 and publish the ClickOnce Application.

“Current thread must be set to single thread apartment (STA) mode before OLE calls can be made”

Soumitra Mondal — Mon, 06 Dec 2010 18:05:00 GMT

While calling a OpenFileDialog (http://msdn.microsoft.com/en-us/library/system.windows.forms.openfiledialog.aspx) via Installer class as a Custom Action in the Visual Studio Setup project, it just hangs there.

When we attach a debugger we receive an error: "Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it. This exception is only raised if a debugger is attached to the process."

The same code works fine on Win XP and 2003. It only occurs on Win Vista and higher version of Operating Systems

The sample code is mentioned below:

MessageBox.Show("Cannot Locate Config File");

MessageBox.Show("Pid : " + System.Diagnostics.Process.GetCurrentProcess().Id.ToString());

String Location = String.Empty;

OpenFileDialog frm = new OpenFileDialog();

frm.InitializeLifetimeService();

frm.Filter = "Config Files (*.config)|*.config| (*.xml)|*.xml";

frm.Title = "Browse Config file";

DialogResult ret = frm.ShowDialog();

if (ret == DialogResult.OK)

Location = frm.FileName;

InitializeComponent();

The problem is that the MSI thread is running as an MTA thread, but the FileDialog.ShowDialog requires an STA thread. To achieve this you will need to start a STA background thread and call the dialog from that thread. Basically I did the following:

- Added the DialogState class. This keeps track of the input and output for the thread.

- Added the STAShowDialog function. This function takes a FileDialog, calls ShowDialog on a background STA thread, and then returns the results.

- Changed the call from DialogResult ret = frm.ShowDialog(); to DialogResult ret = STAShowDialog(frm);

You may need to add exception handling separately.

Here is the complete code:

using System;

using System.Collections;

using System.Collections.Generic;

using System.ComponentModel;

using System.Configuration.Install;

using System.Linq;

using System.Windows.Forms;

namespace WindowsFormsApplication1

{

[RunInstaller(true)]

public partial class Installer1 : Installer

{

public Installer1()

{

MessageBox.Show("Cannot Locate Config File");

MessageBox.Show("Pid : " + System.Diagnostics.Process.GetCurrentProcess().Id.ToString());

String Location = String.Empty;

OpenFileDialog frm = new OpenFileDialog();

frm.InitializeLifetimeService();

frm.Filter = "Config Files (*.config)|*.config| (*.xml)|*.xml";

frm.Title = "Browse Config file";

DialogResult ret = STAShowDialog(frm);

if (ret == DialogResult.OK)

Location = frm.FileName;

MessageBox.Show(Location);

InitializeComponent();

}

/* STAShowDialog takes a FileDialog and shows it on a background STA thread and returns the results.

* Usage:

* OpenFileDialog d = new OpenFileDialog();

* DialogResult ret = STAShowDialog(d);

* if (ret == DialogResult.OK)

* MessageBox.Show(d.FileName);

private DialogResult STAShowDialog(FileDialog dialog)

{

DialogState state = new DialogState();

state.dialog = dialog;

System.Threading.Thread t = new System.Threading.Thread(state.ThreadProcShowDialog);

t.SetApartmentState(System.Threading.ApartmentState.STA);

t.Start();

t.Join();

return state.result;

}

/* Helper class to hold state and return value in order to call FileDialog.ShowDialog on a background thread.

* Usage:

* DialogState state = new DialogState();

* state.dialog = // <any class that derives from FileDialog>

* System.Threading.Thread t = new System.Threading.Thread(state.ThreadProcShowDialog);

* t.SetApartmentState(System.Threading.ApartmentState.STA);

* t.Start();

* t.Join();

* return state.result;

public class DialogState

{

public DialogResult result;

public FileDialog dialog;

public void ThreadProcShowDialog()

{

result = dialog.ShowDialog();

}

VS2010 Setup project - Migration from VS2008 does not work with Upgrades

Soumitra Mondal — Tue, 03 Aug 2010 20:25:39 GMT

Symptom

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

ClickOnce - .net 4.0 errors: "Deployment manifest is not semantically valid" and "Deployment manifest is missing "

Soumitra Mondal — Tue, 03 Aug 2010 20:22:59 GMT

Team Build 2010 is being used to build the deployment manifest for a .Net 4.0 application to be deployed via ClickOnce.

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.

<GenerateDeploymentManifest

AssemblyName ="$(AppName).application"

TrustUrlParameters="true"

… …

TargetFrameworkVersion="v4.0"

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

… …

></GenerateDeploymentManifest>

Contributor : Ravi Shankar

ClickOnce - File accociations are lost upon progrmmatic updates to ClickOnce on Win 7 X64

Soumitra Mondal — Tue, 03 Aug 2010 20:20:35 GMT

File associations created for ClickOnce applications are lost only on Win 7 X64 bit machines upon a programmatic update.

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

VS Setup project - vsdraCOM sets codebase in registry to point to the SourcePath

Soumitra Mondal — Tue, 03 Aug 2010 20:17:45 GMT

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

VS Setup project - Pass Checkbox properties as arguments to MSI during silient installations

Soumitra Mondal — Tue, 03 Aug 2010 19:55:00 GMT

Checkboxes are used in Install UI to select what files need to be installed. This works fine when installing in full UI. During silent installation via the command line, the property cannot be set as arguments to msiexec.

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

ClickOnce -- TargetFrameworkVersion

Aditya Hari — Mon, 21 Jun 2010 18:00:00 GMT

Issue:

===============

Though the ClickOnce application is set to ToolsVersion="3.5" and the TargetFrameworkVersion is v.3.5 we see that when building with TFS 2010 the manifest includes the following dependency

</dependentAssembly>

</dependency>

By including the above dependency we are making .NET Framework 4.0 as a mandatory prerequisite for our application, which is incorrect.

This is because TFS 2010 build installs MSBUILD 4.0

How to repro this:

====================

1. Create a windows app using VS 2008 targeting .NET Framework 2.0

2. Make sure we set the publish properties correct in the publish properties page of the VS 2008.

3. Also, sign the clickonce manifests using a test cert.

4. Make sure we save the project without building.

Now proceed to the next steps:

1. Launch the VS 2010 command prompt and use the 4.0 msbuild to build and publish the same app after clearing the publish file created in the TEST A.

msbuild /target:publish "projectname.vbproj"

2. Once the publish is success, look at the publish folder for the application manifest and in the app manifest we could find the following.

Workarounds to fix the above problem:

===================

1. Use c:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe to publish your project. This should always work.

2. Set <Project ToolsVersion="3.5" to <Project ToolsVersion="4.0" in your *.csproj or *.vbproj file. and Publish using c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe.

If the above are not an option, then you could try the following too:

Change the following lines in the TFSBuild.proj

From:

To:

Thanks,
Aditya Hari

Windows Installer 4.0 - MSI that installs data files under System Protected folders does not remove files upon uninstall.

Gauravb — Mon, 21 Dec 2009 21:54:00 GMT

Installing data files (.mdb) into System Protected folders (Program Files, System32 etc..) on Windows Vista machines as Standard user.

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 - http://msdn2.microsoft.com/en-us/library/bb756960.aspx

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

Contributor : Ravi Shankar

MSI: Unable to elevate an uninstallation via ARP in Vista

Gauravb — Mon, 21 Dec 2009 21:49:00 GMT

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 http://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

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

Custom action on vista

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

Elevation through Script on Vista

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

Contributor : Ravi Shankar

Native Custom action dll fails to build on x64

Gauravb — Mon, 21 Dec 2009 21:45:00 GMT

when you changed the build environment from Win32 to x64 and tried to build the setup project Its giving Error

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

Contributor : Ravi Shankar

Per-User installation of an MSI as standard user on Vista is installing files into Administrators profile

Gauravb — Mon, 21 Dec 2009 21:40:00 GMT

Files are being installed into the Administrators Profile rather than to the Standard Users profile.

This does not appear to be the default behavior for an Admin assisted installation as per documentation on http://msdn2.microsoft.com/en-us/bb384154.aspx

"Windows Vista built-in installer detection prompts for consent when you run under UAC. A bootstrapper (Setup.exe) built with Visual Studio 2005 always prompts for consent, regardless of what it is installing. Because Setup.exe and all of its processes run with an administrator token on Windows Vista, the final application installation will be installed with elevated privileges. If a user runs Setup.exe with administrator-assisted elevation, the application will be installed under the elevated user's profile (not the administrator's profile)"

The setup.exe was embedded with a UAC manifest that had RequestedExecutionLevel = RequireAdministrator.

The Admin Assisted Installation feature is over-ridden due to this. There will be a prompt for elevation even before the MSI is launched by setup.exe

Changed the RequestedExecutionLevel = AsInvoker.

This caused the setup.exe to launch the MSI AsInvoker to begin with. Elevation prompt was seen only when there was a need to elevate, this caused Admin Assisted Installation to work correctly.

More Information

Documentation on http://msdn2.microsoft.com/en-us/bb384154.aspx

This document should be studied carefully before building MSI packages that use the Admin Assisted Installation feature.

Contributor : Ravi Shankar

MSI: About the Uninstall Registry Key, WindowsInstaller Value

Gauravb — Mon, 21 Dec 2009 21:09:00 GMT

MSI packages built using Visual Studio Setup and Deployment project create the following registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<Product Guid>\WindowsInstaller.

There is no official Microsoft documentation for this registry key but the result of changing its value are as follows :-

If the "WindowsInstaller" registry entry is "1", the uninstall program set in the ProgramPath of the "UninstallString" entry did not work.

However, when the "WindowsInstaller" registry entry is "0", the uninstall program set in the program path of the "UninstallString" entry worked as expected.

Setting the WindowsInstaller Registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<Product Guid>\ will let you use your own UninstallString to uninstall the application via Add/Remove Programs

List of all properties under the Uninstall Key are documented on http://msdn.microsoft.com/en-us/library/aa372105(VS.85).aspx

Contributor : Ravi Shankar

How to make ClickOnce work over SSL requiring client certificates

Gauravb — Mon, 21 Dec 2009 21:04:00 GMT

Current feature limitations of Clickonce does not provide for security over internet by design.

It does work over SSL with server certificates which provides a mechanism to let users know that the application is coming from a trusted publisher. However, it you want to secure your application itself to a limited set of users you will need to setup the web server to "Require Client certificates" over SSL.

Clickonce is known to not work when the Web Server is set to "Require Client Certificates".

When Internet Explorer encounters a Clickonce deployment manifest (.application file) it calls something like rundll32.exe dfshim.dll, ShOpenVerbApplication applicationname.application

A process by the name dfsvc.exe is started in further reading from the Application manifest (.exe.manifest file) and downloading the files from the server into the Clickonce application cache.

dfsvc is not able to handle any prompt for authentication during this process and setting up the Web Server to "Require Client Certificates" causes a prompt to the user to select an installed client certificate from the users certificate store. Therefore deployment fails with an error "The remote server returned an error: (403) Forbidden"

IIS can be configured to "Require Client Certificates" at the Website level, Virtual Directory level and the file level.

Setting up IIS to require client certificates at the website, virtual directory and the publish.htm level but not on the .application file and the rest of the files in the publish directory will cause a prompt for certificate when you hit the publish.htm file but not when the .application file is processed.

Clickonce should successfully deploy with this setting. Security is ensured since users will need a valid Client certificate installed to enter the Publish.htm page.

More Information

NOTE: One caveat to this solution is that users will still be able to directly launch the application from the .application file provided the URL is made known to them. But the URL can only be known after getting prompted for certificate to hit the Publish.htm page

Contributor : Ravi Shankar

How to build an MSI to deploy ActiveX control

Gauravb — Mon, 21 Dec 2009 21:02:00 GMT

1. Create a new Setup and Deployment Project in Visual Studio.

2. Include the ocx files in the Project using the “File System Editor” as in

http://msdn2.microsoft.com/en-us/library/4ddxk2ye(VS.80).aspx

It’s better to have the files in system32 folder.

3. Go to the launch conditions editor and create a new File search to search for

the files regsvr32.exe and rundll32.exe under system32

http://msdn2.microsoft.com/en-us/library/0x2fc4kd(VS.71).aspx

The Property that will be set in the Launch Conditions editor will be used in the MSI package to go

the registration of the ocx files.

4. Build the setup Project.

5. The rest of the steps are to be done using a Platform SDK tool called ORCA. This

tool can be installed from the folder “C:\Program Files\Microsoft Platform SDK\Bin”

after installing the Platform SDK from the link

6. Once we have ORCA installed, right click on the MSI built using the Setup and

deployment project (this should be in your output folder) and select Edit with

ORCA.

7. This will open the MSI for further editing in ORCA. On the left side find a

table named “CustomAction” and select it. Towards the right pane you should be able

to see some Custom Actions already added by default. Right Click and select “Add Row”

8. In the Action field type a name to the CustomAction

(For example : other_cisco_controls), in the Target field type in 3122, in the Source field type

the name of the Property that you used in step 3.

In the Target field type /s “[SystemFolder]<name of the ocx file>”

9. Similarly create other CustomActions to register other ocx files.

10. The last step is to sequence these CustomActions to run. To do this on the left

pane in ORCA find a table called “InstallExecuteSequence” and select.

Right click on the right pane to add a new row.

11. In the Action field type in the name of the CustomActions as you had typed in

step 8. In the condition field type “Not Installed” and in the Sequence field type

a number 6400 and lesser than 6600.

12. Save the MSI file using ORCA and test the package.

Contributor : Ravi Shankar

How to disable the default Launch condition for the .Net Framework in a Visual Studio Setup and Deployment project.

Gauravb — Mon, 21 Dec 2009 20:49:00 GMT

Two ways to do this.

1)Create a Transform to make apply changes to the MSI as to skip the default launch condition. You may then author a Custom launch condition to only display a message and exit the installation.

Open the complied MSI using ORCA, click On the Transforms menu and select New Transform.

Find table by the name _VsdLaunchCondition and drop the only row it shows.

Click on Transforms and select Generate Transform. Save the transform as a mst file.

To install using the transform use the command line msiexec /I <path to msi file> TANSFORMS=<path to the mst file>

2)Build MSI file without the default Launch Condition.

In the VS Setup project, go to the Launch Condition editor.

Go to the properties for the Launch Condition by the name .NET Framework.

Set the Message Property to any message that you may want to display.

Set the InstallUrl field to blank and build the project.

Contributor : Ravi Shankar

Issues encountered when the same XBAP application is run from different codebases and the user navigates between those different codebases.

Gauravb — Wed, 04 Nov 2009 00:57:00 GMT

When the user navigates between different codebases, he may encounter with a blank/hang web page that fails to render the application. The issue can be encountered in the following scenarios:

1. Navigate to URL1/xbap1

2. Navigate to URL2/xbap1

3. Navigate to URL1/xbap1 -à Issue.

This issue is a bug in PresentationHost (the component responsible for deployment of xbaps using IPHM APIs.). It is encountered when a previous version of an already installed xbap is revisited somehow.

Development/Deployment time workaround options:

· Convert xbap to online-only ClickOnce application as online-only clickonce applications should work in the above scenarios without a problem.

· Change the application identity when deploying to different codebases so that the application looks like a different application. You can change the identity by changing the PKT or name in the deployment manifest. Note that the applications cannot share data through ClickOnce data directory in this case.

· Refrain from ApplicationDeployment APIs as they are going to fail in such scenario. There are two xbap APIs that can be used instead of IsNetworkDeployed and ActivationUri.: BrowserInteropHelper.IsBrowserHosted and BrowserInteropHelper.Source respectively. Note that there is no way of accessing Data Directory.

Contributor : Gaurav Bodar
Reviewer : Ravi Shankar

ClickOnce Publish Error: "Cannot continue. The application is improperly formatted. Contact the application Vendor"

Gauravb — Tue, 03 Nov 2009 23:32:00 GMT

Publish fails with Error "Cannot continue. The application is improperly formatted. Contact the application vendor for assistance."
Consequently after the failure to publish, when the application is debugged from within the IDE there is an error

ArgumentNullException was unhandled Value cannot be null.

Call Stack:Parameter name: activationContext

at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[] activationCustomData)

at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext)

at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone()

at System.Threading.ThreadHelper.ThreadStart_Context(Object state)

at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

at System.Threading.ThreadHelper.ThreadStart()

Cause

Cyclic dependencies caused due to having a reference to the same project under the references.

Resolution

Look under project references to verify that there are no Cyclic Dependencies.
Remove any Cyclic dependencies if exists.

Contributor: Aditya Hari
Reviewer : Ravi Shankar

ClickOnce:VS08 SP1 XML serialization assemblies not publishing

Gauravb — Tue, 03 Nov 2009 23:05:00 GMT

When using msbuild to publish the ClickOnce application which uses XML serialization assemblies we notice that they are not published.

Cause

It is known issue with Visual Studio 2008 SP1 and only with msbuild. If we publish normally using the IDE it works fine.

Resolution

Use the following Sgen task in the targets file.

<SGen

BuildAssemblyName="$(TargetFileName)"

BuildAssemblyPath="$(IntermediateOutputPath)"

References="@(ReferencePath)"

ShouldGenerateSerializer="$(SGenShouldGenerateSerializer)"

UseProxyTypes="$(SGenUseProxyTypes)"

KeyContainer="$(KeyContainerName)"

KeyFile="$(KeyOriginatorFile)"

DelaySign="$(DelaySign)"

ToolPath="$(SGenToolPath)"

SerializationAssembly="$(IntermediateOutputPath)$(_SGenDllName)"

Contributor: Aditya Hari
Reviewer : Ravi Shankar

ClickOnce Application Security Settings

Gauravb — Tue, 27 Oct 2009 18:25:34 GMT

The difference between the following two Security Settings in ClickOnce Application:
a> Selecting “This is a full trust application”
b> Selecting “This is a partial trust application” and choosing the all Permissions

Basically we would like to know the difference between a & b. In other words, we would like to know the details on the colored area as listed below.

Please note that both are not the same. Full Trust (also known as Unrestricted) is different than just including everything. http://msdn2.microsoft.com/en-us/library/8x61d3e3(VS.80).aspx

All permission sets are a subset of the FullTrust set (which doesn’t actually contain any permissions; it’s just a special permission set). Practically speaking this means that a demand for any permission at all when compared against the FullTrust set will succeed. If you simply select every permission, you’re not going to be a subset of any set that contains:

· Custom permissions that someone has written
· Identity permissions
· The FullTrust set itself

As an example of the last one, the System.Diagnostics.Process class will do a demand for FullTrust, which will only be successful against FullTrust code. Another different is in the execution environment between explicit FullTrust vs Internet+All permissions. In FullTrust case the EXE is launched directly, whereas in any partial trust or custom permission set case the app is run under AppLaunch.exe host process which causes some functionality to be disabled - e.g. regfree com, app update APIs.

If you select

a) (Full Trust application) then the application will be run directly by calling CreateProcess directly on the entrypoint exe. The application runs with full Code Access Security permissions (no different from any other native application running as the user) and in addition, has

1) access to its current working directory
2) support for registration-free COM
3) The ability to issue binding statements and safe mode declarations in the app’s config statement, allowing it to opt out of GAC servicing.
If you select

b) (Partial trust with all permissions) the app is not run directly via CreateProcess, but is instead hosted in a dedicated hosting process called applaunch.exe. In this case, you don’t get 1, 2 or 3 above.

Between these two, “Full Trust” is stronger execution permission for the above reasons.

Contributor: Soumitra Mondal

When you try to create a new setup project/open an existing setup project, Visual Studio 2005/2008 IDE may hang

Gauravb — Mon, 19 Oct 2009 16:51:00 GMT

To work around this problem, run DCOMCNFG.exe and clear the check box for the Provide additional security for reference tracking option on the Default Properties tab.

1. Click Start, point to Programs, point to Administrative tools, and then click Component Services.
2. When the Component Services explorer is open, double-click Component Services, and then click Computers to open the Computers folder.
3. Right-click My Computer, and then click Properties.
4. Click the Default Properties tab.
5. Disable the Provide additional security for reference tracking check box near the bottom of the page
6. Click OK.

Repro Steps
==========
1. Click Start, point to Programs, point to Administrative tools, and then click Component Services.
2. When the Component Services explorer is open, double-click Component Services, and then click Computers to open the Computers folder.
3. Right-click My Computer, and then click Properties.
4. Click the Default Properties tab.
5. Enable the Provide additional security for reference tracking check box near the bottom of the page.
6. Click OK.
Create a new setup project/open an existing setup project in Visual Studio 2005/2008. Note Visual Studio IDE hangs

More detail Information
====================
From the hang dump:
The first thread waits till the other thread finishes. Thread 0 is apartment threaded.

0:000> kL
ChildEBP RetAddr
000fff74 7c90e9c0 ntdll!KiFastSystemCallRet
000fff78 7c8025cb ntdll!ZwWaitForSingleObject+0xc
000fffdc 5ccbb98d kernel32!WaitForSingleObjectEx+0xa8
00100004 5cc6ca93 dpdpl!CVsThreadBase::Start_base+0x64
0010003c 5cd8cdad dpdpl!CVsdDeployable::Validate+0xcb
00100078 5cd946f4 dpprj!CVsdPrjBaseProject<IVsdPrjSetupProject,CVsdPrjSetupProject,&CLSID_VsdPrjSetupProject>::StartBackgroundValidation+0xa3
001000b0 501024ba dpprj!CVsdPrjRootNode<&CLSID_VsdPrjCabProject>::OnAfterOpenProject+0x109

The other thread is trying to unmarshal an apartment threaded COM object, which was created in thread 0. So it waits on thread 0 to process windows messages and deadlock

0:020> kL
ChildEBP RetAddr
0892f670 7c90e9c0 ntdll!KiFastSystemCallRet
0892f674 7c8025cb ntdll!ZwWaitForSingleObject+0xc
0892f6d8 7c802532 kernel32!WaitForSingleObjectEx+0xa8
0892f6ec 7752abbd kernel32!WaitForSingleObject+0x12
0892f708 77601e51 ole32!GetToSTA+0x6f
0892f728 7760109a ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0xf6
0892f808 7751047c ole32!CRpcChannelBuffer::SendReceive2+0xb9
0892f874 77510414 ole32!CAptRpcChnl::SendReceive+0xab
0892f8c8 77ef3db5 ole32!CCtxComChnl::SendReceive+0x113
0892f8e4 77ef3eac rpcrt4!NdrProxySendReceive+0x43
0892fcc0 77ef3e42 rpcrt4!NdrClientCall2+0x1fa
0892fce0 77e89aa4 rpcrt4!ObjectStublessClient+0x8b
0892fcf0 77511f50 rpcrt4!ObjectStubless+0xf
0892fd40 77511fa3 ole32!CStdMarshal::RemoteAddRef+0xb3
0892fd64 775117d3 ole32!CStdMarshal::GetNeededRefs+0x4a
0892fd98 7751168a ole32!CStdMarshal::ConnectCliIPIDEntry+0xa0
0892fdc4 77510cb0 ole32!CStdMarshal::MakeCliIPIDEntry+0x8c
0892fdf0 77510be0 ole32!CStdMarshal::UnmarshalIPID+0x66
0892fe44 77510fb1 ole32!CStdMarshal::UnmarshalObjRef+0xef
0892fe5c 77510f71 ole32!UnmarshalSwitch+0x25
0892fe90 77510fd9 ole32!UnmarshalObjRef+0x7f
0892ff14 77556e24 ole32!CoUnmarshalInterface+0xa7
0892ff30 5ccbb8b5 ole32!wCoGetInterfaceAndReleaseStream+0x16
0892ff44 5ccbba16 dpdpl!CVsThreadBase::UnmarshalParentIUnknown+0x1a
0892ff74 781329bb dpdpl!CVsThreadBase::InternalThreadMain+0x4c
0892ffac 78132a47 msvcr80!_callthreadstartex+0x1b
0892ffb4 7c80b683 msvcr80!_threadstartex+0x66
0892ffec 00000000 kernel32!BaseThreadStart+0x37

The COM is an internal COM object and so it doesn’t have registration information in the registry. Since it works on other machines my guess is that we unmarshal the interface before its marshaled. In order to compare it, I took a hang dump from a working machine with a break point on dpdpl!CVsThreadBase::UnmarshalParentIUnknown

I wanted to find why marshalling did not happen on working cases. To this effect I put breakpoints on all the functions in the secondary threads stack up to GetToSTA. Then I figured out where it deviated in the working machine. This led me to function ole32!CStdMarshal::GetNeededRefs. Checking this function lead me to a value and it was different between failing and working machines. The difference in values was a flag which according to the doc represents the above DCOM setting.

Reference: http://msdn2.microsoft.com/en-us/library/ms680051.aspx#_com_setting_machine_wide_reference_tracking

Contributor: Soumitra Mondal

How to add a .net dll within your application setup (Windows Installer Package) using Visual Studio 2005/2008

Gauravb — Mon, 19 Oct 2009 16:49:00 GMT

There are two methods to do it.

Method 1: Create a registry file for registration of the DLL file using regasm.exe utility (http://msdn.microsoft.com/en-us/library/tzat5yw6(VS.71).aspx)

Ex: %windir%\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe myTest.DLL /regfile:C:\myTest.reg

Now you need to import the registry within the Visual Studio Setup Project (Right-click “Registry on Target Machine”, click “Import”, and then browse to the .reg file) and build the Setup project.

Method 2: Deploy the assembly to the target computer in the global assembly cache (GAC)

· Right-click “File System on Target Machine”, click “Add Special Folder”, and then click “Global Assembly Cache Folder”.

· By default, the assembly is inserted in the Application Folder (by default, it is a side-by-side installation). Drag the assembly to the Global Assembly

Cache Folder.

· Build the Setup Project.

Contributor: Soumitra Mondal