Troubleshooting Tips

LANGUAGES: All .NET Languages

ASP.NET VERSIONS: 1.0 | 1.1

 

Work With Relative Paths

Learn to write apps with paths that are tolerant of structural movements.

 

By Don Kiely

 

I realize that all applications by readers of asp.netNOW are carefully crafted, well-designed and architected, and implemented flawlessly, so that the project hierarchy is efficient and logically laid out. As true as that may be (or not, in my case!), the sad fact is that things change. They may change during development or for the next version, and you have to move aspx pages and other resources around. The problem is that it's all too easy to write paths into the app that are intolerant of structural movements.

 

For example, you might reference another page in your app, such as to redirect to the page, using this syntax:

 

/Catalog/Sports/Skijoring/Skis.aspx

 

This will redirect to Skis.aspx, located off the default Web location (probably c:\inetput\wwwroot) and down the directory structure through the Catalog, Sports, and Skijoring directories. But when you move Skijoring from Sports to DogSports, you have to go through and find all those references everywhere in your app and change them - or else you'll have broken links in your app.

 

One solution to this rigidly hard-coded path is to use relative paths to get to the page, something like this:

 

Catalog/Sports/Skijoring/Skis.aspx

 

Now ASP.NET will look in the Catalog subdirectory of the directory of the current page, and travel down from there to get to Skis.aspx. This is a bit more robust, because if you copy the current directory and its subdirectory hierarchy to another location, the link to Skis.aspx will still work, because the relative location of Skis.aspx to the current page doesn't change. But it may change for other pages in the app that aren't in that hierarchy but reference Skis.aspx.

 

This starts to really become an issue when you develop an application locally in your default Web site but then deploy it to a hosted server. Such servers commonly create a directory structure based on the user, putting the virtual directory in a location other than the c:\inetput\wwwroot directory. In that case, it's a sure bet that any paths that start with a / are going to break when you deploy them.

 

By some estimates, ASP.NET has about 30 functions to handle paths and relative paths in Web applications. The most commonly used is probably the System.Web.UI.Page class' MapPath method, which returns the physical path that a virtual path maps to, using either the virtual or absolute paths I showed above. You can learn more about your options in the Understanding Paths in ASP.NET article listed in the references section below.

 

The Mighty Tilde

But one of the best kept and largely undocumented secrets in ASP.NET is the tilde character (~). The tilde is actually a shortcut notation for the HttpRuntime.AppDomainAppVirtualPath property, which, according to the .NET documentation, "returns the virtual path of the directory that contains the application hosted in the current application domain." Another way to say it is that the ~ refers to the root of the virtual Web application, not the root of the Web server. The difference is subtle but crucial. It means that you can use a ~ to start the paths in your application and no matter where you move the application it will find the referenced files without problem.

 

Now you can reference the Skis.aspx page like this:

 

~/Catalog/Sports/Skijoring/Skis.aspx

 

The page still needs to be under the Catalog directory of the application root directory, and down through Sports and Skijoring, but at least you can deploy your app wherever you want and it will still work great, getting badly needed skis out to the skijorers of the world.

References

 

Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, Alaska. E-mail him at mailto:donkiely@computer.org.