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:
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.
The UW IMAP toolkit is a strange beast...
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...