Reading a text file (or JSON file) from a Windows 8 Runtime application

I just had need of reading a small JSON file into a Windows 8 application using the Windows Runtime.

Uri uri = new Uri("ms-appx:///assets/data.json");

var storageFile = await Windows.Storage.StorageFile.GetFileFromApplicationUriAsync(uri);

using (var storageStream = await storageFile.OpenReadAsync())
using (Stream stream = storageStream.AsStreamForRead())
using (StreamReader reader = new StreamReader(stream))
var jsonText = reader.ReadToEnd();
var results = JsonConvert.DeserializeObject<DemoData>(jsonText);
this.DataContext = results;

What seemed like it should have been a common example on MSDN was not …, and after a bit of searching and reading, I believe the above code represents at least a common and safe way of loading data.

I’ve got a file called data.json stored in an Assets folder:


And the file’s Build Action is set to Content:


Change the value passed to the Uri constructor and … the file will be loaded successfully. Once loaded, I used the strongly typed generic DeserializeObject method to convert the Json data to a class called DemoData.

Using Sqlite and C# to determine if a specified table exists

I had need of a bit of code in C# to determine whether several tables in a Sqlite database had been created, so …

public static class DbExtensions
    /// <summary>
    /// Determines whether the table exists
    /// </summary>
    /// <param name="connection">Existing, opened, database connection</param>
    /// <param name="tableName">The name of the table to test for.</param>
    /// <returns>True if table exists.</returns>
    public static bool TableExists(this IDbConnection connection, string tableName)
        Debug.Assert(connection != null);

        var cmd = connection.CreateCommand();
        cmd.CommandText = @"SELECT COUNT(*) FROM sqlite_master WHERE name=@TableName";
        var p1 = cmd.CreateParameter();
        p1.DbType = DbType.String;
        p1.ParameterName = "TableName";
        p1.Value = tableName;

        var result = cmd.ExecuteScalar();
        return ((long)result) == 1;

Nothing too complex … only determining that the list of tables is stored in a system table named sqlite_master. If you want to find all indexes that have dependencies on a specific table, you can instead use the column tbl_name.

If you’re using Dapper and the DapperExtensions, you might find this useful:

_connection = new System.Data.SQLite.SQLiteConnection();
DapperExtensions.DapperExtensions.SqlDialect = new DapperExtensions.Sql.SqliteDialect();
_connection.ConnectionString = new DbConnectionStringBuilder()
    {"Data Source", "thumbnailer.db"},
    {"Version", "3"},
    {"FailIfMissing", "False"},

First, it creates the SQLite connection (nuget) and then configures the DapperExtensions to use the SqliteDialect. What that means is that the extensions will generate SQL that actually works! 🙂 Finally, in my case, I wanted the DB to be created if it didn’t exist, so I set FailIfMissing to False.

Modern C++, iterators and loops compared to C#

It has been a while since I looked much at modern C++. I’ve started intentionally simple and was exploring some of the ways that a simple list can be iterated. I hate to say this, but I remember the days when the standard template library was not necessarily something that was the easiest to get working on Windows with a Microsoft C++ compiler in a simple, safe and reliable way. My, how times have changed for the better!

While the overall syntax of C++ lacks the refined and designed elegance of a C# application, it has come a very long way!

I’ve thrown together a simple sample. The code creates a list of strings, pushes (not add, arrgh!) strings onto the list, and then iterates through the list in three similar, but syntactically different methods below:


OK, there’s a few awesome things here that make C++ much more approachable these days:

  1. a decent string class! No more hunting for a library or header file that has most of the functionality you need. (there’s a wstring as well for wchar_t needs)
  2. All the common Data structure types like list, map, vector, etc… that you might need without writing them your self.
  3. With using, the code doesn’t need to refer to types with namespaces (much like C#). So, instead of std::list<std:string>, it’s just list<string>, which I consider far more readable at a glance.
  4. No weird casting or worrying about strings when values are passed to the push_back function. Again, it just works.
  5. auto – the var of C# is called auto in C++. If I hadn’t used auto in the first iterator, the code would have declared the type as list<string>::iterator. While not terrible, auto reads well, as it’s likely that I’ll not need the detailed declaration to understand what’s being iterated upon.
  6. Second option is just syntactical sugar as it internally uses a standard for loop like in the first example internally. But, you’ll note there are anonymous functions/lambdas! The square [] brackets is the capture clause of the lambda expression. Unlike C#, where the compiler automatically determines what outer scoped variables will be used by the inner lambda function, in C++, it’s necessary to explicitly declare what is required. While this is a bit annoying, there are times where this extra declaration might cause programmers to think twice about all of the variables that are required in the lambda expression. In this instance, there aren’t any variables needed, so it’s empty.
  7. The last example is the most concise, and maybe a little less friendly at first and that’s mostly due to the heritage of C++ and how to make code most efficient. It’s called a range-based for statement. First, the code is using auto again and the type is a string as it’s declaring the type used within the list. The & symbol remember is a reference and the const is indicating that the value will not be changed by the inner block. These two together ideally make it so the value is observed in-place, without any need for a copy.

While the range-based for statement isn’t quite as readable as C#:


I think you might agree that the C++ version is more than passable, and nearly friendly!


(Aside, there is a shortcut initializer list syntax that can be used with non-aggregate types in C++, so an int for example that would have gotten rid of the calls to push_back).

How to rewrite a MongoDB C# LINQ with a Projection Requirement using a MongoCursor

The LINQ Provider for MongoDB does not currently take into account data projections efficiently when returning data. This could mean that you’re unnecessarily returning more data from the database than is needed.

So, I’m going to show you the pattern I applied as a replacement for the LINQ queries when I need to use a projection.

Given the following simple LINQ statement:

var query = 
    (from r in DataLayer.Database
        where !r.Deleted
        select new
            Id = r.Id,
            Title = r.Title,
            Created = r.Created
        }).Skip(PageSize * page).Take(PageSize);

