People have been doing this for a long time, of course,  but the Hot Towel SPA starter really is a nice introduction to the style. In a SPA, you really  need to think of the browser as “the client,” a standalone entity that communicates with your server via (web) API calls. Once you get used to it, it’s really rather refreshing, and it allows you to take advantage of all the computing power on the client machine in a way that can be quite liberating.

Hot Towel uses a JavaScript application framework called Durandal to structure the client side code. It divides the world up into services (JavaScript modules, basically), views, and view models. All of this is just for the JavaScript side of things, remember – you may also have views and view models and so on on the server side, but that’s a different thing – you’ll interact with those via AJAX calls, usually using JSON to encode the data.

Hot Towel uses HTML for the views and lets Knockout do the view composition and data binding, which makes it a good source of examples for learning Knockout as well.

The JavaScript code is nicely modular, in the style of require.js. If you’ve not seen this style, it’s worth checking out. Basically, you declare all your dependencies for your JavaScript module, and the framework asynchronously loads them as necessary, as passes them to your module. It’s great documentation, great for structuring the code so you don’t get circular dependencies, and makes for easier unit testing too, since can easily supply alternative (mock) implementations of your module’s dependencies.

On the server, the MVC code is well organized as well, and it’s straightforward to plug in your new Web API controllers and start coding.

I’ve been playing with this starter for a while, working on a proof of concept for a new series of articles on my blog. I found Hot Towel to be a great starting point, and it opened my eyes to some interesting new techniques on the client side. Give Hot Towel a try for your next project, it’ll be fun.

Since we’re deploying our application to Azure , we don’t have access to the Windows event log, or to log files that we might  generate, in the way we would if we were hosting in a more traditional environment (or in a Windows Azure virtual machine for that matter). Fortunately, we do have other tools available.

Let’s look at some tools we can use to diagnose a problem that we already have with our simple application. If we navigate to /account/login on a locally running version of the site, it comes up without any problems. Visit the same URL on the Azure version, and instead you get an error page. The page is intentionally vague about the cause of the error.

At this point, you are probably wanting to turn off the custom error messages so you can see the exception. Let’s return to the management portal to do that. Click on the Websites side-tab, select your site, then click the Configure link. Scroll down a bit to the Diagnostics section.

Turn on all three of the diagnostic options. Don’t forget to scroll down and click the Save button.

Then try your application again. It will take a little while to respond – essentially, you’ve just changed the web.config, so it’s restarting. Now you’ll get detailed error messages. That doesn’t mean you’ll see the yellow screen of death. The end-user experience is the same. What you get with the detailed error messages is the ability to see those error messages in the management portal. The detailed error messages and logs get written to an FTP site, which you can access once you’ve configured a user name. You’ll find the link for that on the Dashboard page of the portal, on the right side and down a bit:

After you do that, your username and FTP URL will both show up in the section below the “quick glance.” Click on the FTP URL and you can view the detailed errors, one html file per error. The full IIS logs for your site are there as well, so you can download and analyze them at your leisure.

The detailed error message for this problem isn’t very helpful, though:

If only there were a way to see the stack trace…

ELMAH To The Rescue

There’s a great package called Elmah that provides handlers that you can install into your web application. These handlers record exceptions that your application encounters, logs them, and also makes them available for your review directly within your web site. This is not an Azure-specific package, but it will work just fine with your Azure web site.

Go ahead and install the Elmah NuGet package. Since we’re using an MVC site, you can install the Elmah.MVC package, which will automatically install the base Elmah package as well. You can either use the “Manage NuGet Packages” option you get when right-clicking the project in Visual Studio Solution Explorer, or you can do “Install-Package Elmah.MVC” in the Package Manager Console.

Once that’s done, you can republish you application to Azure. If you visit your /account/login URL again, it will still fail. Then you can visit /elmah on your site. This will tell you “You do not have permission to view this directory or page.” This is good – you don’t want random Internet users to be able to read your error logs! To enable you to read the errors right now, though, let’s change the web.config. At the end, just before the </configuration> end tag, add a section like this:

  <elmah>
      <security allowRemoteAccess="1" />
  </elmah>

Now you can republish to Azure. Once you’ve done that, you should be able to go to yourappname.azurewebsites.com/elmah, and see something like this:

Try /account/login again, then go back to /elmah. Now you’ll see an entry for the exception you just experienced. Click on it, and you’ll see that yellow screen of death you’ve been missing!

