On the topic of deprecation, I came across this post today from Plip:
Do you use SqlCommand.Parameters.Add("@Name","Value"); ?
Well, you're in for a shock, it's been depricated in ADO.NET 2.0.
When you move to 2.0, you should instead be using: -
While the depricated code will still compile it will throw a compiler warning: -
System.Data.SqlClient.SqlParameterCollection.Add(string, object) is obsolete: Add(String parameterName, Object value) has been deprecated.
Use AddWithValue(String parameterName, Object value).
The depricated method will not work in .NET v-Next (2.0 +).
Now, for the life of me, I could not fathom the reason for this change - even though I am a big fan (some call me neurotic) of naming conventions. Well, here is the reason, as explained by Pablo Castro of the SQL Server team:
The problem is that both the C# and the VB.NET compilers will expose very weird behavior for this code:
you may expect this to use the overload that takes an object and assign the value 0 to it, but instead it will pick the overload that takes a SqlDbType as the second parameter! In order to avoid this (and potentially others) ambiguity between the Add(string, sqldbtype) and Add(string, object), we deprecated Add(string, object) and introduced AddWithValue(string, object). In general, having multiple overloads where the distinguishing parameter type is “object” in one of them is a dangerous thing to do.