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 have been working quite a bit with doing XSLT on some large XML files lately.
During this I worked with the XslCompiledTransform class in .NET, which make transformations really easy and it works very fast.

An advantage of this class is also that it enables you to utilize scripts within your XSLT file, which enables you to make for example C# functions, for various tasks. I’ll write more about that in a later blog entry to keep this one simple and to the point.

The syntax (in vb.net) for doing a transformation using XslCompiledTransform is as simple as the following:

    'Create settings which eanble scripting in the XSLT file
    Dim xmlSettings As New XsltSettings
    xmlSettings.EnableScript = True
    'create a XML reader for the XLST file
    Dim xsltFile As XmlReader = XmlReader.Create("XSLT FILE")
    'create a Transform object
    Dim xslTransform As New XslCompiledTransform
    'Load XSLT file with Settings into transform object
    xslTransform.Load(xsltFile, xmlSettings, Nothing)
    'Do the transformation.
    xslTransform.Transform("INPUT XML FILE", "OUTPUT XML FILE")  

The main disadvantage I’ve found for using this transformation is the huge memory usage it uses.
In my own situation, the process used about 3.5 times as much memory as my source XML file, meaning that a source file about 450MB my .NET process was killed on a 32 bit computer with an out of memory exception.

The actual memory usage will of course vary depending on how complex your transformation is, so the 3.5 number is not meant to be nothing more than an indicator that it is memory intensive.
It is however very fast, and I managed to transform very large files in a manner of seconds, thus if you can live with the memory consumption it is quite effective.