System.BadImageFormatException was unhandled
Message: Could not load file or assembly SomeTool.exe' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

Normally you see this exception if the machine doesn’t have right run time installed. But this was obviously not the case. Changing build to x86 or x64 didn’t made any difference either. Next I ran peverify.exe which happily reported that there was nothing wrong with the binary image. Finally I needed to pull out the big guns, ask fuslogvw, which would show me if there are any dependent assembly binding that was failing. But that also didn’t produce any boom sounds.

So the last resort was to just meditate over the issue for few minutes. And that works. In a sign of enlightenment I saw app.config buried along with bunch of files and it had these lines:

<?xml version="1.0"?>
<configuration>
<startup><supportedRuntime version="v2.0.50727"/></startup></configuration>

Aha! Apparently the app.config doesn’t get updated (may be because it was in TFS?) when VS did the 4.0 upgrade. As app.config didn’t had anything else, just deleting this file solved the issue. I do wonder how many people come across this gotcha.

• Apparently resetting identity using DBCC CHECKIDENT can be expensive operation if you are also deleting all items from the table. One way to reduce time is use TRUNCATE TABLE before DBCC CHECKIDENT.
• I prefer table variables instead of temp tables but one place temp tables are required is if you have lots of data in them and want index!
• Data Tuning Wizard would come out with zero suggestions on many occasions but it does not mean there are no significant optimizations possible. The best way to “guess” possible index is to have index for all columns used in join and use INCLUDE clause that has columns accessed in SELECT. This last thing does attracts even the least interested query plans to use the index :).
• If you have temp tables, it’s usually better to create index after you have inserted data instead of before.
• If you have complex sproc, SQL Server Profiler will spit out thousands of trace lines during the run. A quick way to pin point the SQL statements needing performance tuning is to use File > Save As to put the trace results in to a table. You can use then following query that immediately surfaces culprits. Notice that statements which run in WHILE loop might take less time individually but collectively their duration sum may be higher. Below query would reveal this culprits immediately.
  
  select SUBSTRING(TextData, 1, 4000), SUM(duration), COUNT(1)
  from [SavedTrace]
  group by SUBSTRING(TextData, 1, 4000)
  order by 2 desc

One of the big performance hits occur when you must process individual rows one at a time instead of in set. For instance, let’s say you have a table with a column that has comma delimited values. Now you want to split these values in each cell and create a new table which would have N rows for each row in original table – one for each spitted value. The Internet is littered with dozen ways to split strings in TSQL, some even uses CTEs (not a good idea because there are lots of gotchas like max recursion limit). So far the best way is to use SQL CLR with code like below. Its as fast as any native TSQL juggling, if not faster. However most important thing here is not SQL CLR but how you use this table valued function and here’s the secret: The best bang for the performance you would get is using CROSS APPLY (or OUTER APPLY) with table valued UDF.

public partial class UtilityFunctions
{
    [Microsoft.SqlServer.Server.SqlFunction(FillRowMethodName = "FillRow", TableDefinition="StringPart nvarchar(max)", 
        IsDeterministic=true, IsPrecise=true, SystemDataAccess=SystemDataAccessKind.None)]
    public static IEnumerable ClrSplitString(SqlString sqlStringToSplit, SqlChars delimiter, SqlBoolean removeEmptyEntries)
    {
        if (!string.IsNullOrEmpty(sqlStringToSplit.Value))
        {
            return sqlStringToSplit.Value.Split(delimiter.Value
                , (StringSplitOptions)(removeEmptyEntries ?
                        StringSplitOptions.RemoveEmptyEntries : StringSplitOptions.None));
        }
        else
        {
            return null;
        }
    }

    public static void FillRow(object obj, out SqlString splittedString)
    {
        if (obj != null)
            splittedString = new SqlString((string)obj);
        else
            splittedString = SqlString.Null;
    }
}

If you are generating or working with very large proxies then you might see following error:

Exception: InvalidOperationException
Message: Unable to generate a temporary class (result=1).
error CS0001: Internal compiler error (0xc00000fd)
error CS0003: Out of memory

This error typically occurs when .Net infrastructure attempts to generate *XmlSerializers.dll on the fly. To do this csc.exe is spawned off and if your proxy is too large then it might error out with a message like above. This seems to be a bug in csc and reportedly it might get fixed in .Net 4.0.

Meanwhile, here’s how you can workaround it:

