Here is a class that will do all of that for you:

public class DependencyPropertyWatcher<T> : DependencyObject, IDisposable
{
    public static readonly DependencyProperty ValueProperty =
        DependencyProperty.Register(
            "Value",
            typeof(object),
            typeof(DependencyPropertyWatcher),
            new PropertyMetadata(null, OnPropertyChanged));

    public event EventHandler PropertyChanged;

    public DependencyPropertyWatcher(DependencyObject target, string propertyPath)
    {
        this.Target = target;
        BindingOperations.SetBinding(
            this,
            ValueProperty,
            new Binding() { Source = target, Path = new PropertyPath(propertyPath), Mode = BindingMode.OneWay });
    }

    public DependencyObject Target { get; private set; }

    public T Value
    {
        get { return (T)this.GetValue(ValueProperty); }
    }

    public static void OnPropertyChanged(object sender, DependencyPropertyChangedEventArgs args)
    {
        DependencyPropertyWatcher<T> source = (DependencyPropertyWatcher<T>)sender;
            
        if (source.PropertyChanged != null)
        {
            source.PropertyChanged(source, EventArgs.Empty);
        }
    }

    public void Dispose()
    {
        this.ClearValue(ValueProperty);
    }
}

And here is how to use it:

private DependencyPropertyWatcher<string> watcher;
        
protected override void LoadState(Object navigationParameter, Dictionary pageState)
{
    watcher = new DependencyPropertyWatcher<string>(this.textBox, "Text");            
    watcher.PropertyChanged += OnTextChanged;
}

private void OnTextChanged(object sender, EventArgs e)
{
    var text = watcher.Value;
    // ...
}

Their behavior however can differ slightly from API to API, WPF and Silverlight for example, have slightly different behaviors when it comes to dependency properties. This blog post will look in the details of how dependency properties work in Windows Store Apps.

Implementing a dependency property

The first thing to know about dependency properties is that the infrastructure that make them work is in the DependencyObject class. Therefore, you will need to inherit from DependencyObject if you want to use dependency properties.

Declaring the dependency property

Declaring a dependency property is done through a static method. This will return a key (of type DependencyProperty) that you will be able to pass to GetValue and SetValue to get and set the property on a specific DependencyObject. Here is how to declare the dependency property:

public static readonly DependencyProperty IsSpinningProperty = 
    DependencyProperty.Register(
        "IsSpinning",
        typeof(bool),
        typeof(SpinningControl),
        new PropertyMetadata(false)
    );

Declaring an attached dependency property is very similar:

public static readonly DependencyProperty IsMovableProperty =
    DependencyProperty.RegisterAttached(
        "IsMovable",
        typeof(bool),
        typeof(ObjectContainer),
        new PropertyMetadata(false)
    );

In both snippets, I have highlighted in red the string that will identify the property within the dependency property infrastructure. This name will be used for example when you want to animate the property from XAML.

Implementing the wrapper

A wrapper for GetValue and SetValue is usually defined along with the dependency property. There are some specific conventions on how they should be declared. Here is how to implement them:

public bool IsSpinning
{
    get { return (bool)GetValue(IsSpinningProperty); }
    set { SetValue(IsSpinningProperty, value); }
}

And for a dependency property, the wrapper should be as follow:

public static void SetIsMovable(DependencyObject dependencyObject, bool value)
{
    dependencyObject.SetValue(IsMovableProperty, value);
}

public static bool GetIsMovable(DependencyObject dependencyObject)
{
    return (bool)dependencyObject.GetValue(IsMovableProperty);
}

I have highlighted in red the name of the property that will be looked up in some occasions (see below) when using the property from XAML.

When is the wrapper used?

Dependency property wrappers are not just wrappers. If you don't implement them, you won't be able to use the dependency property from XAML. When setting a dependency property from XAML, the compiler will check that the dependency property you are using actually exists. It can only do so by performing a static analysis of the code. As a result, it is unable to know that you declared a property called "IsSpinning" by calling DependencyProperty.Register. What the compiler does instead is check the existence (and type) of the wrapper. If you use a non-attached dependency property, it will check for the property wrapper, and if you use an attached property, it will check for the GetX and SetX methods (as shown above). This check is also done for example when you declare a Setter in a Style, targeting a specific property. Note however that the compiler doesn't check what happens inside that wrapper. It could be empty, or do something completely different, but as long as it exists and the type matches, compilation will succeed.

