Reasons to have an absolute path in .NET

Question

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.

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.

Are there any deal breakers that argue for an absolute (common) path?

Answer 1

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.

Answer 2

Go with relative pathnames. Really. Think of branching your repository. Think of setting up Unit Tests. Think of having separate debug and release builds. To pun a bit... It's all relative.

Answer 3

I'd avoid absolute paths if possible. As a general development principle I ought to be able to check your code out on my machine wherever I like.

If you must use absolute paths for some reason, put them in your .config file app settings - at least then you can have different paths for your development and deployment machines.

Answer 4

Avoid absolute path like the plague. They WILL bite you one way or the other.

A project with absolute paths scattered around always break any attempt to automate build or to adopt any sound branching strategy.

The very first decision you have to take when creating an absolute path, that is, the drive letter, should tip you that it's a very, very bad idea. Surely, everybody has a C: drive. Well...

• I've seen machines with no C: drive mounted
• I've seen IT people lie about every machine having a D: drive, or haviong access to P: network drive
• I've seen repository switches overwrite work because that's the only way to have a working build
• I've seen countless hours lost trying to find all the places where the absolute path are stored when they needed a simple change

Don't do it. No matter what, don't.