ASP.NET Request Paths Reference

I decided to write down and document for myself the different paths provided by ASP.NET, to get a grip on the subject and a reference to turn to.

The path I will be requesting is:

This will be an ASP.NET-application named MyApplication in the IIS.


Here is the result returned by the Request-property of the page, which is a HttpRequest.

/MyApplication - Gets the ASP.NET application's virtual application root path on the server.

~/MyFolder/MyPage.aspx - Gets the virtual path of the application root and makes it relative by using the tilde (~) notation for the application root (as in "~/page.aspx").

/MyApplication/MyFolder/MyPage.aspx - Gets the virtual path of the current request.

/MyApplication/MyFolder/MyPage.aspx - Gets the virtual path of the current request.

/MyApplication/MyFolder/MyPage.aspx - Gets the virtual path of the current request.

- Gets additional path information for a resource with a URL extension.

C:\Visual Studio Projects\MyApplication\ - Gets the physical file system path of the currently executing server application's root directory.

C:\Visual Studio Projects\MyApplication\MyFolder\MyPage.aspx - Gets the physical file system path corresponding to the requested URL.

/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue - Gets the ASP.NET application's virtual application root path on the server.


Then there is the property Request.Url that returns a System.Uri , with all its properties. This is an interesting thing to explore as well.

/MyApplication/MyFolder/MyPage.aspx - Gets the absolute path of the URI.

Request.Url.AbsoluteUri: - Gets the absolute URI.

Request.Url.DnsSafeHost: - Gets an unescaped host name that is safe to use for DNS resolution.

Request.Url.Host: - Gets the host component of this instance.

/MyApplication/MyFolder/MyPage.aspx - Gets a local operating-system representation of a file name.

Request.Url.OriginalString: - Gets the original URI string that was passed to the Uri constructor.

/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue - Gets the AbsolutePath and Query properties separated by a question mark (?).

?QueryStringKey=QueryStringValue - Gets any query information included in the specified URI.

Request.Url.ToString(): - Gets a canonical string representation for the specified Uri instance.

Request also has the property Request.UrlReferrer which is of the type System.Uri and has the same properties as Request.Url. It has the following description: Gets information about the URL of the client's previous request that linked to the current URL.

C# 4: Reflected Dynamics

In Scott Hanselman's blog-entry titled Back to Basics: C# 4 method overloading and dynamic types , Scott talks about method-overloads in C# 4 and the dynamic -keyword.

