.NET 1.1+

Mapping a Drive Letter Programmatically

Some legacy applications do not permit the use of UNC paths when accessing network folders, instead requiring that a drive letter be mapped. When interacting with such software it may be necessary to map a drive letter and later remove mappings using C#.

UNC Paths and Drive Letters

Modern computers are often connected to a network with access to many other remote resources, including shared folders, printers and other devices. These resources are usually referenced with a unique path name defined using the Uniform Naming Convention (UNC). UNC paths generally specify the name of a machine, or cluster of devices, and the name of a folder, file or other resource that is to be accessed. An example of a UNC path that you may use in Windows is "\\BlackWasp\ImageGallery\Wasp.ico". This path leads to the Wasp.ico file, which is held in a shared folder named "ImageGallery" on the "BlackWasp" server.

Earlier in the history of PC operating systems, DOS and Windows-base software relied on the use of drive letters to access files. In the same way that C: usually refers to the main hard disk drive in a PC, other letters would be mapped to networked resources. This permitted applications to open and save files to local and networked folders using the same naming conventions. For example, the "\\BlackWasp\ImageGallery" could be mapped to I:, allowing the file described earlier to be accessed using the path, "I:\Wasp.ico".

The problem with the drive letter approach is that it only permits a maximum of twenty-six local and remote folders to be accessed simultaneously. In a modern office environment this may not be enough. Handily, the use of the UNC is supported by Windows and by the .NET framework without additional effort. However, if you need to interact with older software you may need to add and remove drive letters programmatically.

In this article I will describe some of the manners in which you can map drive letters using C# code. For a demonstration of these methods, download the sample application using the link at the top of this article.

Mapping Drive Letters

The .NET framework does not provide a means of mapping a drive letter. Instead, a Windows API function must be executed using Platform Invocation Services, also known as P/Invoke. To use P/Invoke, classes from the InteropServices namespace are required. To make the code in the samples below more readable, it makes sense to add a using directive for this namespace:

Referencing WNetAddConnection Methods

There are two API functions that can be used to directly map a drive letter to a folder represented by a UNC path. These are called WNetAddConnection2 and WNetAddConnection3. These functions supersede a previous method named WNetAddConnection, which is now present only to allow the correct operation of 16-bit applications.

The two functions are found in the mpr library of the Windows API. We can add references to the functions using the following code:

[DllImport("mpr.dll")]
static extern UInt32 WNetAddConnection2(ref NETRESOURCE lpNetResource, string lpPassword, string lpUsername, uint dwFlags);

[DllImport("mpr.dll")]
static extern UInt32 WNetAddConnection3(IntPtr hWndOwner, ref NETRESOURCElpNetResource, string lpPassword, string lpUserName, uint dwFlags);

You can see that the two declarations only differ in one respect. When using WNetAddConnection3, an additional parameter is provided. This parameter, named hWndOwner in the sample above, receives the handle of a window. If the call to the API function results in the display of interactive dialog boxes, the parent window of these dialog boxes will be the one with the specified handle. In all other respects, the two methods are essentially identical.

When selecting between the two functions, use WNetAddConnection2 where there is no visible user interface or where no user interaction will be required. Use WNetAddConnection3 when calling the function from a form within a Windows application.