looks like you can’t.

Tested on Windows 8 Consumer Preview

Think about it

This Javascript means the same as the C# counter part.

//C#
var csharpclass = new ClassLibrary1.Class1();
await csharpclass.testAsync();
// do something

//javascript
var csharpclass = new ClassLibrary1.Class1();
csharpclass.testAsync().then( function (e) {
    // do something ...
});

So does it mean I can avoid creating WinJS.Promises object for async method and use C# instead since it’s (let’s be honest)  kinda confusing and do this instead?

// to avoid doubt: THIS DOES NOT WORK
// only wishful thinking!
public sealed class Class1
{
    public async void testAsync()
    {
        // do this asynchronously ...
    }
}

wouldn’t that be cool???

Unfortunately not.

to declare an asynchronous method in C# and be able to call it as WinJS.Promises we can’t use the async C# keyword but instead use the IAsyncActionWithProgress interface instead. Here’s an example:

namespace ClassLibrary1
{
    public sealed class Class1
    {
        public IAsyncActionWithProgress<Result> testAsync()
        {
            return AsyncInfo.Run<Result>((token, result) =>
                Task.Run<Result>(()=>
                    {
                        // do this asynchronously ...
                        return new Result();
                    }

                ));
        }
    }

    public sealed class Result { ... }
}

Not as clean as one would hope, huh? Hopefully it’ll change in the next Windows 8 release and Microsoft will introduce support to async keyword for WinJS.Promises

Tested on Windows 8 Consumer Preview

Read more: Creating Windows Runtime Components in C# and Visual Basic

1. Add a class library

I assume you have an existing Javascript Metro Application Project. So now what you have to do is just add a C# Metro Class Library. Add a class. Notice a few rules:

1. Root namespace has to match assembly name
2. class has to be sealed
3. and there’s a few more restriction

namespace ClassLibrary1
{
    public sealed class Class1
    {
        public string test()
        {
            return String.Empty;
        }
    }
}

2. Change type of the project to WinMD

Right click solution, properties, under application tab, change output type to WinMD File.

3. Reference project from the JS Metro Application Project

4. Consume the class from JS

var csharpclass = new ClassLibrary1.Class1();
csharpclass.test();

Read more: Walthrough creating a simple component in C# and calling it from JavaScript

There was an awesome Hadoop session last night (sponsored by Microsoft) that explains the basic of Hadoop and then goes into Hadoop on Azure. If you are remotely interested in cloud, big data, or even Business Intelligence, it’s an interesting watch.

Recording can be found here https://skydrive.live.com/redir.aspx?cid=9f92dce9238e14a8&resid=9F92DCE9238E14A8!154&parid=root Get it while it’s hot

Some gems that I note down from the session:

• RDBMS support giga to tera, Big Data peta to exa
• Typical DBA:RDBMS ratio 1:40,
  DBA:Haddop ratio 1:3,000
• BI pattern: extract, structure and store “important information”
  Big Data: “store it all”, maybe information becomes important “later”. Structure only on demand.
• Common pattern: store all data in Hadoop. structure them on demand for serving more traditional BI tools
• Hadoop on Azure is "naturally" integrated with Windows Azure Blob Storage but can be configured to use other storage providers like Amazon S3 (for migration)
• With PowerPivot, one can easily pull in Hadoop/Hive map reduce result into Excel

What is it

WinJS.Promise is an implementation of CommonJS’s Promise ecmascript spec proposal. The spec suggest that we should be able to do the following:

asyncComputeTheAnswerToEverything().
    then(addTwo).
    then(printResult, onError);

Promise allows you to structure asynchronous code as if it was serial by chaining methods together – a technique that I’m sure you’re familiar with by now through JQuery. To C# folks, this is the next best thing since we do not have async/await keyword for javascript.

How to implement a Promise with WinJS

In its simplest form here are the essential element to create a WinJS.Promise to be able to do the above:

(function () {
    "use strict";

    // ...

    WinJS.Namespace.define("someNameSpace", {
        refreshAsync: function () {
            return new WinJS.Promise(
                function (completed, error) {

                    try {
                        //slightly long process
                        ...

                        // you could pass the result to the 
                        // completed function as arguments
                        completed();
                    }
                    catch (e) {
                        error();
                    }
                });
        }
    });
})();

then I could consume the method by:

someNameSpace.refreshAsync()
    .then(updateUI(), showUIError());

Tested on

Caveats, since all these things are still Beta, the above test “works on my machine” with:

Windows 8 Consumer Preview

Visual Studio 2011 Ultimate Beta

Read more

constructing WinJS.Promise http://msdn.microsoft.com/en-us/library/windows/apps/br211866.aspx

constructing Done clause http://msdn.microsoft.com/en-us/library/windows/apps/hh701079.aspx

So you are building a Windows 8 Metro app, wanting to make sure that it passes the Windows Store test and decided to run the Windows App Certification Kit early. You open up WACK from the Windows 8 Consumer Preview Start Menu and cannot find your app listed on the kit. What’s going on?

It seems like Windows App Certification Kit is still buggy in the Windows 8 Consumer Preview. It failed my app for one reason (It cant be my fault, can it?). But most importantly it seems if there are any application with a blank InstallLocation then it will stop going through the application list. Here’s how to fix it:

1. Open a powershell window
2. Do a “Get-AppxPackage > out.txt”
3. Open out.txt and look at InstallLocation field of all the apps installed (IMPORTANT!!)
4. For the apps whose InstallLocation is blank, do a “Remove-AppxPackage <packageFullName>”

