Make sure to use Unix path separator while working with AWS .Net SDK

Ran into the following signature mismatch exception while trying to upload a file into a folder on using using AWS .Net  SDK.

“Amazon.S3.AmazonS3Exception : The request signature we calculated does not match the signature you provided. Check your key and signing method.”

Uploading files in the root of the bucket worked fine, but, the signature calculated by the SDK didn’t match the server calculated signature while trying to upload to a folder.  The problem turned out to be the path separator, AWS include object key while calculating request signature, but, the server is using ‘/’ as path separator, while the SDK uses whatever you set. Since most the .Net functions use ‘\’ to separate paths make sure to replace the separator while creating the request.

Using Unix style path separator fixed the problem.

Tip: Delete Unversioned Items

Having multiple branches of a project or multiple projects checked out makes it easier to quickly switch between them. But, one disadvantage of keeping multiple working copies checkout is that the temporary obj and binaries hog a lot of hard disk space, this becomes a major problem if you are using a SSD and don’t have a ton of free space.

Tortoise SVN can help you remove all the temporary files and reclaim that precious disk space, just right click on the working copy while holding the shift key down and choose “delete unversioned items”, this will display all the unversioned items and allow you to delete them.

Just make sure to uncheck “Use recycle bin”

SQLite.Net Custom Functions not getting registered after upgrading to .Net 4.5

SQLite’s ADO.NET adapter System.Data.SQLite supports for user defined SQL functions. New functions are implemented by deriving a class from SQLiteFunction class and applying SQLiteFunctionAttribute to it. At run time SQLite.Net reflects on all the assemblies loaded in the AppDoamin to automatically register all the use-defined SQL functions.

We have a few user-defined functions which we have been using for a long time without any problem. But, after installing .Net 4.5 on my system none of the user-defined function work. Somehow SQLite was not able to find the custom functions after the 4.5 upgrade. It turned out that in .Net 4.5 CLR Microsoft tweaked the order in which static constructors get called.

Here is the SQLiteFunction static constructor where all the user defined functions are registered.

In order to minimize the number of assemblies that need to be examined, the code only goes through types which reference System.Data.SQLite.dll. That’s a good idea, but, it does it in a weird way, it compares the referenced assembly name with the name of the assembly that called this method (GetCallingAssembly) , rather than the name of the assembly that contains this code (GetExecutingAssembly).

This never caused any problem in .Net 4.0 and older version because SQLiteFunction’s static constructors always got called from within its instance constructor.

But, in .Net 4.5, CLR calls the static constructor before the instance constructor.

And in this case the calling assembly is no longer the SQLite assembly itself, and therefore the SQLiteFunction’s static constructors skips all the user-defined functions.

Interestingly I was only able to reproduce the problem in an asp.net web application, somehow in console app static constructor gets called from instance constructor even in .Net 4.5.

The sample app I used to test this is available in GitHub here.

Fixing the problem should be easy enough, either replace GetCallingAssembly with GetExecutingAssembly and recompile the SQLite.dll or just manually register all the user defined functions using SQLiteFunction’s static RegisterFunction method.

UPDATE: SQLite.Net maintainers were quick to address this, mistachkin fixed it on the same day. Here is the url for sqlite.net ticket: http://system.data.sqlite.org/index.html/tktview?name=4e49a58c4c. Thanks mistachkin.

.Net Path Class Usage

ChangeExtension Changes the extension of a path string.

(C:\mydir\myfile.com.extension, .old)=> C:\mydir\myfile.com.old
(C:\mydir\myfile.com.extension, )=> C:\mydir\myfile.com.
(C:\mydir\, .old)=> C:\mydir\.old

Combine(String[]) Combines an array of strings into a path.

new[]{@"d:\archives", "2001", "media"} => d:\archives\2001\media
new[]{@"d:\archives", "2001", "\media"} => media (details)

GetDirectoryName Returns the directory information for the specified path string.

C:\MyDir\MySubDir\myfile.ext => C:\MyDir\MySubDir
C:\ => 

GetExtension Returns the extension of the specified path string.

