I am writing this post as I know quite a few developers only now migrating apps from Windows XP environments, most of whom are spending a lot of time fighting with the new tighter security world that started to come in with Windows Vista.

As most know; the directory structure for user files and temporary documents has changed over the life of Windows (“C:\Documents and Settings\…” is now “C:\Users\…”, Program Files location changes for 64 bit, etc).

In addition to this many of the folders and registry keys, that as a developer, you used to be able to write files and values to are no-longer accessible. In addition to this areas of the event log are also locked down, and writing to it can crash your application if not handled correctly.

So now on Windows Vista, Windows 7 and Windows 8, as a developer you cannot and should not be writing to Program Files, the root of any of your drives, Windows folder, etc, etc. This can also include the traditional temp folder (C:\Windows\Temp or C:\Temp).

The only places you can write to with any certainty are the user specific Temp folder, the ProgramData folder, or the users document store.

If you are having to deal with a legacy app you might have to manually (or programatically) override the security settings granting permissions to write files to the locations you need, though you should do so with caution, as Windows updates and security patches can reverse your changes.

All of these locations vary depending on the system setup and operating system, so what is the best way to handle it?

Well in any .NET App you can easily access any of these folders locations using the Environment namespace (System.Environment) and the SpecialFolder enumeration.

For example: –

Console.WriteLine(“Folder Path: {0}”,
System.Environment.GetFolderPath(System.Environment.SpecialFolder.ApplicationData));

A full list of the special folders can be found at http://msdn.microsoft.com/en-gb/library/system.environment.specialfolder.aspx

This is not a list of those accessible for writing to, it is a complete list.

In addition to these you can also access the traditional list of environment variables using: –

System.Environment.GetEnvironmentVariable(string);

Though for this you need to know what is available as it will cause an exception if you call for a variable that does not exist.

You can get a full list of what is on your current system with: –

var s = System.Environment.GetEnvironmentVariables();
foreach (System.Collections.DictionaryEntry item in s)
{
Console.WriteLine(“{0} = {1}”, item.Key, item.Value);
}

But you need to avoid app specific ones, and watch out for some that may have changed names over the years.

You can access the documentation (.NET 4.5) for the System.Environment class at http://msdn.microsoft.com/en-us/library/z8te35sa.aspx or via your Visual Studio help.

With regards to the Event Log, you need to make sure you create your event source during your app install (or have an admin add it into the appropriate event log). This may not be caught during development as most developers run as admin and may even turn off all the UAC protection.

If you don’t then the kind of error you might see in Visual Studio would look something like: –

Security Exception when trying to write to Event Log.
“The source was not found, but some or all event logs could not be searched. To create the source, you need permission to read all event logs to make sure that the new source name is unique. Inaccessible logs: Security.”

But all your users will see is something like: –

App crash when trying to write to Event Log

If you need to use the event log (which is good practice), then make sure you have created your source during your install and not during your exception handling.

As for the registry, unless your app is running in elevated mode, the only hive you now have access to is HKEY_CURRENT_USER, some of which itself may have been locked down, by specific apps to prevent changes. So if you need to read from HKEY_LOCAL_MACHINE then you should not be using CreateSubKey; but creating your keys/valuse during or app elevation and using OpenSubKey for reading… remember you exception capturing though, similar to Environment Variables, you’ll get an exception if you don’t have access or the key does not exist.