Getting your application ware of Vista’s UAC

January 31, 2008

If your application does anything “bad” like writing to program files directory or the local machine part of the registry then its unlikely to run as expected on Vista (dont use the virtual stores).

If your app really needs to write to these forbidden lands your users will need to escalate it to admin privileges via the UAC dialog. Visual Studio 2008 makes this pretty simple, just right click on your solution and select at Add New item, then select Application Manifest File. Open the app.manifest file and change the “requestedExecutionLevel” level to “requireAdministrator”. If, like me, you package the setup.exe bootstrapper and setup.msi in to a self extracting zip, make sure you include the word setup in your exe name. Vista automatically shows the UAC dialog when any executables named *setup*.exe are ran.

Also see http://channel9.msdn.com/Showpost.aspx?postid=334866

Advertisements

Reading other app.config files

January 11, 2008

Since VS 2005 its been really easy to read / write app.config properties thanks the to the strong typed Properties.Settings class created for us by Visual Studio. However reading / writing properties of a app.config which belongs to other application isn’t as straight forward. Why would you want to do this anyway? well, perhaps the app.config belongs to a Windows service and you want to give users the ability to alter settings from a configuration application written using windows forms.

The following code requires you to add System.Configuration to your references.

public static void UpdateAppConfigValue(string SettingName, string NewValue)
{
string sConfigFileName = “OwnerApp.exe.config”;
string sSettingsSection = “OwnerApp.Properties.Settings”;
string sSettingName = SettingName;
string sValue = NewValue;

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = sConfigFileName;

Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

ConfigurationSectionGroup grpApp = config.GetSectionGroup(“applicationSettings”);
ClientSettingsSection secPropSet = (ClientSettingsSection)grpApp.Sections[sSettingsSection];

secPropSet.SectionInformation.ForceSave = true;

SettingElement elm = secPropSet.Settings.Get(SettingName);
elm.Value.ValueXml.InnerText = NewValue.Trim();

config.Save();
}

public static string GetAppConfigValue(string SettingName)
{
string sConfigFileName = “OwnerApp.exe.config”;
string sSettingsSection = “OwnerApp.Properties.Settings”;
string sSettingName = SettingName;

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = sConfigFileName;

Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

ConfigurationSectionGroup grpApp = config.GetSectionGroup(“applicationSettings”);
ClientSettingsSection secPropSet = (ClientSettingsSection)grpApp.Sections[sSettingsSection];

secPropSet.SectionInformation.ForceSave = true;

SettingElement elm = secPropSet.Settings.Get(SettingName);

return elm.Value.ValueXml.InnerText.Trim();
}


Elegant solution for dialog conditioning

January 10, 2008

Good dialogs should only show appropriate options. For example Power Management settings should only be available when Power Management is enabled, or when Power Management is selected to be enabled when the dialog is closed.

Data binding provides us with a elegant solution for such dialog conditioning. Simply place all conditional controls (in this case power management settings controls) in to a panel (pnlPMSetting). Data bind the Enabled property of the panel to the Checked property of the enabler control (ckUsePM).

pnlPMSettings.DataBindings.Add(“Enabled”, ckUsePM, “Checked”);