When setting a property in XAML to a static value, Windows will actually call the wrapper. That means that it will work even if it is a standard .NET property that is not backed by a dependency property. The SetX method is called if you use the syntax of an attached dependency property. However if you try anything such as setting the value to a binding, or using the property in a style or an animation, Windows will no longer use the wrapper, and will call directly GetValue or SetValue, matching the name of the property that you are using in XAML with the name you declared when you called DependencyProperty.Register. If that name doesn't exist, you will get a runtime error. That's why the name in the wrapper and the name in DependencyProperty.Register (all in red above) have to match. If they don't match, you will either get a compile time or runtime error.

Here are the key takeaways about how dependency properties work when used from XAML:

1. Compile time
   • Compile time check is always performed by looking at the name and type of the wrapper.
2. Runtime
   • Setting the property to a static value in XAML will cause the wrapper to be called (looked up by its name). That works even if there is no dependency property registered to that name.
   • With any other advanced feature (data binding, styles, animations...), GetValue and SetValue are called directly and the wrapper is bypassed. There must be a dependency property registered with that name.

Those two pages give the golden rules of a Windows Store App design:

• Laying out an app page
• Guidelines for fonts

Following those guidelines will ensure you have a sleek UI, that is consistent with the other apps.

The documents use the notion of unit, which is a 20 pixels space, and can be divided in 4 sub-units of 5 pixels each.

In a standard page, the top region containing the header will be 140 pixels (7 units) and the left margin will be 120 pixels (6 units). The bottom margin will be between 50 and 130 pixels (2.5 to 6.5 units) depending on your content.

• AppBar
• Button
• CheckBox
• ComboBox
• ComboBoxItem
• ContentControl
• FlipView
• FlipViewItem
• GridView
• GridViewItem
• GroupItem
• HyperlinkButton
• ListBox
• ListBoxItem
• ListView
• ListViewItem
• PasswordBox
• ProgressBar
• ProgressRing
• RadioButton
• RepeatButton
• RichEditBox
• ScrollBar
• ScrollViewer
• SemanticZoom
• Slider
• TextBox
• Thumb
• ToggleButton
• ToggleSwitch
• ToolTip

Note that you will also find those default styles and templates in the following file on your disk: C:\Program Files (x86)\Windows Kits\8.0\Include\WinRT\Xaml\Design\generic.xaml.

In this article, I will explain how to pin any shortcut to the start screen. Let's say for example that you would like to pin a file to the Start screen. It works with really anything: executables, batch files, documents, images, etc...

1. Start creating a shortcut to what you want to pin.
2. Navigate to %ProgramData%\Microsoft\Windows\Start Menu\Programs (Press Windows + R and paste it there to open it directly)
3. Copy the shortcut there

That's it, the tile should have appeared in your Start screen. If it hasn't, you'll find it in "All apps" in the bottom bar (right click, or swipe your touch screen from the bottom). You can then right click on the tile and select "Pin to Start".

People are starting to realize the need for asynchronous programming, but even the most popular frameworks for asynchronous programming, like Node.JS or Tornado with Python are callback based.

This was also the case with C# until recently, but as you know, C# 5.0 introduces the new async/await keywords. Those keywords are the Holy Grail of asynchronous programming. Asynchronous code written using async/await will be as readable as synchronous code, because it no longer requires the use of callbacks.

Async and await can be used out of the box with Task<T>, but any object implementing the awaitable pattern can be used with await. IObservable though, represents a collection, and await only allows to deal with single values. Note that you can await an observable, but that will only yield the last value of that observable. You could also use BufferAllAsync that I showed in my last article, then await the result, but that will require the whole enumeration to be buffered, and you won't be able to do any processing before the observable has completed. What we would need is an async flavor of foreach, something like:

