I have a setup project for a Windows service that we wrote some time ago. At the start of this current dev cycle, I upgraded the solution from VS 2008 to 2010 and went on my merry way to update code for the service (no changes to the installer). No big deal – all seemed well, … until I tried running the installer.
During install, we prompt for a username which we use to set ACLs on some files and directories. We do this by calling NTAccount.Translate like so:
SecurityIdentifier serviceAccountSid = (SecurityIdentifier)new NTAccount(serviceAccount).
The user is prompted to enter their domain & username (i.e. myDomain\dhanan) and we translate that to a SID to set the file & folder permissions.
This all worked fine with the VS 2008-based installer, but then I spent WAY too much time yesterday debugging why it was failing now (exception: Some or all of the identity references could not be translated”. TFS source control confirmed that there were no source code changes involved other than the upgrade to VS 2010 (which actually did NOTHING to the setup .vdproj project file). Mysterious, huh?
I finally discovered that the issue was in the value coming from the installation custom dialog edit box where the user enters their domain and username. That value that gets added to the dictionary coming into the Installer.OnCommitted() method (via CustomActionData set to “/service_account=[EDITB1]” ).
When debugging into the Installer class and inspecting the value for the service_account, it had TWO backslashes in it (i.e. @"myDomain\\dhanan”), instead of 1 that I typed in as the user!
The lame thing about this is that it only does this in the VS 2010 setup project, not the VS 2008 one. The only thing I can find online that’s even loosely related is this: Troubleshooting Setup and Deployment Projects. (Backslash in textbox causes invalid directory or URL exception). They don’t mention WHY – I’m wondering if it’s the same issue.
So … I now have a hack at the top of the OnCommitted( ) method:
serviceAccount = serviceAccount.Replace( @"\\", @"\" );
Lame, but it works. Hey MS – please fix this !!
Thanks Rohit for the comment. Yep, we ended up fixing it that same way. (and then removed the string replacement code out of the custom actions). I guess the lesson learned is *always* put quotes around the variables that are coming from custom dialogs.