<p>We're trying to decide between having all the devs on a particular team to use an absolute path for their code base or if relative paths are fine.</p>

<p>One reason I can think for an absolute path, meaning everyone has the same path, is because of IIS and functional tests.  Our asp.net functional test use Nunit and WatiN to fire up IE and go through various scenarios.  To have these run stand alone from the Nunit GUI, I have to check if Cassini is running and if not, start it.  It requires passing in the physical path.  So, only people using that particular path can run the functional tests this way.  </p>

<p>Are there any deal breakers that argue for an absolute (common) path?</p>

I too was faced with the situation where the dev server required an absolute path to launch. It was also for unit testing. After spending a couple of days dwelling on the issue, I decided to refactor as much as possible to make testing work without requiring the actual ASP.NET pages to be served. This meant abandoning automated UI testing of some packaged server controls, but in the end, I never found a good solution.
Absolute paths are one of the worst things I've ever encountered in almost any environment. They're a timebomb waiting to happen.
That said, I've often had an application that required an absolute UNC path as a "drop" location for uploaded files (when hosted in a web farm). I found it acceptable, in the end, for lack of a better solution.