private static async Task EnumerateAsync(IObservable<string> observable)
{
    async foreach (var item in observable)
    {
        Console.WriteLine(item);
    }
}

Unfortunately, the C# language designers preferred not to overwhelm developers, and did not include that feature in C# 5.0.

Fortunately, it is not hard to recreate. The secret is to transform the IObservable<T> into a IAsyncEnumerable<T>, then use await to enumerate asynchronously over it. IAsyncEnumerable<T> is part of the interactive side of the Reactive Extensions. You will need to add a reference to System.Interactive.Async, which you can find in the Ix_Experimental-Async NuGet package. IAsyncEnumerable<T> is basically a replica of the IEnumerable<T> interface, the only difference is that MoveNext returns Task<bool> on the IAsyncEnumerator instead of bool on the normal IEnumerator. This makes perfect sense, as in the asynchronous case, MoveNext should only complete when the source IObservable has a new value to provide, when the observable completes, or if it throws.

Let’s assume we have an observable that we want to iterate over:

IObservable<string> io = Observable.Interval(TimeSpan.FromSeconds(1)).Select(v => "Tick " + v);
EnumerateAsync(io);

We can implement an async foreach by copying the expanded form of foreach, and adding the await keyword when calling MoveNext. The result is this:

private static async Task EnumerateAsync(IObservable<string> observable)
{
    using (var enumerator = observable.ToAsyncEnumerable().GetEnumerator())
    {
        while (await enumerator.MoveNext())
        {
            await Task.Yield();

            var item = enumerator.Current;

            // Your code here
            Console.WriteLine(value);
        }
    }
}

The Task.Yield statement is necessary because of a bug in the implementation of ToAsyncEnumerable. Using that construct, you can process observables in a pull fashion. That means you can wrap the loop in a try/catch statement, use break from the loop, and the disposal of the subscription is automatically handled. That also guarantees that each iteration of the loop will be done one after the other, in a sequential fashion, making your code thread-safe by design.

What Task is in reality is a “future”. A future is an object that represents a value which may or may not exist yet. When you run a piece of code using Task.Run, what the Task returned represents is the return value of your piece of code. It will only be available when the piece of code finished running. However, Task is suited to represent any sort of operation that hasn’t completed yet, parallel computation but also IO. If parallel computing is important in some fields, asynchronous IO is capital for almost any application (Client and server).

Reactive Extensions (Rx) is a project that was started by Erik Meijer before the TPL even existed. It was only released recently though (2010). Rx is providing a new interface (IObservable<T>) that can be combined by the means of operators, the same way you can use LINQ on IEnumerable<T>.

Historically, the async/await feature did not exist yet when the Rx project started. As a result, they have now a great deal of overlap in what they can do. It doesn’t mean that one must disappear, there are situations where one or the other will be better suited. Let’s now see which one is better suited for what.

Reasons for using Task<T>

Let’s say you are turning a synchronous function returning int to async, you could do two things: return IObservable<int> or Task<int>.

Rx provides you with a bunch of operators, one of them is Observable.Return. This returns an observable that pushes a single value, then completes immediately. My opinion is that returning Task<int> is better, and here are the reasons why:

1. Task is included in .NET, whereas the reactive extensions are not. Your code will require the reactive extensions if you chose to return IObservable.
2. In C# 5.0, the async/await language feature can only return Task or Task<T> (or void), so you can use that feature and don’t need any conversion.
3. The IObservable<T> contract is very broad, it just represents a stream of values. It could be zero value, one value, or multiple values. And after a value has been pushed, it could complete immediately, or later. On the other hand, a Task<T> represents always a single value of type T, and when the value is available, it becomes the result of the task, and the task is considered completed. At this point, the task is immutable, and you know it will never change state again. The contract is much simpler.
   If someone consuming your function looks at the signature, it is clear that it returns a single value if your return Task<T>. If you return IObservable<T> however, there are many things it could return.
