Current working directory in ASP.NET code entries - can we depend on it?

Question

Can we depend on the current working directory in ASP.NET codes? Or, in other words, can we use relative paths and be sure that they will work?

If on one page on a website I set the current working directory to something specific, will it remain the same the next time I load another page on the website? When does the same page load on a website?

If I set the current working directory to something specific, in Page_Load (), can I be sure that by the time Page_PreRender () is called? Or can another page on the same website change it on me, between them? Can a page on another website in the same application pool change it to me? Page on another website in a different application pool?

In other words, what is the scope of the current working directory in IIS? Is this page specific? Is it website specific? Or is it common across all pages in the application pool?

Where, among the pages, the website, the application pool and the server, are the boundaries that isolate the different values ​​of the current working directory?

Answer 1

Environment.CurrentDirectory is a simple wrapper around GetCurrentDirectory and SetCurrentDirectory winapi. Indeed, trying to install a directory requires UnmanagedCode permissions. Whenever a function prevents your site from running in partial trust, you are right to be careful depending on this. :)

From the documentation for SetCurrentDirectory :

Changes the current directory for the current process .

The best explanation I can find covers the connection between the w3wp.exe process and the ASP.NET site with this answer . Any other page on your site could potentially change the current working directory of your page. Any pages on any other site in the same application pool can potentially change the current working directory of your page. These external changes to the current working directory can occur at any time during the execution of your page. On the other hand, a page on a site under a different application pool will not change the current working directory of your page. The reason I can say “potentially” is because it becomes even more complex if you look at web garden scripts where there can be more than one process for one ASP.NET site.

Now consider that SetCurrentDirectory not thread safe:

Multithreaded applications and shared library code should not use the SetCurrentDirectory function, and relative path names should be avoided. The current state of the directory written by the SetCurrentDirectory function is stored as a global variable in each process, so multi-threaded applications cannot reliably use this value without possible damage to data from other streams that can also be read or set to this value. This limitation also applies to GetCurrentDirectory and GetFullPathName. an exception is when the application is guaranteed to work in a single thread, for example, parsing file names from the command line argument string in the main thread before creating any additional threads. Using relative paths in multi-threaded applications or common library code can give unpredictable results and is not supported.

Most likely, you do not want to depend on the current working directory . Having said that, given how stupid it is to rely on the current working directory, you can be pretty sure that no other code will touch it. :) A quick look with Reflector shows that no .NET platform code changes it. Some features really check this out, so keep an eye out for them. If you control the deployment environment, you can ensure that your site runs in its own application pool. With the right synchronization technique, you can safely update the current working directory. I would not consider this to be anything other than hacking.

Answer 2

AppDomain.CurrentDomain.RelativeSearchPath will give you the physical path to the bin folder

Answer 3

Links should be created relative to the site root using the tilde (~) operator:

 <a href="~/mysite/somepage.aspx" id="someLink" runat="server">Some Page</a> 

Inside the server, the application pool completely isolates your site, so if any other site fails on the same server, it will not knock down your site with it. IIS is heavily site-specific with the added benefits of isolating application pools. I do not see any practical use when trying to change the link on one page from code to another (or maybe I do not quite understand the question).

Here is a brief description of the IIS architecture:

http://learn.iis.net/page.aspx/243/aspnet-integration-with-iis-7/