Wrong path returned by Environment.GetFolderPath(E

问题:

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 Settings\myUserName\Application 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 Settings\Default User\Application Data

Things I have checked while running on the Win2003/IIS6 machine:

1. myUserName belongs to the group IIS_WPG (even tried Admin)
2. a call to Environment.UserName correctly returns myUserName
3. a call to Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); also returns a 'Default User' path, likewise with DesktopDirectory
4. logged on as myUserName and ensured that C:\Documents and settings\myUserName exists
5. 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 settings\myUserName\ApplicatonData, 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

回答1:

Solved. Apparently this is 'by design' because IIS6 does not load user profile settings.

Microsoft advised me to upgrade to IIS7 or call LoadUserProfile first, I wonder what possessed them to change that functionality from IIS5.1.

http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/890fa85a-b11a-4fbe-a333-cbe69abd72a7

Anyway lesson learned, don't assume functionality hasn't been removed and always test with the same application server even if annoys the IT department!

回答2:

Yes. it's not a bug. Under which user is running the app pool??

Let's split this a little:

The Test Machine uses IIS to host the service or the built-in web server? If you use the built-in web server, it runs under your user. If you use IIS, which one is the pool user?

If it is Network Service or Local System, the process runs under the context of one of those users, and indeed, the call to:

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) 

is OK.

You should change the user of the pool (and recycle the pool) to see the change.