Reusing Source Files in Multiple Visual Studio Projects

Sometimes you have a file F in a project P1, and you want to add it to your project P2 without actually getting a copy of the file. In Visual C++ you simple choose Add Existing Item, the rest is taken care of for you. However, in Visual C# (and maybe Visual Basic which I didn't test) even if you choose Add Existing Item and pick a file from an external folder, the file will be copied to your project folder.

I really find it awkward especially in case you have your files under version control. Luckily, I've just found a simple solution how you can share your source code between two or more projects without copying the files. At least for C# it works just perfectly. Furthermore, no 3^rd party software is required!

You still choose Add Existing Item, then in the File Open dialog box you select your file and press the small arrow on the Add button. You should choose the Add As Link menu item:



Then the your file reference should be displayed as an icon with a shortcut arrow in the solution tree:



Cheers,
Kirill

CodeProject Article: Exposing Events in ASP.NET Server Controls

I've just submitted an article to CodeProject. The article's main concern is adding events to your ASP.NET Server Controls. Although the topic may seem pretty straightforward, there are still some major optimization pitfalls that developers may not be aware of.
In this article I emphasize on using the Events collection. Code listings are provided in C#.

Cheers,
Kirill

An Elegant Way to Parse C# Enums

If you're like me, you find the standard .NET way to parse Enums pretty awkward:

string aStr = "Truncate";
FileInfo aFN = (FileInfo) Enum.Parse(
  typeof(FileInfo), aStr);

First, we have to provide the type of the enumeration twice. Second, I personally hate nested parentheses. I just cannot read the code with too many parentheses.

What I suggest is a thin wrapper:

public static class EnumParser<tEnum>
  where tEnum : struct
{
  public static tEnum Parse(string theVal)
  {
    return (tEnum)Enum.Parse(
      typeof(tEnum), theVal);
  }

  public static tEnum Parse(string theVal, tEnum theDef)
  {
   try                        { return Parse(theVal); }
   catch (ArgumentException)  { return theDef; }
  }
}

After several years of programming in C# I found I constantly use the exact same approach in most or all of my projects so I added it to my small C# toolkit.

The initial example would look more elegant with this new class in scope:

string aStr = "Truncate";
FileInfo aFN = EnumParser<FileInfo>.Parse(aStr);

The second overload allows us to use a default value:

string aStr = "Unknown";
FileInfo aFN = EnumParser<FileInfo>.Parse(
  aStr, FileInfo.Truncate);

The provided solution is good but not perfect. Let's create another version of the EnumParser class:

public static class EnumParser
{
  public static tEnum Parse<tEnum>(
    string theVal) where tEnum : struct
  {
    return (tEnum)Enum.Parse(
      typeof(tEnum), theVal);
  }

  public static tEnum Parse<tEnum>(
    string theVal, tEnum theDef) where tEnum : struct
  {
   try { return Parse<tEnum>(theVal); }
   catch (ArgumentException)  { return theDef; }
  }
}

As you see, we moved from a generic type to a non-generic type with two generic methods. Now let's look at the usage:

string aStr = "Truncate";
FileInfo aFN = EnumParser.Parse<FileInfo>(aStr);

The usage example when we don't specify a default value is almost identical to that of the generic type. However, things change significantly when a default value comes into play:

string aStr = "Unknown";
FileInfo aFN = EnumParser.Parse(aStr, FileInfo.Truncate);

As you see, we don't even specify the generic method arguments and the code will still compile successfully. The reason is: the compiler can resolve the arguments of the generic method from the argument that we specified. Our default value argument has now two roles: first, it is the value that will be returned in case the string is not recognized; second, it is an implicit type specifier for a generic method.

This is, of course, my favorite way to parse enums.

Cheers,
Kirill