A few days back Microsoft announced enhancement to the new SkyDrive. It now works exactly like DropBox.  If you’re confused about the differences between the new SkyDrive, the old SkyDrive and Live Mesh, then you’re not alone. This post will try and clear up the confusion. Hang in there. I’m going to also compared it slightly with Dropbox and Google Drive.

The Old Model

Before the launch of the new SkyDrive, Microsoft used to offer 2 separate products: SkyDrive and LiveMesh.

SkyDrive was the online storage service that was used by the Microsoft Office Web App, all accessible from Live.com. There was no official supported way to automatically sync these files to your computer. I guess the combination of SkyDrive and Live Office Web Apps can be seen as Google Docs. An online only solution.

Windows Live Mesh (originally name Live Mesh, renamed to Live Sync and back to Live Mesh again….I know.) was and still is an application that lets you sync folders across computers – including PCs to the cloud i.e. SkyDrive.
To see a list of the computers participating in the sync, you could go to Windows Live Devices. The SkyDrive storage will be listed as SkyDrive Synced Storage.

With Live Mesh, SkyDrive is optional. I set up a few of my folders to be synced-up only between computers. Which kinda means there is no size restriction as such. The only downside since the P2P nature of the communication is the participating computers have to be on at the same time.

Most of the confusion comes with the fact that our SkyDrive Synced Storage (used by Windows Live Mesh) is separated from the main SkyDrive. Confused? To put it simply, if you start a document from Live.com Office Web Apps, you won’t see it in any of the Live Mesh folders. The same goes for the opposite. I can start a document locally on my computer, have it stored in Live Mesh & SkyDrive Synced Storage and I won’t be able to see it on the main SkyDrive screen.

  
left: SkyDrive
right: SkyDrive Synced Storage

 
left: SkyDrive shows 25GB
right: SkyDrive synced storage shows 5GB

The New Model

The new SkyDrive added a feature which makes it exactly the same as the DropBox model where you get a preconfigured folder where the content will be synchronized across between the cloud storage and your devices. For the consumers, this model is much easier to grasp and managed.

However for the power users, we’d miss the peer-to-peer feature of Live Mesh, which I’m guessing will at some point go away.

Which one to use?

I used to use Live Mesh heavily for peer to peer syncing my archived files. It’s one folder with a few gigabytes of content which I don’t need to have available on the cloud but would like to have on every computers. I then use Dropbox when I want to have it synced to the cloud as well. Also, partly because Windows Live Mesh didn’t have a client on the iPhone too.

But now since Windows Live has increased to 25GB, I see very little occasion where I care about p2p synchronization anymore – or to use the 2GB Dropbox for that matter. 25GB is enough to fit almost all my personal data excluding videos, photos and music. I’m sure this is also true for most people.

Google has also just recently launched their consumer cloud storage offering Google Drive. But with 5GB of storage, at this point I prefer SkyDrive as my primary cloud storage. Having said that, if you use Google Docs heavily, you’d appreciate how Google Drive creates a local shortcut for all the Google Docs that you have as if they are local files. But they are indeed just shortcuts and you still need internet connection to edit them.

If you haven’t fainted by now after reading that title, or at least nearly, I don’t know what will. Microsoft Interop team earlier today just announced Redis on Windows prototype project.

Redis On Windows

Redis is an open source, networked, in-memory, key-value data store with optional atomicity and durability. Or to put it in simple (but rather vague term), Redis is one of thoes NoSQL databases. Made popular by Craigslist and Groupon.

In the Microsoft stack, we currently have access to Windows Azure Table Storage, RavenDB, MongoDB, CouchDB and so on. The reason why Redis wasn’t initially supported on Windows was due to the lack of a specific OS level function called fork/copy on write which allows data to still be read while written. To overcome this, he Microsoft interop team re-implemented the same feature on the software level as a part of Redis on Windows.

The last surprise was the fact that the Interop team has decided to make GitHub as their home instead of CodePlex.

Little Cloud Value

Is this is a game changer? I don’t think so.

With the advent of the cloud, it makes sense for one to want to use Redis on Windows Azure – which I’m sure can be made to work with little effort. However the issue is around the economics. To store approx. 2GB of data on Azure Table will cost you approx 25 cents/month. Whereas running a full small sized VM instance (to get approx 2GB of RAM for Redis) means paying 2 x $90/month (2 instances for high availability.

Regardless whether it makes sense or not, it is still nice to see that we have more options in what we do without necessarily switching to a different OS if we don’t want to.

Redis on Windows is available on GitHub https://github.com/MSOpenTech/redis however still not labelled as ready for production yet.

While trying to install VMWare Workstation 8 on Windows 8 …

I just finished watching 1 hour worth of video on Google Dart. To put it simply, Dart tries to introduce a new browser based, client-side script language which let us not have to deal with Javascript – kinda like CoffeeScript.

A few things that I find intriguing:

1. C style syntax – Google consciously don’t try to invent new syntax and stick to the syntax that most dev already familiar with.
2. Optional static typing – specifying a type against parameter or variables are optional and mainly for development time checking (intellisense & warnings). On “production mode”, Dart doesn’t enforce it.
3. Dart is designed for dev to work with an “offline first” approach. The server component will be simple REST component like WCF Data Services, Web API, or NodeJS type of service (which to note; all the above will run on Azure )
4. View engines work very similarly to XAML. Google is still brewing the view engine and seems to borrow a lot of the concept from XAML & its view model binding capabilities.
   The view engine will be based on using HTML as a templating system, which will get parsed and output javascript code that generates the DOM elements. It’ll have capabilities to bind visual elements to observables.
5. Just like CoffeeScript – using Dart would mean that we as the developer will need to debug on code that the framework generates. There’s no correlation engine as yet between the source code and generated code.