Windows 8 App Downloads Increasing + Over 5,000 Apps Available

Windows 8 will be unleashed on the general public tomorrow and I thought it would be a good time to review some of the numbers I have been tracking over the last month.

Downloads of Windows 8 Apps have been steadily increasing over the last month.  Below is screenshot from the App Summary page for my Windows 8 app.  The blue line is my app, while the orange line is average for the top 5 apps in that subcategory.  Considering the large gap between the 2, I think it is safe to assume that my app is NOT in the top 5 in the subcategory.

The spike in the last couple of days is fairly dramatic and I am a little surprised by that.  I would have expected that kind of spike on the days following the official release as opposed to the days leading up to the release.  

Finally, the all important App count.  There have been some stories floating around that the Window 8 Store is a ghost town and that there are no apps available.  I think these might be exaggerating the situation a little.  As of this morning, in the US store there are over 5000 apps available for download. 

Obviously a far cry from the hundreds of thousands available in other app stores, but we are seeing solid growth in this number. Less than a month ago, that number was 2000. That means the store more than doubled in less than a month. If the growth continues, it won’t be long before the Widows 8 Store is filled with all the apps you need (and a whole lot you don’t need).

Listing Desktop Apps in the Windows 8 Store

So it looks like Microsoft will be allowing publishers to list their desktop apps in the Windows 8 Store.  As per the developer agreement:

b. Desktop App Submission. You may submit an app description for one or more desktop apps to the Windows Store. Notwithstanding anything else in this agreement, you understand that Microsoft will not offer any desktop apps through the Store and only Windows Store apps are made available through the Windows Store. Microsoft may, but is not required to, list the desktop app in the Windows Store together with a link you provide, to a website where users can acquire the app. You are solely responsible and agree to maintain that website and provide an updated link to Microsoft if the url changes. Desktop apps are any apps built using APIs other than the APIs for Windows Store apps that run on Windows 8.

As the agreement states, Microsoft will not distribute desktop apps through the store, but they will provide a link to a website where users can download your desktop app.  If nothing else, it is a great way to advertise your app.  Hopefully this doesn’t cause any confusion with consumers.  Will end users understand why some apps install automatically while others just send you to a website?

Executing NUnit Tests using the Visual Studio 2012 Test Runner

At a recent Visual Studio 2012 event at the Calgary .NET User Group, I was told that I could run my NUnit tests directly in the Visual Studio 2012 without any special plugins.  Naturally, I was very excited and I immediately tried running my NUnit tests. I was somewhat disappointed to see that the Test Runner did not discover any of my NUnit tests. 

Apparently, you do still need to install an extension that supports NUnit.  Microsoft has completely re-written the Test Runner in Visual Studio 2012 and opened it up for anyone to write Test Adapters for any unit test framework (not just MSTest).  Once the correct test adapters are installed, everything works great.  Luckily, there are a good number of adapters already written.

Here are some Test Adapters that you might find useful:

Overall, I still prefer the unit test runner in ReSharper, but this is a great new feature for those who might not have a ReSharper license.

Over 2000 Windows 8 Store Apps

With still a month left until Windows 8 is made commercially available, I was surprised to hear yesterday that there are already 16 million devices running Windows 8 (via @TommyLee).  I was also surprised to see that in Canada, there are already over 2000 apps available in the Windows Store.  This might not sound like much, but it is double the number of apps available less than a month ago.  These look like good signs for the Windows 8 ecosystem.  I am hoping to see the number of apps continue to grow quickly between now and official launch (and beyond).

Calculated Columns in Entity Framework Code First Migrations

I had a couple people ask me about calculated properties / columns in Entity Framework this week. The question was, is there a way to specify a property in my C# class that is the result of some calculation involving 2 properties of the same class. For example, in my database, I store a FirstName and a LastName column and I would like a FullName property that is computed from the FirstName and LastName columns. My initial answer was:

public string FullName 
{
get { return string.Format("{0} {1}", FirstName, LastName); }
}

Of course, this works fine, but this does not give us the ability to write queries using the FullName property.  For example, this query:

var users = context.Users.Where(u => u.FullName.Contains("anan"));

Would result in the following NotSupportedException:

The specified type member ‘FullName’ is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported.

It turns out there is a way to support this type of behavior with Entity Framework Code First Migrations by making use of Computed Columns in SQL Server. While there is no native support for computed columns in Code First Migrations, we can manually configure our migration to use computed columns.

Let’s start by defining our C# classes and DbContext:

public class UserProfile
{
public int Id { get; set; }

public string FirstName { get; set; }
public string LastName { get; set; }

[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
public string FullName { get; private set; }
}

public class UserContext : DbContext
{
public DbSet Users { get; set; }
}

The DatabaseGenerated attribute is needed on our FullName property.  This is a hint to let Entity Framework Code First know that the database will be computing this property for us.

Next, we need to run 2 commands in the Package Manager Console.  First, run Enable-Migrations to enable Code First Migrations for the UserContext. Next, run Add-Migration Initial to create an initial migration. This will create a migration that creates the UserProfile table with 3 columns: FirstName, LastName, and FullName. This is where we need to make a small change. Instead of allowing Code First Migrations to create the FullName property, we will manually add that column as a computed column.

public partial class Initial : DbMigration
{
public override void Up()
{

CreateTable(
"dbo.UserProfiles";,
c => new
{
Id = c.Int(nullable: false, identity: true),
FirstName = c.String(),
LastName = c.String(),
//FullName = c.String(),
})
.PrimaryKey(t =>; t.Id);
Sql("ALTER TABLE dbo.UserProfiles ADD FullName AS FirstName + ' ' + LastName");
}

public override void Down()
{

DropTable("dbo.UserProfiles");
}
}

Finally, run the Update-Database command. Now we can query for Users using the FullName property and that query will be executed on the database server. However, we encounter another potential problem. Since the FullName property is calculated by the database, it will get out of sync on the object side as soon as we make a change to the FirstName or LastName property.

Luckily, we can have the best of both worlds here by also adding the calculation back to the getter on the FullName property:

[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
public string FullName
{
get { return FirstName + "; " + LastName; }
private set
{
//Just need this here to trick EF
}
}

Now we can both query for Users using the FullName property and we also won’t need to worry about the FullName property being out of sync with the FirstName and LastName properties.  When we run this code:

using(UserContext context = new UserContext())
{
UserProfile userProfile = new UserProfile {FirstName = "Chanandler", LastName = "Bong"};

Console.WriteLine("Before saving: " + userProfile.FullName);

context.Users.Add(userProfile);
context.SaveChanges();

Console.WriteLine("After saving: " + userProfile.FullName);

UserProfile chanandler = context.Users.First(u => u.FullName == "Chanandler Bong");
Console.WriteLine("After reading: " + chanandler.FullName);

chanandler.FirstName = "Chandler";
chanandler.LastName = "Bing";

Console.WriteLine("After changing: " + chanandler.FullName);

}

We get this output:

It took a bit of work, but finally Chandler’s TV Guide can be delivered to the right person.

The obvious downside to this implementation is that the FullName calculation is duplicated in the database and in the UserProfile class.

This sample was written using Visual Studio 2012 and Entity Framework 5. Download the source code here.