Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
I have built an installer using the Visual Studio 2005 setup project wizard. It installs correctly on Windows XP but fails on Windows Vista. I investigated and found that the failure on Windows Vista is caused by a custom action that fails with an access denied error. However, I am running the setup with elevated privileges in Windows Vista. How can I fix my setup so it will work correctly on Windows Vista?
As Robert Flaming described in this blog post, it is necessary to set the NoImpersonate flag for custom actions that modify the system in Windows Vista. This was an uninforced architectural intent that is now enforced in Windows Vista.
Unfortunately, there is not a way to directly set this flag for a custom action in the UI for the setup project in the Visual Studio IDE. In Visual Studio 2005, you can use a post-build step that modifies the MSI to set this bit using a strategy previously described in this blog post.
You can use the following steps to set the NoImpersonate bit in a Visual Studio 2005 setup project:
<update date="1/22/2007"> Updated command line in step 7. The variable I had specified previously was incorrect. It actually needs to be spelled wrong using "ouput" instead of "output" in the $(BuiltOuputPath) variable </update>
<update date="3/18/2009"> Fixed broken link to the sample script. </update>
Hi Qasper and Jaydeep - It looks like my file server is back up, so the download link should work again. Just in case, I also posted the source code for this script at http://blogs.msdn.com/astebner/archive/2007/05/28/2958062.aspx so you can copy and paste it into a file that you can use when you build your VS setup projects.
Sorry for the hassle, and hope this helps....
Greetings, this is not only my first blog here (bare with me!) but the first in a series on creating
As I mentioned last time , deferred custom actions are generally no impersonate. In this entry, I hope
Hi Everybody, I followed the intructions given here, the msi built OK. but when I try to install the msi in MS Vista I'm still getting the same error for the custom actions. I run the msi as Administrator on Vista... thanks.. any ideas???
Hi there, I got a problem to run the script no impersonate script, my PostBuildEvent is:
cscript.exe "$(ProjectDir)CustomAction_NoImpersonate.js" "$(BuiltOutputPath)"
but I get the following error in the output window when when the CustomAction_NoImpersonate.js is executed, and of course the installation fails to install on vista:
C:\Source Code\VS 2005\Projects\SetupProj\CustomAction_NoImpersonate.js(24, 1) Microsoft JScript runtime error: Subscript out of range
Any help would be greatly appreciated, Thanks
Hi Claudirim - Please note the exact spelling of the command line listed in the blog post above. The variable name needs to be $(BuiltOuputPath) with the word "ouput" misspelled. Your comment lists it as "output" and that will not work correctly. Hopefully that will correct this issue. Please let me know how it goes for you.
Hi Lfgarbi - Are you sure that you're running into the same permission issue that is described in this blog post? Also, are you sure that the custom action attributes for your MSI are now being set correctly? Does the same MSI install correctly on OS's other than Vista? I'd suggest looking at the MSI in an MSI editor tool such as Orca and confirming that the custom action attributes are being set correctly for your custom action. If you're still not able to figure things out, I can try to help if you can zip and send me a copy of your MSI and a verbose log file from a failing installation. You can send those to Aaron.Stebner (at) microsoft (dot) com.
I have built an installer using the Visual Studio setup project wizard. I added my Windows Service and Windows Forms Application to a setup project with custom actions. In the After_Install event of the ProjectInstaller class in the Service application, I programmatically started the service and enabled service desktop interaction.
It installs and uninstalls without any problems to Window 2000 and Windows XP. However, when I tried installing the application on Windows Vista, I encounter this problem:
Error: 2869, Unexpected Error -
I stumbled upon this article and it helped with clear that error.
I now have this error to deal with: Access Denied while trying to write AlertService.InstallState and then the installation rolled back.
How can I fix my setup so it will work correctly on Windows Vista?
Hi NEO_GINELLI - If you are getting access denied while running a custom action in your MSI on Windows Vista, you will need to check the attributes of the custom action to make sure that it is marked as deferred and has the noImpersonate bit set so that it will run with the local system account privileges instead of the logged in user's privileges. The script listed above in this blog post can be used to mark custom actions in a VS setup project with the noImpersonate bit, which will hopefully fix this issue for you. If that doesn't work, you will need to debug your MSI further by checking the custom action attributes in an MSI viewing tool like Orca.exe.
The script works fine for my msi in Vista Business Edition but fails in Vista Home Premium. I get the error message "The installer has encountered an unexpected error installing the package. This may indicate a problem with the package. The error code is 2869."
Can you help me with some workaround?
Hi Binujacob - This script does not do anything that is different between the editions of Windows Vista. This error could indicate a problem within your custom action code (as opposed to a problem with the impersonation settings for your custom action). I'd suggest trying to debug your custom action on the Home Premium system where it is failing to try to narrow this down. You can use steps like the ones described at http://blogs.msdn.com/astebner/archive/2005/06/17/430320.aspx to set a breakpoint and attach a debugger to your custom action.
Thanks for your comments. You are right, the issue is not related to the impersonation setting. The issue is that when the database access fails from my Install() method, I throw a InstallException to rollback the installation. The funny thing is that eventhough I give a proper message while throwing the InstallException, it always shows the same "The installer has encountered an unexpected error installing the package. This may indicate a problem with the package. The error code is 2869.". I found a script similar to yours at http://blogs.msdn.com/nikhiln/archive/2007/04/25/post-build-script-to-fix-msi-issues-in-vista-for-vs-2005-setup-and-deployment-project.aspx but it doesn't seem to be working. Can you suggest a solution for this issue?
Thanks & Regards
Hi Binu - In this scenario, I don't believe you have any control over the error code reported by Windows Installer. The 2869 error is a generic error caused by any failure in this type of custom action. I think your best bet in this scenario is to log the exception to the verbose MSI log file if your custom action ends up throwing so that a user will be able to find more detailed troubleshooting steps in the log file in this scenario.
I found the solution and implemented it into my deployment project however it fails to rebuild the project and given error report " 'PostBuildEvent' failed with error code '1' 'Unspecified Error'
i copy and paste this line
cscript.exe "$(ProjectDir)CustomAction_NoImpersonate.js" "$(BuiltOuputPath)" so that i dont have any typo error. Any one have any idea how to solve this problem. I have already extract the file into the same folder as my solution file
Hi Donce - You need to make sure that you copy the file CustomAction_NoImpersonate.js to your project's root directory, and also make sure that you press enter to add a new line after any other post-build events that you might already have in your project. If neither of these help, you may want to try to add message boxes to the JS file to narrow down exactly where it is failing. Hopefully this helps.