When we scroll over to the right a bit, we finally see the problem: System.InvalidOperationException: The ASP.NET Simple Membership database could not be initialized. For more information, please see http://go.microsoft.com/fwlink/?LinkId=256588

---> System.Data.ProviderIncompatibleException: An error occurred while getting provider information from the database. This can be caused by Entity Framework using an incorrect connection string. Check the inner exceptions for details and ensure that the connection string is correct. ---> System.Data.ProviderIncompatibleException: The provider did not return a ProviderManifestToken string.

---> System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 52 - Unable to locate a Local Database Runtime installation. Verify that SQL Server Express is properly installed and that the Local Database Runtime feature is enabled.)

---> System.ComponentModel.Win32Exception: The system cannot find the file specified

So, the reason we cannot access the login page is because we have not yet set up a database in which to store the login information! In the next episode, we’ll fix this problem and start actually building our application.

Important:

Right now, your web application will let anybody view your error information via the /elmah URL! Be sure to remove or comment out that <security allowRemoteAccess="1" /> . Once we have login working, we can configure it so that only administrators have access to that URL, but for now, it needs to be disabled!

Creating the Project

I’ll be using Visual Studio Express 2012 for Web. The easiest way to install this with the Azure tools is probably using this package from the Windows Azure site. Create a new project, and choose C#, then Web, and pick the ASP.NET MVC 4 Web Application.

Next, I install Twitter Bootstrap, because I like it. You can use the default stuff instead, or install some other framework if you prefer.

In the Package Manager Console (that’s View –> Other Windows –> Package Manager Console, by the way), do:

install-package twitter.bootstrap.mvc4
install-package twitter.bootstrap.mvc4.sample

I see a couple of error messages in Visual Studio at this point, but the Readme advises me to close and restart Visual Studio, and so I do. After that, it’s fine.

I also make a small change to Views\Shared\_BootstrapLayout.cshtml, to let it render a section called “featured” that’s included in the default Index.cshtml – without making that change or a similar one, we would get an error.

After this, we can do Ctrl-F5 and we’ve got a running site.

Setting up the Azure Web Site

Now that we’ve got our web application running, we need to publish it to Azure. I’ll assume you’ve already signed up for Azure – if not, why not start with the free trial? To create the web site is really simple – just go to your management portal, click on the Web Sites side-tab.

Then click the big “New” button at the bottom of the page:

Choose the “Quick Create” option – this will let you get a site up after just specifying a name.

Then just enter a name for your site, pick a region near you, and click on “Create web site.”

When the creation process finishes, your site will automatically be available on the web at whatever_name_you_picked.azurewebsites.net.

Publishing

In Visual Studio 2012, you can now easily publish your existing web application directly to the Azure Web Site you just set up. Just right-click on the project and choose Publish.

This leads to a dialog where you can choose a deployment profile. Deployment profiles are files that tell Visual Studio what it needs to know to publish to the correct location. Fortunately, Azure can provide you with a deployment profile automatically. Go back to the Azure management portal, click on the Web Sites side-tab, then click on the name of the web site you just set up. This brings you to the dashboard for your site. Under the bandwidth/usage chart and off to the right (you may have to scroll down a bit) there is a “quick glance” section. In that section is a link to “Download publish profile,” which is what you want. Click that and you’ll download the profile for your site.

Now switch back to Visual Studio, and bring up the Publish dialog again. Click the Import button to import your new profile.

Once you’ve got your profile installed and selected, you can click Next to see what it’s imported, or just click Publish to do the publishing. Once the deployment process has completed, it will open your application in the browser – your web application has now been published, and you can republish at any time without having to import the profile again, it’s now part of your project.

Next Steps

In the next installment, we’ll talk about error handling and diagnostics!

Then something goes wrong. The transaction rolls back. The database is restored to a pristine state, just as it was at the beginning of your transaction. Your cache, on the other hand, is tainted. There are data in your cache that aren’t in your database.

You may come up with a strategy for delaying cache updates until after the transaction has completed. That’s fine, except that you rely on your cache being up-to-date – if you have changes in the database that aren’t reflected in the cache, you’ve got a different kind of tainting. All sorts of unreliability and special casing begin to creep in. So in the end, you either have to cache only things that will never change, or you have to make your cache transaction-aware.

