Relative Path

Relative path is used a lot in Win32, and it makes sense. When I say relative path, I mean relative to the current directory. After all, there is no other directory that I can relative to.

But in .Net, we do have another one! And it is called ApplicationBase! Remember when we probe, we probe GAC, and ApplicationBase.

So we have current directory, and ApplicationBase. Now when I use a relative path, what exactly is the path relative to? Current directory, or ApplicationBase?

There is no possible way that .Net framework can know in every situation. But it has to figure something out for you. And it tries its best to guess what exactly do you mean.

So in some cases, it uses ApplicationBase. In some other cases, it uses current directory.

For example, if you call Assembly.LoadFrom(”foo.dll”), it will look in ApplicationBase. If you have a config file,  and with a relative path in codebase hint, it will look in ApplicationBase.

Now what about AppDomain.SetCachePath()?

It uses the current directory as the parent directory. Surprise!

The thing is, relative path is ambiguous at best. Avoid them whenever possible.

Comments

• Anonymous
  May 04, 2004
  I can't throw away relative path-it's most powerful feature in present "distributed" world for "scoped" scenarios,web programming particularly depend on it.
• Anonymous
  May 04, 2004
  Not saying you throw away relative path. What I suggest is that you should figure what is the full path at runtime and pass it to the APIs, instead of relying on the framework to make its guess.
• Anonymous
  May 10, 2004
  Relative paths are useful. The current working directory is not. It's a global variable shared amongst all threads so even if you try to have the discipline to set it prior to calls dependent on the CWD, another thread may change it (with the same well-intentioned logic).
  
• Anonymous
  May 28, 2004
  hi hi hi h