Accessing the mapped folder from a Windows service written in C #

I have a windows service that polls a specific folder to create new files. This works great when the folder is on one of the local drives such as C: or D: The service does not find the folder on a mapped drive.

Here's the code that checks for the folder before polling:

System.Security.Principal.WindowsIdentity userIdentity =
            System.Security.Principal.WindowsIdentity.GetCurrent();
            System.Security.Principal.WindowsPrincipal principal =
                new System.Security.Principal.WindowsPrincipal(userIdentity);

            MappedDriveResolver mdr = new MappedDriveResolver();
            if (mdr.isNetworkDrive(folderPath))
            {
                LoggingAppWrapper.LogDeveloperMessage(folderPath + " is on a Mapped    drive", 1, TraceEventType.Information, string.Empty);

            }

      

MappedDriveResolver is the class I found here How do I determine the actual path of the mapped drive?

The code in this link works fine from a simple console app, but doesn't work when it is part of a Windows service. Any suggestions as to what needs to be done for the code for the Windows service to work?

Sincerely.

+3


source to share


1 answer


I would recommend that you configure the service to use UNC paths for folders, not on the server running the service.

Mapped drives are a usability feature for users and so they are specific to that user profile / environment. Meaning, when you log in, you might have an X: drive that maps to \\ server1 \ share1, but when you log in, my X: drive can map to \\ server2 \ share2 instead. The actual mapping process is either saved as part of your profile using "Restore on Login" or handled through the login script.

You need to check which account the service is running under and make sure the mapped drive exists for that user environment (this might help How to map the network drive that the service will use ).

Edit:

The reason your console application is running and the service is not is due to the differences between the environment in which they run.

To illustrate this, take this console application, compile it, and run it as a schedule task. Set the variable "path" to the mapped drive that your user can access.

    static void Main(string[] args) {
        MappedDriveResolver mdr = new MappedDriveResolver();
        string logfile;
        string path = @"I:\";
        string[] files;

        // Write out "log" file to where this is running from
        logfile = Path.GetDirectoryName(System.Reflection.Assembly.GetEntryAssembly().Location);
        logfile = Path.Combine(logfile, "log.txt");

        using (StreamWriter sw = new StreamWriter(logfile, true)) {

            try {
                sw.WriteLine("Checking path " + path);
                if (mdr.isNetworkDrive(path)) {
                    sw.WriteLine("Network Drive: Yes");
                } else {
                    sw.WriteLine("Network Drive: No");
                }
            } catch (Exception ex) {
                sw.WriteLine("Exception: " + ex.Message);
            }

            try {
                sw.WriteLine("Resolve path " + path);
                string newpath = mdr.ResolveToUNC(path);
                sw.WriteLine("Resolved path " + newpath);
            } catch (Exception ex) {
                sw.WriteLine("Exception: " + ex.Message);
            }

            try {
                sw.WriteLine("Get file list from " + path);
                files = Directory.GetFiles(path);
                if (files == null || files.Length == 0) {
                    sw.WriteLine("No files found");
                } else {
                    sw.WriteLine(string.Format("Found {0} files.", files.Length));
                }
            } catch (Exception ex) {
                sw.WriteLine("Exception: " + ex.Message);
            }

            sw.Flush();
            sw.Close();
        }
    }

      



Note. This applies to Windows 7 Task Scheduler

Test 1: Just run the application by double clicking on it.
Result: Success

Test 2: Configure a scheduled task to run as a user account with "Run only when user logs on"

Result: Success

Test 3: Configure a scheduled task to run as a user account with "Run whether user was enabled or not"
Result: Exceptions

Test 4: Configure a schedule task to run as the Local Service account.
Result: Exceptions

Test 1 and 2 work because they are using the current login environment, including the mapped drives that are part of it.

Testing 3 and 4 is due to the fact that they have their own custom environment created for them, which does not have any configured mapped drives. At this point, I'm running out of ways that there are differences, but "interactive" and "non-interactive" environments differ in significant ways.

+4


source







All Articles