C:\mydir.old\myfile.ext => .ext
C:\mydir.old\ => 

GetFileName Returns the file name and extension of the specified path string.

C:\mydir\myfile.ext => myfile.ext
C:\nydir => 

GetFileNameWithoutExtension Returns the file name of the specified path string without the extension.

C:\mydir\myfile.ext => myfile
C:\mydir\ => 

GetFullPath Returns the absolute path for the specified path string.

mydir => c:\temp\Demo\mydir [currentdir\mydir]
\mydir => c:\mydir

GetInvalidFileNameChars Gets an array containing the characters that are not allowed in file names.

Windows 7:
(",  0022) (<,  003C) (>,  003E) (|,  007C) (□,  0000) (□,  0001) (□,  0002) (□,  0003) (□,  0004) (□,  0005) (□,  0006) (□,  0007) (□,  0008) 0009 000A 000B 000C 000D (□,  000E) (□,  000F) (□,  0010) (□,  0011) (□,  0012) (□,  0013) (□,  0014) (□,  0015) (□,  0016) (□,  0017) (□,  0018) (□,  0019) (□,  001A) (□,  001B) (□,  001C) (□,  001D) (□,  001E) (□,  001F) (:,  003A) (*,  002A) (?,  003F) (\,  005C) (/,  002F) 

GetInvalidPathChars Gets an array containing the characters that are not allowed in path names.

Windows 7:

Windows 7:
(",  0022) (<,  003C) (>,  003E) (|,  007C) (□,  0000) (□,  0001) (□,  0002) (□,  0003) (□,  0004) (□,  0005) (□,  0006) (□,  0007) (□,  0008) 0009 000A 000B 000C 000D (□,  000E) (□,  000F) (□,  0010) (□,  0011) (□,  0012) (□,  0013) (□,  0014) (□,  0015) (□,  0016) (□,  0017) (□,  0018) (□,  0019) (□,  001A) (□,  001B) (□,  001C) (□,  001D) (□,  001E) (□,  001F) 

GetPathRoot Gets the root directory information of the specified path.

\mydir\ => \
myfile.ext => 
c:\mydir\myfile.ext => c:\

GetRandomFileName Returns a random folder name or file name

w143kxnu.idj

GetTempFileName Creates a uniquely named, zero-byte temporary file on disk and returns the full path of that file.

This method creates a temporary file with a .TMP file extension. The temporary file is created within the user’s temporary folder, which is the path returned by the GetTempPath method.

GetTempPath Returns the path of the current user’s temporary folder.

This method checks for the existence of environment variables in the following order and uses the first path found:
The path specified by the TMP environment variable.
The path specified by the TEMP environment variable.
The path specified by the USERPROFILE environment variable.
The Windows directory.

HasExtension Determines whether a path includes a file name extension.

myfile.ext => True
mydir\myfile => False
C:\myDir.ext\ => False

IsPathRooted Gets a value indicating whether the specified path string contains a root.

Path.Combine Quirk

Weird, Path.Combine ignores all the parameters preceding one which starts with ‘ \ ‘

SpecialFolders on different versions of Windows

Simplify Unit testing with Beyond Compare

Consider the following NullValueHandlingBlogPost unit test from Json.Net.

Assume you are maintaining this test and once fine Friday evening at 6pm (they always break @ 6pm) you get an alert from build system that NullValueHandlingBlogPost failed.

Description don’t match, but, that’s not the only difference, ReleaseCounteries is also different, so once you fix Description and run the unit test again you will find out about ReleaseCounteries and you can go ahead and fix that too. This was a trivial case, spotting similar differences in a complex xml is a lot more headache.

What if, rather than NUnit output strings, you get the following BeyondCompare diff screen whenever the expected and actual string don’t match.

Now isn’t this so much better, here I am launching launch Beyond Comapre if the expected and actual text does not match in the unit test, like this:

In a single glance you can spot all the differences and get a better understanding of the bug causing the unit test to fail. This saved me a good couple of hours trying to fix a unit test involving large xml configuration file. You can use any diff tool that you like, here @ B-Line Medical we are BeyondCompare fan, so I used that.  I added a couple of more methods to compare files and objects as well.

Checkout the BeyondCompare class’s source here.

Distinct Favor Latter

The default LINQ Distinct implementation returns the first of the duplicate items,

static IEnumerable<TSource> DistinctIterator<TSource>
(IEnumerable<TSource> source, IEqualityComparer<TSource> comparer) {
    Set<TSource> set = new Set<TSource>(comparer);
    foreach (TSource element in source)
        if (set.Add(element)) yield return element; 
}

Ran into a situation where I needed distinct elements based on some property and wanted to prefer the last item if duplicates are found. Turned out to be quiet simple:

public static IEnumerable<TSource> DistinctFavorLatter<TSource, TKey>
    (this IEnumerable<TSource> source, Func<TSource, TKey> keySelector)
{
    return source.ToLookup(keySelector).Select(group => group.Last());
}

A simple unit test:

[Test]
public void DistinctFavourLatter()
{
    var source = new List<Pair<int, char>>
                     {
                         new Pair<int, char>(1, 'a'),
                         new Pair<int, char>(2, 'b'),
                         new Pair<int, char>(3, 'c'),
                         new Pair<int, char>(4, 'd'),
                         new Pair<int, char>(2, 'e'),
                         new Pair<int, char>(4, 'f'),
                         new Pair<int, char>(5, 'g')
                     };

    var actual = source.DistinctFavorLatter(item => item.First);

    var expected = new List<Pair<int, char>>
                     {
                         new Pair<int, char>(1, 'a'),
                         new Pair<int, char>(3, 'c'),
                         new Pair<int, char>(2, 'e'),
                         new Pair<int, char>(4, 'f'),
                         new Pair<int, char>(5, 'g')
                     };

    CollectionAssert.AreEquivalent(expected, actual);
}

How to write maintainable enum switch statements

Get the source in VS 2010 solution here.

Using enum in switch statements is pretty common in C#. But, in large applications switch statements can become a maintenance nightmare, especially if the enum is used in multiple switch statements throughout the application.

Things starts fine, the enum and switch statements are usually created by the same developer around the same time, so the switch usually handles all the possible enum values appropriately. But keeping all the switch statements in sync with enum is very error prone, especially if you do not get any assistance from compiler. C++ compilers warns you about missing enum values in a switch statement, but, unfortunately C# does not, unexpectedly Resharper does not have code inspection for this warning either (There is an open issue though and you can up vote it here).

To guard against this, developers usually throw a NotImplementedException in the default clause of every switch statement.

But, if you don’t have good code coverage its quiet possible that this bug will not get caught during testing. To minimize the chance of that, I wrote EnumSwitch, which validates that none of the enum values are ignored by mistake. The following test case shows the basic usage:

EnumSwitch makes sure that all the enum values are either handled or explicitly ignored, it throws a NotImplementedExpcetion otherwise. In contrast to simply throwing exception in the default clause, EnumSwitch does error checking on every execution in order to detect missing enum values.

It also supports Default handler, just in case if some special handling is needed in the default case.

Only downside of this approach is a slight hit in performance, since compilers and CLR can produce more optimize code for vanilla switch statement as compared to EnumSwitch class, but, for any practical business application the minute performance hit is not an issue at all.

I think, it will be a little complicated to statically detect missing enum values in a switch using FxCop and StyleCop, but it should be simple enough to identify this situation using Rosyln. Will give Rosyln a try as soon as I upgrade to VS 2012 Professionals.

Get the source in VS 2010 solution here.

Use pseudovariable $exception rather than declaring an unused exception variable

Occasionally, I see catch blocks with unused exception variables.

Probably developer declare the variable so that they can inspect the exception while debugging, but, then forget to delete it. Since the unused variable results in a compiler warning (”The variable ‘ex’ is declared but never used”), its better to use pseudovariable $exception rather than declaring variable, if you need it just for debugging.

Visual studio also adds the variable to locals variables window by default.