I experienced the following rather unhelpful exception at work today.
Padding is invalid and cannot be removed

With a stacktrace something along the following:

System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast) +7596702
System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount) +208
System.Security.Cryptography.CryptoStream.FlushFinalBlock() +33
System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo) +225
System.Web.Security.FormsAuthentication.Decrypt(String encryptedTicket) +246

After doing some searching and more or less complex debugging, and resetting the application pool and what not, I find the simple solution.

I had two projects running on my localhost which both used the default cookie name for forms authentication, which then apparently conflicted with each other. Do’h.
But well, problem solved.

Today I was faced with a problem where the close method on a SQLDataReader took ages – well 10 seconds or so – to complete.

Then I read the following snippet from the documentation:
The Close method fills in the values for output parameters, return values and RecordsAffected, increasing the time that it takes to close a SqlDataReader that was used to process a large or complex query. When the return values and the number of records affected by a query are not significant, the time that it takes to close the SqlDataReader can be reduced by calling the Cancel method of the associated SqlCommand object before calling the Close method.
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqldatareader.close.aspx

So I tried calling cancel on the command prior to closing the reader and presto – the SQLDataReader closed very fast.

Once again, reading the documentation solved my problem and from this day on, I'll try to cancel the command prior to every close, just to see if it saves some time :)

I mentioned in my last blog post that you can use scripts in XSLT, so I just wanted to show shortly how you can use scripts to show the power it can yield.
Firstly – add a namespace to your XSLT file:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:msxsl="urn:schemas-microsoft-com:xslt"
                xmlns:scripts="urn:scripts.this">

Then you can use the scripts in various situations.
For example, I had to parse some "Yes" and "No" into Boolean strings "true" and "false" (for business logic reasons) so I made a script for that in the bottom of my XSLT file (I made the scripts in C# syntax):

<msxsl:script language="C#" implements-prefix="scripts">
    <![CDATA[
        //return true or false as string instead of "yes" and "no"
    public string getBooleanString(string s0)
    {
      if ((String.Equals(s0, "yes", StringComparison.OrdinalIgnoreCase))
      { return "true"; }
      if (String.Equals(s0, "no", StringComparison.OrdinalIgnoreCase))
      { return "false"; }
      return s0;
    }
    ]]>
</msxsl:script>

Now, I could use this script in my XSLT matching like this:

<xsl:value-of select ="scripts:getBooleanString(./VALUE)"/>

This makes a call to the C# script “getBooleanString” with the value, the script will test it for “Yes” and “No” and return “true” or “false” respectively, or the string itself it it wasn’t one of the two.
Some of the other things I used this for was to compare strings case with case insensitive, and to hold temporary values to avoid having to run through my XSLT file multiple time in the transformation process.  I also had to convert some number formats to use period as decimal point instead (due to language specific settings), so I made a script which changes between period and comma.

It is a powerful tool to have in the XSLT toolbox.