We should highlight few important things at this stage
- As the Commit event knows the Target Directory where the application is being installed, you can save it to the register for future references from the application, which is a Frequent Asked Question.
- The Commit event can reference the TargetDir property from the Context.Parameters variable because it was initialized by the Install event.
- You may use the code shown in the Commit example above to explore what is available on any event in your Installer Class.
- You should never attempt to modify the InstallState file, if you damage this file and the Uninstall event requires any information from it, you will not be able to uninstall the application.
- You should use the Commit event to apply final changes, like writing information to the register, changing folder permissions, etc.
USING THE COMMIT EVENT TO CHANGE THE TARGET DIRECTORY PERMISSIONS
If your deployment project is installing a Windows Services, and the Windows Services creates or write to files located on the TARGET DIRECTORY (Its home directory), you should change its permissions with the COMMIT event as long as the Windows Services is running under the LocalService, NetworkService or LocalSystem.
The code below changes the TARGETDIR permission for a Windows Services running under the LocalService account.
Code:
DirectorySecurity dirSec = Directory.GetAccessControl(savedState["TargetDir"].ToString());
FileSystemAccessRule fsar = new FileSystemAccessRule(@"NT AUTHORITY\SERVICE"
, FileSystemRights.FullControl
, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit
, PropagationFlags.None
, AccessControlType.Allow);
dirSec.AddAccessRule(fsar);
Directory.SetAccessControl(savedState["TargetDir"].ToString(), dirSec);
|
You should add the following reference at the top of your class for the code above to work
Code:
using System.Security.AccessControl;
|
We get the Directory Security for the target directory (Windows Services home directory) using the GetAccessControl method on it; We already know it is save to use savedState["TargetDir"].ToString() from the explanations given before.
We create a new File System Access Rule for the NT AUTHORITY\SERVICE account, granting it (allowing, as the last parameter specifies AccessControlType.Allow) FullControl and setting the Inheritance Flags to ContainerInherit and ObjectInherit (both of them, the pipe between them works like a logical or, giving both of them), and setting the propagation flags to none. Why should we do this? the answer is simple, because it worked (after few hours of trial and error).
The complete code for the Commit event granting full permissions to the Windows Services' LocalService account is shown below:
Code:
public override void Commit(System.Collections.IDictionary savedState)
{
base.Commit(savedState);
DirectorySecurity dirSec = Directory.GetAccessControl(savedState["TargetDir"].ToString());
FileSystemAccessRule fsar = new FileSystemAccessRule(@"NT AUTHORITY\SERVICE"
, FileSystemRights.FullControl
, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit
, PropagationFlags.None
, AccessControlType.Allow);
dirSec.AddAccessRule(fsar);
Directory.SetAccessControl(savedState["TargetDir"].ToString(), dirSec);
}
|
We removed the code using the streamWriter as it is not relevant to change the TARGETDIR permissions. After these changes and installing the application, the target directory permissions for the NT AUTHORITY\SERVICE account are shown below; the account NT AUTHORITY\SERVICE is represented by the SERVICE account in the picture: 
USING THE UNINSTALL EVENT TO CLEAN THE TARGET DIRECTORY
Well, after working long hours and having countless meetings with your client, they decided to Uninstall your solution, or perhaps they were so thrilled that a new and more powerful one will replace the original one. Regardless of the reason, applications will not remain installed forever, sometime they have to go, and when this happens you want everything under its home directory (known as target directory by the deployment project) to get deleted. The deployment project's uninstall process will get rid of all the objects it installed (including your installer class), but its home directory may not be deleted if it is not empty and your application may have created files (log files, temp files, config files, registry entries, etc) that the deployment project is unaware of, so it will not consider deleting them at uninstallation time; this is a situation that your installer class' UNINSTALL event should take care of.
The code below is for an installer class UNINSTALL event cleaning the target directory.
Code:
public override void Uninstall(System.Collections.IDictionary savedState)
{
base.Uninstall(savedState);
String _TargetDir;
_TargetDir = savedState["TargetDir"].ToString();
if (File.Exists(_TargetDir + "DB.log") == true)
{
File.Delete(_TargetDir + "DB.log");
}
if (File.Exists(_TargetDir + "DB_Settings.log") == true)
{
File.Delete(_TargetDir + "DB_Settings.log");
}
if (File.Exists(_TargetDir + "DB.config") == true)
{
File.Delete(_TargetDir + "DB.config");
}
}
|
You should not be concerned about deleting the Installer Class and its InstallState files as the un-install process will delete them at the very end, your IC's Uninstall event should delete whatever was created outside the initial installation.
WHERE IS THE "NT AUTHORITY\SERVICE" ACCOUNT COMING FROM?
One way to find the account a windows service is running under is by adding these lines of code in the Windows Service's OnStart event:
Code:
WindowsIdentity self = WindowsIdentity.GetCurrent();
SecurityIdentifier selfSID = self.User;
StreamWriter sw = new StreamWriter("C:\\Temp\\Iam.txt");
sw.WriteLine("I am " + self.Name);
sw.WriteLine("wow " + self.Groups.ToString());
sw.Flush();
sw.Close();
|
You will need the following namespaces for the code above to work
Code:
using System.Security;
using System.Security.AccessControl;
using System.Security.Principal;
using System.IO;
|
You should make sure, the Temp folder exists on the machine where you are running the Windows Service. The account NT AUTHORITY\SERVICE was found with the code above on a Windows Xp machine, it may change elsewhere, like Windows 2000 or 2003 Servers.