Environment.GetFolderPath(Environment.SpecialFolders.ApplicationData) returns C:

Question

I have encountered a very strange behavior on the computer of one of my clients and I cannot find any clue as to why it happens: When the application calls Environment.GetFolderPath(Environment.SpecialFolders.ApplicationData) the return value will be C:.

This is of course wrong, his AppData directory is the usual C:\Users\.....\AppData\Roaming and also his variable %APPDATA% points to exactly that directory.

Can anybody shed light on why this could possibly happen?

EDIT: The code...

LogFilePath = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + @"\ReportsAddin";
if (!Directory.Exists(LogFilePath) && Properties.Settings.Default.Logging == true)
{
    try
    {
        Directory.CreateDirectory(LogFilePath);
    }
    catch (Exception ex)
    {
        // ...
    }
}

The exception thrown then says that it cannot create a directory consisting of a blank string or blank spaces. Investigating with some output showed that the AppData folder returning from that call is C: when in fact it should be the user's real AppData folder.

try to look into this post: http://stackoverflow.com/questions/3943626/wrong-path-returned-by-environment-getfolderpathenvironment-specialfolder-appli/3953509#3953509 — Roman, Nov 04 '13 at 13:29
Please place the code that gets the path, as well as any code up to the point at which you evaluate the actual path. It seems to me that the string is just inadvertently getting modified. — Mike Perrenoud, Nov 04 '13 at 13:42
Thanks for the reference, but I doubt it applies here, no IIS used. The client is running Windows 8 x64, exactly as I do, she just uses Office 2010 32 Bit. The application is an Excel addin btw. — Franz B., Nov 04 '13 at 13:43
Ok, I edited the original post with the part of the code which throws the error for that particular user. — Franz B., Nov 04 '13 at 15:20
At the moment, I do not have access to the client's computer anymore, but the account seemed pretty standard, main user account for that Windows 8. What should I try to look after, any hints in that regard? — Franz B., Nov 04 '13 at 15:23

score 1 · Answer 1 · answered Nov 04 '13 at 14:59

1

The actual path for the folder identified by Environment.SpecialFolder.ApplicationData depends on the current user (who started the program).

Make sure the program runs under a user account for which the ApplicationData folder exists. If your program runs under e.g. a local system account you may want to use another directory.

Instead of Environment.SpecialFolder.ApplicationData you could use Environment.SpecialFolder.CommonProgramFiles or Environment.SpecialFolder.CommonProgramFilesX86.

answered Nov 04 '13 at 14:59

helb

7,609
8
36
58

I know the current user and her %APPDATA% refers to a valid directory. In which way would I verify that the ApplicationData folder indeed exists for that specific user? (other than checking the %APPDATA% variable and the path) I would like to refrain from changing the application's folder for the sake of making it run on one computer and would thus happily welcome an actual solution. You are right though, I could circumvent it by using those folders. However, that would make it impossible to adapt it to other users' needs. – Franz B. Nov 04 '13 at 16:13

Environment.GetFolderPath(Environment.SpecialFolders.ApplicationData) returns C:

1 Answers1