3

This seems to have happened completely randomly. One minute the program was working, then I made some changes (completely unrelated to this part of the program, all I actually changed was one of the embedded resources of the project) and the following property now returns just a "\".

public static string ProgramDataDir
{
    //this has always worked on all windows OSes before, but all of a sudden, not so
    //get { return Environment.GetEnvironmentVariable("ProgramData") + @"\"; }

    //I've tried changing it to this, and this doesn't work either - same results
    get { return Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + @"\"; }
}

This property should, and has always returned C:\Documents and Settings\All Users\Application Data on XP and Server 2003. This no longer works on a virtual 2003 machine and a virtual XP machine, both running on the same virtual host. The host doesn't have any effect on these environment variables does it? Could it be a problem with my virtual host? Unfortunately I don't have an available, standalone Server 2003 or XP machine that I can install this software and run tests on.

Note: I realise that this part is not a programming question as such, more a server issue, but due to the nature of the rest of the question I feel it still suited SO, please correct me if I'm wrong.

Also, I haven't touched this project in some time, I'm pretty sure I haven't changed any settings except for the assembly version number, but I don't know and can't remember if I had changed any of the compilation settings or similar after the last working version. Would any of these kind of settings have this sort of effect on my application?

The application is running as a Windows Service, so using any of the user special folders isn't appropriate for this application.

Connell
  • 13,925
  • 11
  • 59
  • 92
  • Have a look at http://stackoverflow.com/questions/305870/windows-services-and-environment-variables – Eddy Aug 11 '11 at 16:18
  • Thanks Eddy. I had a bit of a play with this but that appears to be a separate problem. The environment variable I'm using should be automatically added by the OS. I've just tested it in a clean install of XP on the same virtual host and have the exact same results. – Connell Aug 12 '11 at 08:17
  • AFAIK Programdata is a folder introduced after win2003/xp. On win7 the env variable %CommonApplicationData% returns c:\programdata\ on older systems including w2k3 is points somewhere un c:\documents and settings. Can you point me to any document where it says that an env variable %PROGRAMDATA% exists by default on any windows platform? – Eddy Aug 12 '11 at 08:49
  • I checked my w2k3 server instance and it doesn't exist there either but this is like yours running inside a vm – Eddy Aug 12 '11 at 08:52
  • I can't find a document that states it, but the software has been working on XP and 2003 using this variable for well over a year now. It must to do with the compiler, because the old exe file for the working version of the software still works :/ – Connell Aug 12 '11 at 08:56
  • Put the old (working) exe into reflector to decompile it and check what code is actually executing. It doesn't make sense that it is successfull at getting a value from an environment variable that isn't set. The only way I can see that it would is if the old exe is for instance started from a cmd file that first sets the env variable and then starts the app – Eddy Aug 16 '11 at 11:57
  • I never worked it out in the end. It mustve been a compilation setting I've changed, as I've read that XP and 2003 don't support the ProgramData environment var. I must've had some sort of compatibility setting enabled previously that allowed that variable to work. My workaround was to return the All Users AppData folder when using ProgramData returns an empty string or null. This worked in my solution as the variable is only ever retrieved once, then the database path is saved in the registry. Thanks for your help. – Connell Aug 16 '11 at 12:20

1 Answers1

0

Does that path exist on your machine or was it otherwise replaced? According to the documentation for Environment.GetFolderPath:

A folder will not physically exist if the operating system did not create it, the existing folder was deleted, or the folder is a virtual directory, such as My Computer, which does not correspond to a physical path.

Could this be the case for you?

dpurrington
  • 1,488
  • 11
  • 20