it can be converted to a MongoCursor style search like this:

var cursor = DataLayer.Database.GetCollection<Research>()
    .FindAs<Research>(Query<Research>.NE(r => r.Deleted, true))
                r => r.Id, 
                r => r.Title, 
                r => r.Created))
        .SetSkip(PageSize * page);           

I’ve attempted to format it in a similar way mostly for my own sanity. As you see, both queries first get access to the database collection. But, instead of using AsQueryable<T>, you’ll use the FindAs<T> method. The query is more verbose in the second example, although not overly so. I chose to keep it strongly typed by using the generic version Query<Research>. By doing so, it meant that I could use an Expression to set the field/property that was being queried, rather than rely on a string (I could have just passed “Deleted” as a string in the code).

By strongly typing the parameters in this way, it meant that the compile process can catch things like type mismatches (verifying that the value being compared is a Boolean for example as is the Deleted property).

Secondly, and this addresses the requirement of a result projection, I’ve included just those fields that are required by the UI rather than all of the fields in the document. One of the fields is potentially quite long (up to 1MB of text), and in this case, unnecessary in a summary list display in my web application. Here, I used the SetFields method of the MongoCursor.

The C# driver includes a static class called Fields (in a generic and non-generic form) which can be used to express the set of fields to be included/excluded. I’ll point out that there is an option to just pass in a list of strings to SetFields, but it’s not strongly typed. So again, no compile-time checking that I’ve got the property names correct. I’m going for safety here, so I chose the strongly-typed generic implementation of Fields<Research>. Then, using the Expression syntax again, I’ve selected the fields I needed as a parameter list.

Finally, I added some code to limit the result size and set the skip equivalent to the original LINQ query.

There are a number of other Query methods that you can use to build more complex operations.

For example:

var q = Query.And(
    Query<Research>.Exists(r => r.Title), 
        r => r.Title, BsonRegularExpression.Create(new Regex("^R"))));

The above maps to the following MongoDB query:

{ "$and" : [{ "Title" : { "$exists" : true } }, { "Title" : /^R/ }] }

Title field exists and the Title field starts with an uppercase “R”.

While the Query style syntax is more verbose than the equivalent LINQ statement, the result still is expressive and very readable and maintainable.

FYI: If there’s an index on Title, then the /^R/ syntax returns the results the most efficiently in MongoDB (as it stops searching after the first character).

How to view the MongoDB Query when using the C# LINQ Provider

If you’re using the Official MongoDB C# Driver from 10gen, you may want to occasionally verify that the generated query matches your LINQ query (or at least that it’s building something efficient).

Take for example this query:

var query = 
    (from r in DataLayer.Database.GetCollection<Research>().AsQueryable<Research>()
        where !r.Deleted
        select new
            Id = r.Id,
            Title = r.Title,
            Created = r.Created
        }).Skip(PageSize * page).Take(PageSize);


I wanted to verify that the query was checking the Deleted property, and see if the projection was considered as part of the query, so a few lines of code later …

public static string ToMongoQueryText<TQueryable>(this IQueryable<TQueryable> query)
    return (query as MongoQueryable<TQueryable>).GetMongoQuery().ToString();            

public static void DebugWriteMongoQueryText<TQuerable>(this IQueryable<TQuerable> query)
    Debug.WriteLine("QUERY: " + query.ToMongoQueryText());

I added two extension methods to IQueryable. As the return type for the query in my sample is actually an anonymous type, it wasn’t something I could easily type in the Immediate Window in Visual Studio for example.


No thanks  <>f__AnonymousType2<string,string,System.DateTime>.

I added the Conditional Attribute so that the code would only execute in a Debug build of my application.


The output of the query above was:

QUERY: { "Deleted" : { "$ne" : true } }

As you’ll see, the anonymous projection wasn’t considered. Unfortunately, that’s a known issue with the current driver. This mattered in my above example, as some of the fields could contain a large amount of data that wasn’t needed by the current display.