Referencing other ASP.NET pages symbolically, with compile-time checks?

I'm noticing code accumulating in my project that looks like this:

Response.Redirect("/Foo/Bar.aspx");

This seems brittle -- if I move or rename Bar.aspx file, I need to find places where I've referenced it and correct those string constants, both in markup and codebehind. It seems like their should be a better way. Something like:

Response.Redirect( MyNamespace.BarPage.Get开发者_开发知识库Url() );

In other words, let the 'stack' figure out the URL I need. Note: I know that I can consolidate references to a particular page with a hand-coded BarPage.GetUrl() method, but even that seems failure-prone.

Isn't there a better way?

The best way would be to resource them. Add a meaningful key and the URL value to the resource file, and redirect that way.

Response.Redirect(Properties.ASPXUrls.FooBar);

The problem you'll face is that there's no real inherent link between a code-behind and it's code-infront except the <%@Page %> directive. There's no real reason a codebehind has to even have the same class name as the code-infront's file name, it only happens because it's convention and it's how the auto-generator lays it out.

This means you're not going to find anything you can reference at compile-time that even knows what aspx the .cs links to. The closest thing you'll find is the typeof(MyNamespace.BarPage).FullName which will give you the code-behind's name and by assuming things follow convention you could (but I don't recommend) construct the URL for the code infront page it's associated with.

Personally I think you're better off just doing a find-all for "barPage.aspx" when you rename it and doing a little refactoring. You'll have to deal with hyperlinks in the code-infront anyway. If barPage.aspx represents some abstract concept (Like "The login page") it may help to add a property for it, but if barpage is just another page with no real globally inherent meaning I'd leave it as-is.

I'd recommend creating a static class with different properties for each of the links. That way, you only have one place to update.

Redirects in general are fragile, no matter how you get the name of the next page. They are also a performance problem.

If you find them collecting in your system, the first question you should really ask is why: excessive redirects are almost always a sign of an architectural problem.