ASP: be careful when using Server.MapPath() in the Application_OnStart event within global.asa

In the Application_OnStart event in global.asa the Server.MapPath() method may not give you the path you expect, which means
in most cases it is not safe to use Server.MapPath() in Application_OnStart. The problem occurs because when the Application_OnStart event runs it operates in the context
of the page that the user was requesting that caused the IIS Application to start.

This means that if you have a page on your site with the path "/virtual_root/folder/page.asp" if a user requests that page when the IIS Application is not started, when Application_OnStart
fires it will be within the context of "/virtual_root/folder/". This means that if you use Server.MapPath(), ASP will treat any paths/file names you pass to it as being relative to "/virtual_root/folder/".

So if "/virtual_root/" was physically located at "c:\inetpub\wwwroot\virtual_root\" and you passed the path "xsl/transform.xsl" to Server.MapPath(),
instead of returning the path you might assume ("c:\inetpub\wwwroot\virtual_root\xsl\transform.xsl") you will in fact get "c:\inetpub\wwwroot\virtual_root\folder\xsl\transform.xsl" returned.

If your website is just a one off site that you have complete control over then the best solution is simply to abandon Server.MapPath() within Application_OnStart and hardcode
the physical path instead. If you don't want to do that, you can instead compare the output of Server.MapPath(".") with your known, hardcoded virtual root path to work out
the actual phyical path.

If you web application is a product that you sell to other people for them to install on their webservers then it is a little more challenging to solve. The solutions obvious are:

hardcode the paths (by collecting the physically path details during setup or making the user edit a file in the site)

remove all use of Server.MapPath() from Application_OnStart

N.B. the same issue partly applies to the Session_OnStart event if you use that. In this case you can work around the problem, because when the Session_OnStart event
fires you have access to the ASP Request object. This means that you can get details ("APPL_PHYSICAL_PATH" from the Request.ServerVariables collection) that will allow you to determine
the physical path of the virtual root and therefore work out the correct path. If only ASP gave you access to the Request object within Application_OnStart then this problem
would be easily resolvable.

One of the oddities that it has is a configuration file that the maintainers of the toolkit strongly advise you not
to use. This file allows you to do various useful things, the most useful of them to me is the ability to change
the directory where all the mail folders are stored. The default for this is the user's home directory, which to me is
a pain as it leaves you with all your mail cluttering your home directory.

The details of how to use the /etc/cf-client.cf,
~/.imaprc and ~/.mminit configuration files are supplied in the
src/imaprc.txt file that is part of the UW IMAP distribution. There are all sorts of dire warnings in this file about
what can go wrong if you use it.

There is however no warning about one of the quirks associated with these files. It took me a long time to work out
why the imap server was ignoring my /etc/cf-client.cf file. I discovered in the end that a line at the end of the file
without newline is ignored...