Most .NET programs of any consequence require certain knowledge of the underlying system: the current user's name, the name of the machine or domain, locations of particular folders, etc. In older applications, those written in Visual Basic or other languages accessing the Windows API directly, obtaining this essential information required programmers to understand dozens of API calls, some quite obscure, spread out over many different DLLs. In the .NET Framework, all of that essential information is supplied by a single class: System.Environment. This article from InformIT takes a look at some of the mistakes made by programmers when accessing this directory.
One of the biggest sins of application developers is assuming the location of certain directories. "Everybody knows," for example, that the system directory is "C:WINDOWSSYSTEM32" on Windows 95, 98, and ME, and "C:WINNTSYSTEM32" on Windows NT variants including Windows 2000, XP, and 2003. Except what "everybody knows" is dead wrong in many cases. I've seen systems that have the system directory on the D drive, or have an entirely different name for the system directory.
In addition to assuming the location of certain directories, many programmers also put application-specific data in inappropriate places, or store special kinds of files in places other than where they're supposed to be. Application-specific data, for example, should never be stored with the application in the C:Program Files directory hierarchy because many users don't have write access to that hierarchy. Application data belongs in the Application Data directory defined for the logged-in user, or in the Common Application Directory if all users share the data.
The question, then, is how to find the location of the appropriate directory. The answer is the System.Environment.GetFolderPath method. GetFolderPath returns a string that contains the location of the directory identified by the Environment.SpecialFolderEnumeration value that you pass as the lone parameter. For example, to determine the location of the user's "My Pictures" folder, you would write:
[C#]
string MyPicturesFolder =
Environment.GetFolderPath(Environment.SpecialFolder.MyPictures);
[Visual Basic]
Dim MyPicturesFolder As String = _
Environment.GetFolderPath(Environment.SpecialFolder.MyPictures)
Unfortunately, the Environment.SpecialFolder enumeration does not include values for all of the special folders supported by the Windows API and accessible by the SHGetFolderPath function. For example, you can't obtain the Recycle Bin directory location from Environment.GetFolderPath. To obtain locations that aren't identified by Environment.SpecialFolder, you have to use P/Invoke to call SHGetFolderPath or SHGetFolderLocation Windows API functions. Even with those restrictions, Environment.GetFolderPath is quite useful. You should use it to obtain special folder locations rather than assuming a particular path.
You can obtain the path to the system directory, by the way, through the Environment.SystemDirectory property, or by calling Environment.GetFolderPath and passing Environment.SpecialFolder.System.
Another important directory is the current directory: the directory in which the application is executing. The Environment.CurrentDirectory property will report the current directory, and also will allow you to change the application's current location.
Read more about the System.Environment directory at InformIT.
