Little Gotcha in VS 2010

If you have a class library, and you want to write a Console app to test your class lib with, you might find you get a compile error that doesn't make sense:

The type or namespace name 'MyClassLib' could not be found (are you missing a using directive or an assembly reference?) 

This could be caused by the target framework being set to "client"

Here's how to fix it:

1. Right click the console app project, and select Properties (at the bottom of the menu).
2. Select the Application tab on the Property page
3. Check the Target Framework - make sure it is NOT .Net Framework 4.0 (or 3.5, if that's what you are using).
4. If it is client, you can just select the correct framework - in my case .Net Framework 4.0
5. When you select the new Framework, you will get a warning about unloading the project.  Who cares, it's wrong anyway!  :-)

How To Tell If a Request Is An AJAX Request (Microsoft MVC)

There might be times when you want to handle an AJAX http request differently than a "normal" http request.

It's really quite simple - just check the request header!

if (Request.Headers["X-Requested-With"] != null
    && Request.Headers["X-Requested-With"] == "XMLHttpRequest"){
   // if here this is an AJAX Request
}

The point is, take a look at the Headers attribute of the Request and check using the code above.

Hope this post saves someone some time!

APIs and Method Deprecation

One of my current projects requires the use of a Library for document conversion and manipulation.  This company has some very good products and they are in a complicated space - one that's always changing.  Like most library vendors, they are looking for ways to improve their offering.  With improvements, comes change...

That said, they are not very experienced at .Net.  Most of their libraries are unmanaged DLLs and their support for .Net clients is with a managed DLL that is a thin adapter around the unmanaged DLL.

Consider this call:  lib.DoSomething(string FileName, int Param);
In earlier versions of their libraries, I would pass in a file name and the param and all was good in the world.

In the newest version, the signature has not changed, but you are not supposed to pass in a file name!  You should only pass "" (an empty string).

In other words, the only valid way to call this method is
 lib.DoSomething("", myInt); 

To add insult to injury, this silently changed between versions!  

There are a lot of things wrong with this approach:

1. They are causing runtime errors for anyone who doesn't change their code
2. No one would think about changing their code unless they just happened to catch the change on page 43 of their doc. (and we *all* read the doc, right?) :-)
3. The method signature doesn't really match the intent.  (Why should I have to pass a parameter when only one value is ever valid - especially when it's a null value?) 

For all intents and purposes, they really want to deprecate this method, but they were not quite sure how to go about it.

What is the right way to deprecate a method in an API in .Net?

You should not kill a method right away.  Give your customers time to change their code to match your changes.  Honestly, if you can avoid deprecation, you should.  In the cases where it is unavoidable, you should use this pattern.

First, mark your deprecated method with the [obsolete] attribute.

[Obsolete("This method is obsolete; use method DoSomething2 instead. This method will become unsupported in version x.y")]
public void DoSomething(string Filename, int Param)

Create the replacing method - it should have a different signature.
public void DoSomething2(int Param)

With this pattern, there is no chance that your changes will cause a runtime error!  Instead, your customers will see compiler-time errors/warnings which is definitely preferable.