4. The threading model is more straightforward with Task<T>. When you are handed a task, and want to attach a continuation to it, you are in complete control of what thread it will run on, no matter where that task comes from. If you don’t specify any scheduler for your continuation, it will run on the current scheduler, or the default scheduler (Task pool) if there is no current scheduler. That behavior is always true, and completely independent from the task you are attaching a continuation on.
   In the reactive extensions, on the other hand, when you subscribe to an observable, the scheduler on which the callback will run depends on how the observable was constructed. This allows IObservable to have better performance, since it doesn’t switch thread at each step of the computation, but on the other hand, the abstraction leaks, and a piece of code working with an IObservable could behave differently depending on which scheduler that IObservable runs on.
5. This is an extension of the previous point, but with the reactive extensions, depending on how the observable is constructed, your consuming code (the code in the callback) could be blocking the producing code.
   Task on the other hand, is just a piece of data. There is no producing code associated to it. This model is easier to reason with.

Reasons for using IObservable<T>

As you saw in the previous section, Task is a better abstraction and easier to reason with, but there are situations where Task<T> is not the best tool for the job. Task<T> represents a future for a single value of type T. Sometimes, you need to return a stream of values. Here is an example: let’s imagine you are writing an asynchronous function that reads a database table, and returns it. If you return task, you will have to return something like Task<List<Row>>, that means you will be buffering all the rows in memory, and complete the task when the whole table is buffered. You can probably see why this can become a scalability issue. A better option is to return IObservable<Row>. Each row, as it is read from the database, is pushed through the IObservable. The consumer can then process rows as they become available, and there is never more than one row in memory at the same time.

Note that if as a consumer, you still want to buffer all the rows, you can easily convert the IObservable<Row> to a Task<IList<Row>>, using this function:

public static Task<IList<T>> BufferAllAsync<T>(this IObservable<T> observable)
{
    List<T> result = new List<T>();
    object gate = new object();
    TaskCompletionSource<IList<T>> finalTask = new TaskCompletionSource<IList<T>>();

    observable.Subscribe(
        value =>
        {
            lock (gate)
            {
                result.Add(value);
            }
        },
        exception => finalTask.TrySetException(exception),
        () => finalTask.SetResult(result.AsReadOnly())
    );

    return finalTask.Task;
}

To wrap up, I would suggest to use Task whenever you can, and use IObservable if you get into a more complex situation where you need an entire collection to be turned asynchronous.

1. Introduction
2. Provisionning a virtual machine on Windows Azure
3. Setting up the server
4. Configuring your client

Make sure you have the private key (the PPK file) we generated in part 2 using Puttygen.

What we will do first is create an empty repository on the server. We will need to log in onto the server to do that.

1. Start putty and enter your hostname (xxxx.cloudapp.net).

   

2. On the left, click on “Auth”, under “SSH”, under “Connections”. Click Browse where it says “Private key file for authentication”, and find your private key file. Click Open.

   

3. When you are prompted for your username, type “git” (the git user). Putty should then authenticate you using your private key. It will ask you for the passphrase you chose when you generated the key pair.

4. You should now be logged in. Create a new repository by doing:

   cd /git
   git init --bare myrepo.git
   

You can now log out from the server. The repository has been created on the VM. Let’s now clone it on your machine.

First make sure you have installed msysgit on your client machine. You can download it from here. Then you can install TortoiseGit, it you haven’t done so already. You can download it at this location.

You should now be all prepared to use Git from your client machine.

1. Right click on the folder where you want to clone the repository, and select “Git Clone…”. A popup will appear.

2. In the URL, type a URL such as: ssh://<your-clouapp-host-name>/git/<your-repository-name>

   In our example, <your-repository-name> would be myrepo.git.

   

3. Check “Load Putty Key”, and browse for your private key. Click OK.

4. You will be prompted for the user, type “git”, you may also have to type the passphrase of your private key.

This is it, the repository is cloned. The repository will be empty of course, but you can now make some changes (add a file), commit the changes.