First make sure all your classes that are derived from SoapHttpClientProtocol (i.e. the proxy classes) are decorated with WebServiceBindingAttribute. If you have a whole class hierarchy that derives from SoapHttpClientProtocol then all classes in that hierarchy must be decorated.

Next, for all the projects that contains classes derived from SoapHttpClientProtocol, turn “Generate serialization assembly” option on Build page to ON. Remember you will need to do this for Debug as well as Release mode or your code will fail in production.

Now you are set. The *XmlSerializers.dll will be generated and signed+versioned automatically (if your project is signed and versioned) when you do build and csc.exe won’t get spawned to cause above error.

Few more things to keep in mind:

• One of the “popular” workaround in some forums is to switch IIS app pool for WCF to 32-bit. I wouldn’t advise this because you loose all the advantage of 64-bit, primarily, access to all the memory available on server.
• Above error often occurs for Microsoft Dynamics CRM proxies if you have tons of entities and attributes.
• If your code is running as plugin then you might have plugin DLLs hosted at different location than main app exe. An example of this is Microsoft Dynamics CRM plugins that gets hosted by CRM Async service. In this case, you need to copy the *XmlSerializer.dll generated after the build to same location as host exe otherwise it won’t be found by .Net infrastructure!
• If you are using Visual Studio integrated debugging feature for WCF services then you must run Visual Studio as Administrator or above error will pop its ugly head when you are debugging.

If above steps doesn’t solve your problem then you might have to dig deeper using techniques described here, watching binding errors from fuslogvw or attempt to generate Xml serilizer DLL manually using sgen.

try
{
    //some code
}
catch
{ }

How about if we can replace above code with following:

IgnoreExceptionButNotIfDebugging(() =>
{
    //some code
});

Better.

The mysterious IgnoreExceptionButNotIfDebugging is a simple method that takes lambda and it would look like below:

public static void IgnoreExceptionButNotIfDebugging(Action codeBlockToExecute)
{
    try
    {
        codeBlockToExecute();
    }
    catch (Exception ex)
    {
        if (Debugger.IsAttached)
            Debugger.Break();

        Trace.Write("Exception occured: " + ex.Message);

        EventLog.WriteEntry("MyApp", ex.Message, EventLogEntryType.Warning);

#if DEBUG
            throw;
#endif
    }
}

Now you can surround any of your code by IgnoreExceptionButNotIfDebugging and make sure things don’t remain silent when you are debugging!

So if you really had to go ahead with this crazy idea of sending DataTable over WCF then here’s the somewhat more efficient serialization technique you can use. The basic idea is to use binary serialization of DataTable and pass that serialized data as byte array along with the schema information so the client can reconstruct it on other end. It’s needless to say that doing this would invariably restrict your WCF clients to .Net so you might also want to include other web method for other clients.

And here’s the deserializer to go with it:

How efficient is this? It really depends on your data. For instance, with some of my test data with 10K rows I could get about 6X smaller payload size and 30% faster serialization. But as number of rows increases, the speed advantage diminishes compared to built-in XML serializer that you can access via ReadXml/WriteXml. For example, for a million row, above method still gives me 4X smaller payload but serialization is actually 3X slower than built-in XML serializer. So experiment before you go either way!

long t = DateTime.Now.Ticks;
 Console.WriteLine((new DateTime(t)).ToString("o"));
 Console.WriteLine((new DateTime(t, DateTimeKind.Local)).ToString("o"));
 Console.WriteLine((new DateTime(t, DateTimeKind.Unspecified)).ToString("o"));
 Console.WriteLine((new DateTime(t, DateTimeKind.Utc)).ToString("o"));

Prints followings when actual date time is 2009-11-08T17:16:13.7791953 PST:
2009-11-08T17:16:13.7791953
2009-11-08T17:16:13.7791953-08:00
2009-11-08T17:16:13.7791953
2009-11-08T17:16:13.7791953Z

If you use "r" instead it would print followings:
Sun, 08 Nov 2009 17:26:02 GMT
Sun, 08 Nov 2009 17:26:02 GMT
Sun, 08 Nov 2009 17:26:02 GMT
Sun, 08 Nov 2009 17:26:02 GMT

This is similar to Unix commands like WHICH and WHEREIS.

Type amount of indentation you need. It’s typically 5” for letter size:

And you have right aligned address!

select top 1 *
from table
order by newid()