This is an important use-case, however it’s surprisingly rarely discussed. Haskell has Software Transactional Memory (STM), but there’s nothing like that in .Net. On the other hand, the .Net framework offers an interface, IEnlistmentNotification, that you can implement in classes that need to react to transaction events like commit and rollback. It’s actually fairly easy to implement, but there are some tricky areas that I’ll point out. With IEnlistmentNotification in hand, we can create our transactional cache.

Planning

Let’s first agree on what we’re trying to build. To simplify the problem a little, we’ll leave out caches for the moment, and just ask: What would it take to make a transactional dictionary? Such a dictionary would have to support the sorts of guarantees that people expect of transactions. These guarantees are known as ACID – Atomicity, Consistency, Isolation, and Durability.

Atomicity

This means that the transaction succeeds or fails as a single unit. If anything goes wrong in a transaction, all of the work done in that transaction must be undone, as if it never happened.

Consistency

The system moves from one consistent state to another. At no point can the system be inconsistent.

Isolation

The changes that one transaction makes are undetectable to code that’s running in a different transaction, until the transaction commits. Once the transaction is complete, its results are visible throughout the system.

Durability

Once a transaction has been committed, it remains so – it cannot be undone, nor can it be lost due to power failure or other catastrophe. In our case, we’re talking about a volatile resource, a dictionary residing in memory, so we’re not really concerned with durability in the same sense that a database management system would be.

The Approach

The transactional dictionary we’re going to build will have the following properties:

• Changes made to the dictionary within a transaction will not be visible outside of that transaction, until the transaction completes.
• If the transaction rolls back, there will be no changes made to the dictionary.
• If the transaction commits, the dictionary will be permanently updated with the changes executed during the transaction
• Unlike a database, we’re not going to concern ourselves with locking or trying to manage the order of transaction execution, we simply want to make sure that failed transactions don’t leave stale data in the dictionary. However, we will lock the dictionary while each transaction is committing.

The Implementation

We know that we need to implement IEnlistmentNotification to participate in a transaction. We also need to enlist in the transaction in order to get the notifications. Enlisting is easy enough, and looks like this:

txn.EnlistVolatile(this, EnlistmentOptions.None)

Where txn is a reference to a Transaction, usually obtained via Transaction.Current. The “this” argument needs to be a class that implements IEnlistmentNotification.

The implementation of IEnlistmentNotification is also fairly straightforward. Suppose that we have a dictionary that represents the consistent state of our transactional dictionary. We’ll call this the “backing store.” While things are happening during a transaction, the backing store doesn’t change, instead we store those changes in a different location that we’ll call the “transactional values.” When the transaction commits, we need to update the backing store with the results of transaction, i.e. the contents of the transactional values.

A Word on F#

I’m implementing this in F#, rather than C#. This is not because this problem is particularly well suited to functional programming or immutable data structures – in fact, this problem is mostly about state and mutability. I do favor a functional approach in general, but I’m using F# here mostly because it’s shorter and clearer than C#, which means it takes me less time to read, write, and debug. Since I’m doing this on my own time and have no other constraints that dictate what language I should use, I choose what I perceive as the best general-purpose language available for .Net, F#. Your mileage may vary, use what makes you happy.

One additional note: I’ve used generic classes based on built-in framework interfaces, and type variable names in the style of the Framework Design Guidelines ('TKey instead of 'k, for instance) to encourage reuse from other .Net languages. This is not intended to be an F#-specific library.

The Tricky Bits

The first tricky bit is that when the transaction notifies your code that the transaction is done, either via calling Commit or Rollback, Transaction.Current is null, and there’s no Transaction property on the enlistment object that is passed by the transaction manager. This means that the class that gets the notification must know what transaction it’s being notified about already, meaning it must only be working with one and only one transaction. This forces our design to be one in which we create a new instance of a class for each transaction, and assign the management of that transaction to the new instance, rather than handling it in the transactional dictionary itself.

The second tricky bit is that we need to track both the addition of new keys as well as the removal of keys. That means we need a data structure that will track both. We’ll deal with this by storing an F# Option<'T> type instead of the raw value – values that are present in the dictionary will be represented by (Some value) and values that have been removed will be represented by None.

The third tricky bit is that our transactional dictionary needs to keep track of which of its transactional values helpers should receive each particular call, depending on the transaction of the current thread, but it also needs to remove its references to each transactional values helper when the transaction associated with that helper completes. Even if we enlisted the transactional dictionary in the transaction directly, it still wouldn’t know which transaction had committed, so it wouldn’t know which one to remove. So the helper has to be empowered to clean itself up. We’ll do this by passing a function to the helper that it can call to let the transactional dictionary know it’s ready to be cleaned up.