class Program {
    static void f(Int32 x) { }
    static void f(dynamic x) {}
    static void f(Int32 x, dynamic y) {}
    static void f(dynamic x, Int32 y) {}
    static void f(Int32 x, dynamic y, Int32 z) {}
    static void f(dynamic x, Int32 y, dynamic z) {}
    static void Main(string[] args) {
        f(10); // Works - obvious
        f(10, 10); // Ambiguous - obvious
        f(10, 10, 10); // Ambiguous - not so obvious - since it should be possible to resolve

...the behavior is totally by design:

  • dynamic in method signatures doesn’t come into it: it behaves like System.Object does.
  • Given that, neither of the ternary signatures is better because each fits better than the other on some arguments (Int32 fits 10 better than object does)

The key point here, in bold, because it's significant is: having the type dynamic means "use my runtime type for binding".

It all becomes very clear when Reflector is used on the code. This loosens up some thought-patterns and makes it easier to really understand the dynamic -keyword.

Another way to look at this is with Reflector. This C# code:

static void f(Int32 x, dynamic y, Int32 z) {}

is essentially this, from a method signature point of view:

static void f(int x, [Dynamic] object y, int z) {}

and if there was a method that returned dynamic, it'd look like this:

[return: Dynamic]
        private static object GetCalculator() {}

C# Coding Style Conventions

From the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition).

I write this blog post as reference for myself and others. It's a summarized version of the chapter named 'C# coding style conventions' in above named book.

General Style Conventions

Brace usage

DO place the opening brace at the end of the preceding statement.

DO align the closing brace with the beginning of the line containing the corresponding opening brace, unless closing a single-statement block.

DO place the closing brace at the beginning of a new line.


CONSIDER single statement blocks that have braces that begin and end on the same line. Property accessors often use this style.

public int Foo{
    get{ return foo; }
    set{ foo = value; }

CONSIDER single accessor properties having all brackets on the same line.

public int Foo{ get { return foo; } }

DO place the closing brace on its own line, unless followed by an else, else if or while statement.

    } while(someOtherCondition);

AVOID omitting braces, even if the language allows it.

Braces should not be considered optional. Even for single statement blocks, you should use braces. This increases code readability and maintainability.

for(int i=0; i<100; i++){ DoSomething(i); }

There are very limited cases when omitting braces might be acceptable, such as when adding a new statement after an existing single-line statement is either impossible or extremely rare. For example, it is meaningless to add a statement after a throw statement.

if(someExpression) throw new ArgumentOutOfRangeException(...);

Another exception to the rule is braces in case statements. These braces can be omitted as the case and break statements indicate the beginning and the end of the block.

case 0:

Space Usage

DO use one space after the opening and before the closing of braces.

public int Foo{ get{ return foo; } }

AVOID using space before the opening braces.

Preferred:  if(someExpression){
Acceptable: if(someExpression) {

DO use a single space after a comma between parameters.

Right: public void Foo(char bar, int x, int y)
Wrong: public void Foo(char bar,int x,int y)

AVOID using space between arguments.

Preferred:  Foo(myChar,0,1)
Acceptable: Foo(myChar, 0, 1)

AVOID using spaces after the opening or before the closing parentheses.

Preferred:  Foo(myChar,0,1)
Acceptable: Foo( myChar,0,1 )

DO NOT use space between a member name and opening parenthesis.

Right: Foo()
Wrong: Foo ()

DO NOT use spaces after or before the brackets.

Right: x = dataArray[index];
Wrong: x = dataArray[ index ];

DO NOT use spaces before flow control statements.

Right: while(x==y)
Wrong: while (x==y)

AVOID using space before and after binary operators.

Preferred:  if(x==y){ ... }
Acceptable: if(x == y){ ... }

DO NOT use space before or after unary operators.

Right: if(!y){ ... }
Wrong: if(! y){ ... }

Indent Usage

DO use 4 consecutive space characters for indents.

DO NOT use the tab character for indents

DO indent contents of code blocks.


DO indent case blocks even if not using braces.

    case 0:


CONSIDER using the var keyword whenever the resulting type of the variable is obvious. Avoid using it if it decreases readability.

var names = new List<string>(); // good usage of var

string source = GetSource();
var tokens = source.Split(' '); // ok; most developers know String.Split

var id = GetId(); // probably not good; it's not clear what the type if id is

Naming Conventions

In general, we recommend following the Framework Design Guidelines for naming identifiers. However, there are some additional conventions and exceptions to using the Framework Design Guidelines for naming internal and private identifiers.

DO follow the Framework Design Guidelines for naming identifiers, except for naming private and internal fields.

DO use PascalCasing for namespace, type, and member names, except for internal and private fields.

DO use camelCasing for private and internal fields.

DO use camelCasing for local variables.

DO use camelCasing for parameters.

DO NOT use Hungarian notation (i.e., do not encode the type of a variable in its name).

AVOID prefixing local variables.

DO use C# aliases instead of Framework type names. For example, use int instead of Int32 and object instead of Object.


Comments should be used to describe the intent, algorithmic overview, and logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand the function's behavior and purpose. Although there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is desirable for most routines to have comments reflecting the programmer's intent and approach.

DO NOT use comments unless they describe something not obvious to someone other than the developer who wrote the code.

AVOID multiline syntax (/* --- */) for comments. The single-line syntax (// ...) is preferred even when a comment spans multiple lines.

DO NOT place comments at the end of a line unless the comment is very short.

public class ArrayList {
    private int count; // -1 indicates uninitialized array

File Organization

DO NOT have more than one public type in a source file, unless they differ only in the number of generic parameters or one is nested in the other.
Multiple internal types is one file are allowed.

DO name the source file with the name of the public type it contains. For example, String class should be in String,cs file and List<T> class should be in List.cs file.

DO organize the directory hierarchy just like the namespace hierarchy. For example, the source file for System.Collections.Generic.List<T> should be in the System\Collections\Generic directory.

CONSIDER grouping members into the following sections in the specified order:

  • All fields
  • All constructors
  • Public and protected properties
  • Methods
  • Events
  • All explicit interface implementations
  • Internal members
  • Private members
  • All nested types

DO use #region blocks around not publicly callable and explicit interface implementation groups.

#region internal members
#region private members

CONSIDER organizing members of each group in alphabetical order.

CONSIDER organizing overloads from the simplest to the most complex.

DO place the using directives outside the namespace declaration

using System;

namespace System.Collections{

Own additions

DO place namespaces that are not included in .NET Framework on their own separate lines below the .NET Framework namespaces and all in alphabetical order.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Xml;

using MyNamespace;
using MyNamespace.SubNamespace;

Visual Studio: C#-Settings & StyleCop

Design Guidelines for .NET development is something very close and dear to me. Partially for my own sake, but mostly to have consistency across a company, between friends and maybe even across blog-examples.

The tool StyleCop is Microsoft's tool for enforcing these guidelines.

StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project.

After asking a question Visual Studio C#-settings and StyleCop (MS Source Analysis) on Stackoverflow I set out to try to get C# in Visual Studio to behave as compliant as possible.

The result after some testing around was this Visual Studio settings file. You can easily import these settings to your own Visual Studio.

It's mainly about placements of parentheses and curly-braces.

Yes, it can be a bit of a hassle to get used to having the curly-braces on the same line as the namespace-declaration, the class-declaration and method-declaration, but it saves some space and I got used to it quiet quickly and now have problems going back.

namespace TestApp {
    public class TestObject {
        static TestObject() {
            if(true) {
            } else {

This is as close as I can get to the conventions. It's worth to note that StyleCop can differ a bit from the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries .