On my test machine running (Windows XP, IIS5.1) the following code executed within a C# .NET WebService (.SVC) under a custom process identity (using machine.config to specify the user)
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
correctly returns
c:Documents and SettingsmyUserNameApplication Data
However, on (Terminal Services) Windows 2003 machine running IIS6 and executing the same code but now using ApplicationPool to specify the same process identity the method returns:
c:Documents and SettingsDefault UserApplication Data
Things I have checked while running on the Win2003/IIS6 machine:
- myUserName belongs to the group IIS_WPG (even tried Admin)
- a call to Environment.UserName correctly returns myUserName
- a call to Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); also returns a 'Default User' path, likewise with DesktopDirectory
- logged on as myUserName and ensured that C:Documents and settingsmyUserName exists
- running the exact same code in a .net application on the Windows 2003 box, this works and returns the correct path.
I am baffled, it only occurs when runing under IIS6. It is almost like it thinks that the call is coming from Network Service or Local System users and it is not checking the Identity running the Application Pool.
Incidentally when I look at Procmon and watch a C++ application that is called from the webservice it has no such problem reading and writing to C:Documents and settingsmyUserNameApplicatonData, it does not seem to have a problem, perhaps it builds the path differently.
I am starting to think this might be a bug in .NET??
Thanks.
Tom Deloford
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…