Working with transactions can be full of little surprises, which leads us to the fourth tricky bit. As reported by Ayende a couple of years ago (and other places as well), it is actually possible for a use (C#: using) statement to end before your transaction commits, or rather, before your enlistment’s Commit method returns. The Prepare, Commit, and other methods on IEnlistmentNotification are called in a different thread from the one that creates and disposes the TransactionScope, so we’ll have to take appropriate steps (i.e. locking) to make sure that things work the user of our transactional dictionary would expect.

With those in mind, let’s dive into the implementation.

TransactionalDictionary

The transactional dictionary doesn’t reinvent the actual storage of the data – we have perfectly good data structures for that already. It takes a dictionary (the “backing store” we mentioned earlier) as a constructor argument. This is the “one source of truth” for our data, like a table in a database. We may overlay that data with changes, but we will never actually update the backing store until it comes time to commit the transaction.

type TransactionalDictionary<'TKey, 'TValue
        when 'TKey:equality
         and 'TValue: equality>
            (backingStore:IDictionary<'TKey,'TValue>) = 

    //A mapping from transaction to our TransactionValues helper class

    let transactions = new Dictionary<Transaction,TransactionValues<'TKey, 'TValue>>()

    //A synchronization object for locking

    let sync = obj()

    //The lock that we use during the transaction commit process

    let transactionLock = new TransactionLock()

Since this is F#, we don’t have to explicitly store the backingStore parameter, it’s automatically available to all the methods of the type. We create a dictionary to map from transactions to a transaction-specific helper class that we’ll rely on heavily for most of the implementation of TransactionalDictionary. Then we create two synchronization objects – one, “sync” that we’ll use to control access to the transactions dictionary, and one, “transactionLock,” that will ensure that transactions don’t try to commit simultaneously. We do not require the backing store to be thread safe, so we have to provide the locking to ensure only one thread commits at a time.

The IDictionary<’TKey,’TValue> Implementation

The implementation of the dictionary operations themselves is almost trivial – they all involve calling a function called getTxnValues that returns the TransactionValues helper that we have stored for the current transaction, and then delegating the method call to the method of the same name on the TransactionValues helper. Here’s a sample, the implementation of the indexer:

        member this.Item
                with get key = let tv = getTxnValues()
                               tv.[key]
                and  set key value = let tv = getTxnValues()
                                     tv.[key] <- value

The getTxnValues Function

This function is critical to the operation of the dictionary – it checks Transaction.Current to find out which transaction the code is participating in, and returns (via the getValues function) the TransactionValues helper instance associated with that transaction. If there is no instance assigned yet assigned to the current thread, and the thread is in a transaction, it creates one. If the thread is not in a transaction, then it can access the backing store directly.

let getValues txn : IDictionary<'TKey, 'TValue> =
        if txn = null then
            backingStore
        else
            let dict = lock sync (fun () ->
                                    let (containsKey,value) = transactions.TryGetValue txn
                                    match (containsKey,value) with
                                    | true, v -> v
                                    | false, _ ->
                                        let v = TransactionValues<'TKey, 'TValue>(
                                                            backingStore,
                                                            (fun () -> transactionLock.Lock(txn)),
                                                            (fun () -> transactionLock.Unlock |> ignore
                                                                       lock sync (fun () -> transactions.Remove txn |> ignore)))
                                        transactions.[txn] <- v
                                        v)
            dict :> IDictionary<'TKey,'TValue>
    let getTxnValues () = getValues (Transaction.Current)

First, we lock the synchronization object for the dictionary. After that, we’re free to read or modify our Transaction-to-TransactionValues dictionary as we like. If needed, we create a new TransactionValues helper instance, passing it the backing store for the TransactionalDictionary, and two functions. The first function is the one that TransactionValues will call when it’s ready to begin committing its changes to the backing store, and the second function will be called when it has completed its work, either by committing, or rolling back.

The TransactionValues Helper

TransactionValues is really the type that does the greatest part of the work. Each TransactionValues instance manages the changes that have been executed in the context of a single transaction. It stores the changes in a dictionary of its own. While TransactionalDictionary<'TKey, 'TValue> maps 'TKey to 'TValue, TransactionValues maps 'TKey to Option<'TValue>. Storing a value of None means that in the current transaction, that key was removed. Storing a value of (Some v) for a key means that in the current transaction, that key was set to a the value of v. Keys that are not present in the TransactionValues dictionary have to be looked up from the backing store.

We create this dictionary of changes in the constructor:

    let transactionValues =
        if backingStore.IsReadOnly then
            raise (System.ArgumentException("Source dictionary is ReadOnly"))
        new Dictionary<'TKey, 'TValue option>()

Another important task for the constructor is to fix the knowledge of the transaction to which this instance is bound. It is at this point that we actually enlist in the transaction:

    let transaction =
        let txn = System.Transactions.Transaction.Current
        if txn = null then
            let msg = "TransactionValues can only be created in the context of an open transaction"
            raise (System.InvalidOperationException(msg))
        txn.EnlistVolatile(this, EnlistmentOptions.None) |> ignore
        txn

Let’s look at the implementation of the indexer for TransactionValues:

member this.Item
        with get key = getOrFail key
        and  set key value = transactionValues.[key] <- Some value

Clearly, we need to see getOrFail as well! Here it is:

    let get key =
        let (succ, value) = transactionValues.TryGetValue(key)
        match (succ, value) with
        | true, ((Some _) as v) -> v
        | true, None -> None
        | false, _ -> match backingStore.TryGetValue(key) with
                      | true, v -> Some v
                      | false, _ -> None

    let getOrFail key = match get key with
                        | None -> raise (KeyNotFoundException())
                        | Some v -> v

You can see now how TransactionalDictionary delegates to the TransactionValues instance for the current transaction, and TransactionValues stores changes in a separate dictionary that it uses as an overlay over the original backing store.

Commit, or Don’t

So far, the code we have can store different changes for different transactions, and those transactions won’t be able to see each other’s changes. At some point, however, we’ll  want to actually commit or roll back the transaction. To do this, we implement the IEnlistmentNotification interface in the TransactionValues type. Here is the implementation, along with a few relevant functions:

//The undo data needed to undo changes if a rollback happens during
//a 2-phase commit. Generated during the IEnlistmentNotification.Prepare method.
let mutable undo:seq<'TKey * 'TValue option> = Seq.empty

//Tracks whether the Prepare method has been run or not. Under some circumstances,
//Commit can be called without calling Prepare first, so Commit has to be be
//able to do the work of Prepare as well.
let mutable prepared = false

let updateWithPair (dictionary:IDictionary<'a,'b>) (kv:'a * 'b option) =
    let (k,value) = kv
    match value with
    | Some v ->
        dictionary.[k] <- v
    | None ->
        dictionary.Remove k |> ignore

let update (dictionary:IDictionary<'TKey,'TValue>) : seq<'TKey*'TValue option> =
    let undo = seq {
                    for kv in transactionValues do
                        let (has,old) = dictionary.TryGetValue(kv.Key)
                        updateWithPair dictionary (kv.Key, kv.Value)
                        yield kv.Key, (if has then Some old else None)
                        } |> List.ofSeq :> seq<'TKey *'TValue option>
    undo

let prep() = lockStore()
             undo <- update backingStore
             prepared <- true

interface System.Transactions.IEnlistmentNotification
        with
        member this.Commit(enlistment) =
            if not prepared then
                prep()
            finished()
            enlistment.Done()
        member this.InDoubt(enlistment) =
            enlistment.Done()
        member this.Prepare(enlistment) =
            try
                prep()
                enlistment.Prepared()
            with e -> enlistment.ForceRollback(e)
        member this.Rollback(enlistment) =
            for kv in undo do
                updateWithPair backingStore kv
            undo <- Seq.empty
            finished()
            enlistment.Done()

Notice the calls to finished() and lockStore(). These are the functions that were passed by the TransactionalDictionary to the TransactionValues instance in the constructor. The lockStore function locks the dictionary while it’s being updated, so no other transaction can update it at the same time. Then we replay all the changes that have been made over the course of the transaction, updating and deleting keys in the backing store. As we go, we keep a record of the changes that we made. If something goes wrong and the transaction has to be rolled back, we undo the changes we just made using the undo information.

When the transaction either commits or rolls back, then finished() is called to release the lock on the dictionary so that other transactions can update it.

The normal course of events is that the Completed method is called on the TransactionScope before it is disposed, then the transaction manager will call Prepare on each IEnlistmentNotification. If each of them replies with a call to Prepared on the enlistment object, then the transaction manager calls Commit on each IEnlistmentNotification.

Note that Commit is never supposed to fail – you’re expected to have already done the work you needed to do in Prepare, and Commit is just letting you know that this transaction is officially done. If something goes wrong in Prepare, you call the ForceRollback method on the enlistment, and this causes the transaction to roll back.

The documentation says that the methods may not necessarily be called in this order, however, which is why the Commit implementation above is built to also do the work of Prepare if the Prepare method was never called.

The Result

Now we have a fully transaction-aware dictionary. The same kind of logic can be extended to your cache, or to other kinds of transaction-aware objects you may need. I hope you find it useful. Please let me know if you have any comments, questions, or suggestions.

Get The Code

All the code for this article and more is available on GitHub as part of the xoltar-sharp repository. The xoltar-sharp repository is a (currently very small) collection of utilities to simplify the development of complex applications. The transactional dictionary discussed in this article is the first of hopefully many tools that will be added to the xoltar-sharp package over time. I’ll also be releasing it as a NuGet package when it’s ready.

References and Acknowledgements

Thanks to F# guru Phil Trelford for graciously reviewing the transactional dictionary code!

Thanks to Microsoft for making a version of Visual Studio that supports F# available for free!

By far the most useful article I read while researching this one was Juval Lowy’s article, Volatile Resource Managers in .Net Bring Transactions to the Common Type, on MSDN. The TransactionLock type in xoltar-sharp (mentioned in this article, but not examined) is almost entirely based on on Lowy’s C# TransactionLock

Others that were useful include:

• Committing a Transaction in Single-Phase and Multi-Phase
• Enlisting Resources as Participants in a Transaction
• IEnlistmentNotification Interface
• Who stole my transaction?
• How do I create a transacted resource?
• IEnlistmentNotification: Implementation Nuances
• How to be sure that all IEnlistmentNotification.Commits are called?

1. Named Constraints

I have lots of constraints in my code, things like:

type Thing =
    abstract member Foo : int

let foo<'a, 'b
            when 'a <: Thing
             and 'b : comparison> () =
    failwith "not implemented"

let bar<'a, 'b
            when 'a <: Foo
             and 'b : comparison> () =
    failwith "not implemented"

Repeating those constraints over and over again is so not DRY. I wish I could define that constraint once and just reference it where needed.

2. Compiler as a service

Aside from the fact that C# and VB are getting compiler as a service, there’s the additional justification provided by F# quotations. When you have something as useful as F# quotations, why not provide a method to compile them to good quality code?

3. Type classes

F# doesn’t support type classes, which means that lots of useful things from Haskell don’t port easily. For instance, if you want to use map, you have to specify List.map, Seq.map, SomeOtherThing.map, etc., but with type classes, we could have a single “map” function that would find the right implementation depending on the (static) types it’s called on. There are workarounds, but they’re not the real thing. We need the real thing.

4. Parameterized Modules

One thing I tried to make my constraints DRY was to mention them at the module level:

type Thing =
    abstract member Foo : int

module ThingMod<'a, 'b
            when 'a <: Thing
             and 'b : comparison> =

    let foo () =
        //code that mentions 'a or 'b
        failwith "not implemented"

    let bar () =
        //code that mentions 'a or 'b
        failwith "not implemented"

Of course this isn’t supported at all, but I can’t see a reason why it shouldn’t be.

For that matter, it’s a shame that the full ML module system isn’t supported. I really wish we could have either ML modules or type classes. Don’t need both, but do need one or the other.

5. Better syntax for anonymous functions

I know it’s traditional, but (fun x –> expr) is too clunky when C# is doing x  => expr.

6. Macros, campl4 style or otherwise

Not having macros is limiting. You don’t need macro support often, but when you need it, you need it.

7. Better Intellisense

Intellisense for F# in VS 2012 is worlds better than in 2010, but it’s nowhere near as good as the C# support. Needs to work as well for F# as it does for C#.

8. Refactoring support

This is required in today’s world. ReSharper, I’m looking at you, too. 

9. Folder Creation in Solution Explorer

I can have folders in my F# project, I just can’t create them in Visual Studio. Disappointing. I can work around by editing the fsproj file, but I shouldn’t have to.

10. More F# Developers at Microsoft!

Come on, Microsoft! Your F# developers are doing great work, but you need more of them! It’s unacceptable that some Visual Studio features don’t work with F#, that things like Silverlight and Windows 8 get released with caveats like “F# is supported, but you have to use C# to build the front end.” Stop pretending this is a language that’s only useful for heavy computer science – it’s a general purpose language!

Start with the latest Haskell Platform. Then install the Snap packages with cabal. A record of the steps I had to perform on my system is here. Once you’ve got a working Snap install, the easiest way to accomplish the steps listed below is to just clone the snapazure github repository. After that you can skip to the “Packing and Deploying” section.

Start by adding the various configuration files that Azure needs to know how to package up the application.

The most important one is the .csdef file that tells Azure about the files that comprise your application. I’ll spare you the actual XML, please take a look at the repository. There’s an interesting trick in there for passing environment variables to the application so that it can listen on the correct host and port – credit for this is due to Steve Marx, who used it first in his pythonrole project.

The .config files are also XML files, they specify primarily the number of instances of your service that Azure should run when you upload them.

Once those files are in place, make a folder called WorkerRole, cd into it, and do “snap init” to create your Snap application. Build it using “cabal install –bindir=.” so that the executable will be placed in the WorkerRole folder.

Packing and Deploying

Next, “cd ..” and then run “cspack ServiceDefinition.csdef” – this will create the ServiceDefinition.csx file, which is the archive that you’ll upload to Azure. You’ll then go create a Cloud Service, and upload the ServiceDefinition.csx along with the ServiceConfiguration.Cloud.config file to either the staging or production site. It may take quite some time (my first upload took around 15 minutes), but in the end you’ll have a Snap application running in your Azure account.

Here’s mine: http://snapdemo.cloudapp.net

Github repo to get you started: http://github.com/xoltar/snapazure

1. Install the Haskell Platform. You want version 2012.2.0.0 or later.

2. Install Git. You’ll need this later.

3. Open up a command prompt and type:

cabal install snap

This will run for some time, and, if your experience is like mine, eventually fail while trying to build the "network" package. It will complain about the fact that a configure script is present and that it needs a Unix toolchain for that. If this step actually succeeds for you, great, you’re done. If it failed on something else, good luck to you.

4. Open up a Git Bash window. Type:

which ghc

to find your GHC location. It will be something like /c/Program Files/Haskell Platform/2012.2.0.0/bin/ghc. In the 2012.2.0.0 folder will be GHC’s installation of mingw. Add the path to that mingw folder’s bin folder. On my machine, this looks like:

export PATH=$PATH:/c/Program\ Files/Haskell\ Platform/2012.2.0.0/mingw/bin

You can verify that you’ve done it right by checking to make sure you can run gcc:

gcc --version

if you get a message with a version number back, you’re ready for the next step.

4. Run:

cabal install network

Assuming that worked, go back to your original command window and do:

cabal install snap

5. If this fails with a compile error in the snap package as it did for me, then do:

git clone git://github.com/snapframework/snap

6. cd into the newly created "snap" folder

7. Run

cabal install

to build and install from the source version

You’re done! You can now follow the Getting Started guide to create your first Snap application.

Here’s how it can happen. If you have a constraint like <'a when 'a :> IFace>, where IFace is an interface type, if the compiler doesn’t have enough information to establish a concrete type for 'a, then at runtime, typeof<'a> will actually be IFace, not some derived, concrete type as you might have hoped. This may sound obvious, but it probably won’t be, the first time it happens to you.

Below is a code sample that gives a real-world example. Here we’re trying to instantiate a record type via reflection. In two of the test cases, we give the compiler enough information, and it correctly uses a concrete type. When we don’t provide enough, it defaults back to IFace, which leads to trouble – it tries to instantiate IFace as if it’s a record type, which certainly doesn’t work. This isn’t a bug – after all, in pretty much any situation not involving reflection, the supertype is a reasonable default – but it can be surprising.

It would be great to have a new kind of type constraint that could insist that the type be instantiable, i.e. concrete, non-abstract. Maybe something like <'a when 'a :> IFace and 'a:concrete>. With such a constraint in place, we’d get a compile error instead of a runtime error if the compiler couldn’t prove that the type was concrete at any particular call site.

For the moment, though, just be aware that there is no such constraint, and you have to consider the possibility that your constrained type might just be an interface type. There is the 'a : (new: unit->'a) constraint that works just like the new constraint in C#, and that would help, except it only works with a no-args constructor, which wouldn’t be appropriate for our example at all, since we don’t even know ahead of time how many arguments we’re going to pass the constructor.

