Lines are represented differently in different operating systems. For most non Unix Platforms the new line is represented as: "\r\n" And for Unix Platforms the new line is represented as: "\n" I've found that most developers will hard code these values into their code, for example:

string someText = String.Format("This is a line1.{0} This is line 2.", @"\n");

That works, but there is a built in property in the .NET Framework to retrieve the current platforms New Line. This property is Environment.NewLine. Here's an example, using the same code above, but with Environment.NewLine in place of the hardcoded value.

string someText = String.Format("This is a line1.{0} This is line 2.", Environment.NewLine);

This property will return the new line string defined for the environment that the application is running in.

I've been looking through a lot of "hand me down code" (code that was written awhile ago by someone else) that did a lot of File IO. The code works well, but at times its hard to read the really long file paths that they're using. As you know, file paths in C# have to be escaped, otherwise the compiler will think that you're trying to escape a character. So a double backslash actually equates to a single backslash when compiled. This can be cleaned up a bit. Read on brethern...

This is how the file paths look now:

// Current File Paths
string path = "c:\\directory\\folder1\\folder2\\folder3\\somefile.txt";

To make this cleaner, use the "@" symbol at the beginning of the string literal and it will escape the characters for you.

// New File Path
string path = @"c:\directory\folder1\folder2\folder3\somefile.txt";

Simple, but a lot of programmers dont know this little time saver.

NOTE: using the @ symbol when you need to included \t or \r, \n will not work. It will interepret the characters just as they are "\n" will print on the screen as "\n" not the new line that you're probably expecting.

Warning:
A: To give notice to beforehand especially of danger or evil
B: To give admonishing advice
C: To call to one's attention

With that said, we could infer that a warning is something that says "Hey, this is kind of important, you might want to watch this." To me, in .NET Development, a warning means I've done something wrong, I've created an error.

To ensure my builds are top notch, I have updated my projects to treat Warnings as Errors. This allows me to be notified of something immediately. If a warning occurs, its foresight into the future. Warning: "This is what could happen." Pretty much that means, you should probably fix that right now. Therefore I dont let builds complete if there are warnings in certain projects.

Here's how to do it...

1. Go to the project properties and select the Build Tab.
2. Select "All" under Treat Warnings as Errors
   

3. Save and build.

Now, lets say you have a variable thats created but not used in a method somewhere, you'd get an error screen like this:



The build will fail locally as well as on your build server.

This will help alleviate errors in the future that may be caused by something that was a warning two months ago. :)

You can also accomplish through the command line compiler:

csc.exe /warnaserror

This compiler switch will treat warnings as errors.

*Note: You might want to leave this option in its default state for projects where a warning is ommitted automatically, like set up projects that publish to a local system. This is something that I'm ok with as we publish it locally anyway.

Retrieving the ASP.NET filename can be done in many ways. I've created this method in a few helper classes in some of the different jobs I have.

public string GetCurrentPageFileName()
{
   return new System.IO.FileInfo(Request.PhysicalPath).Name;
}

I've also created a base page class in the past to hold these types of methods (below).

/// <summary>
/// Base Page class
/// </summary>
public abstract class BasePage : System.Web.UI.Page
{
    protected string GetCurrentPageFileName()
    {
        return new System.IO.FileInfo(Request.PhysicalPath).Name;
    }
}

Throw this into the App_Code folder and change your default page implementation from System.Web.UI.Page to BasePage. You'll have all the same methods you did before, but this time with the extra methods. Add more functionality into the BasePage as necessary.

Sometimes there are methods in code that my development department knows are robust. There are no bugs in the code. This might be helper methods that have been tested time and time again. Therefore we know we dont need to debug these methods 99% of the time. To alleviate the pain of stepping through unnecessary lines of code accidentally you can inform the debugger that it is not suppossed to access a block of code. To do this add the DebuggerHidden Attribue. You cannot set a break point in this block of code when this attribute is present.

[DebuggerHidden]
void DoSomething()
{
// Do Something
}

*Note: This is only valid on constructors, methods, properties, and indexers only.