After pushing back your commits to origin (the virtual machine), your changes will be safely and durably stored on Windows Azure, and you will benefit from the Geo-replication. Any contributor who owns a private key (as configured in part 3) can create new repositories, push and pull code. You can create as many repositories as you want by following the first 4 steps of this article. You should have about 25 GB free on the disk for storing your repositories, if you chose the default Ubuntu image provided by Windows Azure. In case you need more space, you can attach an additional virtual disk. The current price for Geo-Replicated storage is $0.125 per GB per month. This solution is more complex than setting up a repository on GitHub, especially for a small one, but if you have many repositories and/or large ones, this will be a very economical solution.

1. I will assume you are running Windows on your client machine. We will use Putty to connect to the Virtual Machine using the SSH protocol. Download it from this webpage, and make sure you take the Zip file that contains all the binaries.

2. Launch Putty. You will then need to specify the host name of your VM. It will take the form of xxxx.cloudapp.net. The first part (xxxx) is what you have chosen in part 2 of this series. If you don’t remember what you chose, you can find it by going back to the Azure Portal. It will be displayed on the right. Leave the rest as the default (port should be 22). Windows Azure has automatically opened the port 22 on the load balancer to let traffic in. All the other ports will be closed to reduce the surface of attack.

   

3. You will be prompted for your username and the password. Once you have typed them, you will be logged in remotely on the Virtual Machine.

   

4. Run those commands to make sure your OS is up to date and to install git.

   sudo apt-get update
   sudo apt-get dist-upgrade
   sudo apt-get install git-core

5. Let’s create a user ‘git’ that we will use to access the repositories:

   adduser git

   All the contributors will use that user to push or pull from the repositories, however that doesn’t mean that they will have to share the password. We will see later why.

6. We will now create the directory where all the repositories will be stored. We will create that directory under the main user's own home directory (/home/flavien in our case). Since the 'git' user doesn’t have write permissions in that user's home directory, it will not be able to delete the ‘repositories’ directory:

   mkdir ~/repositories

   However we want only the 'git' user to have full access to the content of the directory.

   First, we need to install the ACL package. That will give us the ability to set a default ACL on the directory. A default ACL is a special kind of ACL defining the access ACL that files and subdirectories directly under the directory inherit when they are created.

   Install the ACL package by running this command:

   sudo apt-get install acl

   Now, run the following commands to set the proper permissions on the 'repositories' directory:

   chmod 700 ~/repositories
   setfacl -m defaut:user::rwx ~/repositories
   sudo chown git:git ~/repositories

   If you run the command « getfacl ~/repositories », you should see the following:

   # file: repositories
   # owner: git
   # group: git
   user::rwx
   group::---
   other::---
   default:user::rwx
   default:group::---
   default:other::---

   

7. We are now going to create a symbolic link to simplify access to the repositories. Type the following command:

   sudo ln -s /home/$USER/repositories /git

   You can check that the symbolic link was properly created by running:

   ls -al /git

   

8. Let’s now configure authentication. Each contributor will use a private key of their own. All those keys will be configured to grant access to the ‘git’ account, so that all the contributors will share the 'git' account on the virtual machine, without having to share the password.

   On your Windows client, start Puttygen, and generate a key (it should be part of the zip file you downloaded on the Putty website). Enter a passphrase, and save the private key on your disk. Copy the public key (where it says “Public key for pasting into OpenSSH authorized_keys file”).

   

   Now go back to the VM on putty, and type:

   mkdir /home/git/.ssh
   echo "ssh-rsa AAAAB3N[…]B+Q== rsa-key-20120704" >> /home/git/.ssh/authorized_keys

   In the second command, you need to replace the part in red with the public key you copied from Puttygen.

   Each contributor should generate a key pair with Puttygen, and send you the public key. You will need to add all those public keys to the authorized_keys file by repeating the command above. Each contributor will then have a key that they can use to connect to the VM on behalf of the git user.

The setup of the VM is now complete. Git is installed on the machine, we have created a dedicated user for accessing repositories, and only that user has access to them, which means that if you install more services on the virtual machine, there is no risk of them changing or deleting the repositories. We have also created key pairs for every contributor, so that they can pull and push to the git repository on the machine, using SSH. In the last post in this series, we will see how to configure TortoiseGit, create a new repository on the virtual machine, and push changes from a client.