This is just something to be aware of, so when you get exceptions with messages like “Type ‘ConstraintTest+IFace’ is not an F# record type,” or “Constructor on type ‘ConstraintTest+IFace’ not found,” you don’t spend too much time thinking “Of course it isn’t! Why did you think that would work, compiler?”

By the way, Matt Podwysocki has a great series on what you can do with constraints in F#: Part 1, Part 2, Part 3. You should definitely head there next.

module ConstraintTest

open NUnit.Framework

    //A simple interface
    type IFace =
        abstract member X: int

    //A record type that implements the interface
    type Foo = {FooX:int}
        with
            interface IFace with
                member this.X = this.FooX

    //A function that instantiates a new record
    //There's a type constraint to ensure the record type implements IFace.
    let makeRecord<'a when 'a :> IFace> (values: obj array) =
        let record = Activator.CreateInstance(typeof<'a>, values)
        record :?> 'a

    [<Test>]
    let ``insufficient type info``() =
        //F# can't figure out the concrete type, defaults to substituting IFace for 'a
        let exc = Assert.Throws<System.MissingMethodException>(fun () -> makeRecord [|1|] |> ignore)
        printf "%A\n" exc

    [<Test>]
    let ``specified type``() =
        //We help F# figure out what the concrete type should be, no problem.
        let record:Foo = makeRecord [|1|]
        ()

    [<Test>]
    let ``specified type 2``() =
        //Again, we help F# figure out what the concrete type should be (in a different way), no problem.
        let record = makeRecord<foo> [|1|]
        ()

It turns out that more and more people are being put out of a job by robots. Not just repetitive factory work, mind. Pathologists. Sports reporters. Soon, drivers.  There are, as we all know, lots of things computers do better than we do. That list is growing all the time, and it’s growing faster. Moore’s law says that computing power doubles every eighteen months, and if that continues to hold true, we’re going to start seeing almost unimaginable science fiction-type robots and computers, very, very soon.

People seem not to be paying attention to this issue. I don’t want to call it a problem, because it’s just reality. However, for many (most? all?) of us, it will feel like a problem. It’s not just a matter of losing your current job, of suffering economic loss until you can retrain and find your balance in this new world. It’s a matter of being completely outmoded.

There’s really nothing special about humans. Unusual, perhaps, but not unique. People routinely claim that this or that trait is “uniquely human,” without the faintest justification. My cats have most of these “uniquely human” characteristics, too.  There are others that the cats don’t have, but they’re not uniquely human, either. Laughter was the one I heard last. Turns out rats laugh too. Tool use is an old one. Chimps. Ravens. Lots of things use tools. Not unique.

There’s also nothing about carbon that makes it uniquely better for supporting life than silicon. True, there are things that we’re better at than computers are, today. We have emotions, better vision, better language processing, a few other advantages. This will change. Computers are getting better, smarter, faster, every single day, and we’re staying basically the same. Evolution is obsolete. Robots will be better than us in every conceivable way, sometime soon. Maybe within my lifetime. My kids, if I ever have any, might well be the last human generation, unless we figure out some kind of way to live in a world where robots are better than us at everything.

We have to figure this out. Nobody’s going to stop improving robots or computers. To keep this from happening, we’d have to have everyone agree to stop. At the same time. Sort of like how we collectively decided to restrain the development of nuclear weapons. The important difference, though, is that the atom bomb looks like the end of the world. Better robots just look like a pile of cash for the people who make them. There’s no stopping piles of cash.

What we need to do is come up with a plan for how to deal with this transition. Can we come up with some way to improve ourselves as quickly as we improve technology? Can we somehow remain as we are, yet stay in control and actually have our lives improved? There are many unknowns. This could be a coming golden age, or it could easily be crisis in the making, as big a problem as clean drinking water or global climate change. Take some time to think about it. How can we prepare for the day when robots do everything better than we do?

	function set-frameworkversion($version) {
		#scan current directory and below for project files
		#Add project types as desired
		$projects = dir -r . -include *.csproj,*.fsproj;
		$projects | % {
			$x = [xml](gc $_);
			$x.project.propertygroup[0].TargetFrameworkVersion = $version;
			 $x.save($_)
		}
	}

Use like this: set-frameworkversion 'v4.5'

If anyone knows a better way or has corrections, please share!