Category Archives: .net

.net, microsoft, professional, sql

Microsoft LocalDB: another option for local databases

6 Comments

Microsoft is launching SQL Server 2012 on  March 7th 2012. In Microsoft’s world “launches” do not always coincide with the availability of release code, which may come before or after, but they are usually not far apart.

The big news in SQL Server 2012 is in new BI (Business Intelligence) features and the ability to import and export from the open source Hadoop framework. Microsoft is also supporting Hadoop on Windows Server and Windows Azure. Robert Sheldon has an excellent article on TechTarget which describes the Hadoop integration.

At the other end of the scale though there is a new approach to local databases, which interests me as this is the kind of thing an application developer might use for local applications. SQL Express LocalDB uses the full SQL Server Express engine but does not require a SQL Server service to be running or even installed. In summary:

  • The LocalDB binaries can be installed with a separate installer or as part of the SQL Server Express.
  • LocalDB instances are isolated to the user.
  • The LocalDB system databases are buried deep in AppData in the user profile. The default location for user databases is the root of the user profile.
  • The old SQL Server User Instances are now deprecated

A driver for LocalDB has to know how to fire up the SQL Server binaries if they are not running, which means that old drivers will not work. Microsoft has patched System.Data.SqlClient in .NET 4 to work with LocalDB.

LocalDB Pros and cons

The advantage of LocalDB over the cut-down Compact Edition is that you get full access to SQL Server features including transactions, stored procedures, geographical data types and so on. It is meant to improve on the old user instances by simplifying matters for the user: no need to run a service, and management of SQL Server completely hidden.

The disadvantage is that your app still has the overhead of SQL Server running in a separate process. A SQL Server LocalDB install also takes around 140MB, which bumps up the download size if your app is distributed on the web.

If you need a local database, it seems to me that Microsoft still has nothing that quite matches SQLite, which runs in-process, is lightning fast, and which does not require any hidden system databases.

On the other hand, it might make sense to use SQL Server if you want to integrate with a server database, or if you are familiar with coding for SQL Server.

I would like to see Windows ship with a local database engine documented as something developers can rely on being there, as with Core Data on the Mac. It would also help if the SQL Server team got together with the Office team and worked out how to get Access and SQL Server Express to use the same database engine – yes, I know Access can use SQL Server data, but it still defaults to its own .ACCDB format and JET database engine.

.net, microsoft, windows, windows 7

OEMs are still breaking Windows: can Microsoft fix this with Windows 8?

10 Comments

Mark Russinovich works for Microsoft and has deep knowledge of Windows internals; he created the original Sysinternals tools which are invaluable for troubleshooting.

His account of troubleshooting a new PC purchased by a member of his family is both amusing and depressing, though I admire his honesty:

My mom recently purchased a new PC, so as a result, I spent a frustrating hour removing the piles of crapware the OEM had loaded onto it (now I would recommend getting a Microsoft Signature PC, which are crapware-free). I say frustrating because of the time it took and because even otherwise simple applications were implemented as monstrosities with complex and lengthy uninstall procedures. Even the OEM’s warranty and help files were full-blown installations. Making matters worse, several of the craplets failed to uninstall successfully, either throwing error messages or leaving behind stray fragments that forced me to hunt them down and execute precision strikes.

I admire his honesty. What he is describing, remember, is his company’s core product, following its mutilation by one of the companies Microsoft calls “partners”.

Russinovich adds:

As my cleaning was drawing to a close, I noticed that the antimalware the OEM had put on the PC had a 1-year license, after which she’d have to pay to continue service. With excellent free antimalware solutions on the market, there’s no reason for any consumer to pay for antimalware, so I promptly uninstalled it (which of course was a multistep process that took over 20 minutes and yielded several errors). I then headed to the Internet to download what I – not surprisingly given my affiliation – consider the best free antimalware solution, Microsoft Security Essentials (MSE).

Right. I do the same. However, the MSE install failed, probably thanks to a broken transfer application used to migrate files and settings from an old PC, and it took him hours of work to identify the problem and complete the install.

What interests me here is not so much the specific problems, but Microsoft’s big problem: that buying a new Windows PC is so often a terrible user experience. Not always: business PCs tend to be cleaner, and some OEMs are better than others. Nevertheless, although I have had Microsoft folk tell me a number of times that its partners were getting the message, that to compete with Apple they need to deliver a better experience, the problem has not been cracked.

There is something about the ecosystem which ensures that users get a bad product. It goes like this I guess: customers are price-sensitive, and to get the price required OEM vendors have to take the money from malware companies and others desperate to drive users towards their products. Yet in doing so they perpetuate the situation where you you have to buy Apple, or be a computer professional, in order to get a clean install. That describes a broken ecosystem.

Microsoft’s Signature PCs are another option, but they are only available from Microsoft stores.

The next interesting question is whether Microsoft can fix this with Windows 8. It may want to follow the example of Windows Phone 7, which is carefully locked down so that OEMs and operators can add their own apps, but their ability to customise the operating system is limited, protecting the user experience. It is hard to see how Microsoft can achieve the same with the x86 version of Windows 8, since this remains an open platform, though it may be possible to insulate the Metro side from too much tinkering. Windows 8 on ARM, on the other hand, may well follow the Windows Phone pattern.

.net, professional, software development, web authoring

The mystery of unexpected expiring sessions in ASP.NET

2 Comments

This is one of those posts that will not interest you unless you have a similar problem. That said, it does illustrate one general truth, that in software problems are often not what they first appear to be, and solving them can be like one of those adventure games where you think your quest is for the magic gem, but when you find the magic gem you discover that you also need the enchanted ring, and so on.

Recently I have been troubleshooting a session problem on an ASP.NET application running on a shared host (IIS 7.0).

This particular application has a form with some lengthy text fields. Users complete the form and then hit save. The problem: sometimes they would take too long thinking, and when they hit save they would lose their work and be redirected to a login page. It is the kind of thing most of us have experienced once in a while on a discussion forum.

The solution seems easy though. Just increase the session timeout.  However, this had already been done, but the sessions still seemed to time out too early. Failure one.

My next thought was to introduce a workaround, especially as this is a shared host where we cannot control exactly how the server is configured. I set up a simple AJAX script that ran in the background and called a page in the application from time to time, just to keep the session alive. I also had it write a log for each ping, in order to track the behaviour.

By the way, if you do this, make sure that you disable caching on the page you are pinging. Just pop this at the top of the .aspx page:

<%@ OutputCache Duration="1" Location="None" VaryByParam="None"%>

It turned out though that the session still died. One moment it was alive, next moment gone. Failure two.

This pretty much proved that session timeout as such was not the issue. I suspected that the application pool was being recycled – and after checking with the ISP, who checked the event log, this turned out to be the case. Check this post for why this might happen, as well as the discussion here. If the application pool is recycled, then your application restarts, wiping any session values. On a shared host, it might be some else’s badly-behaved application that triggers this.

The solution then is to change the way the application stores session variables. ASP.NET has three session modes. The default is InProc, which is fast but not resilient, and for obvious reasons not suitable for apps which run on multiple servers. If you change this to StateServer, then session values are stored by the ASP.NET State Service instead. Note that this service is not running by default, but you can easily enable it, and our helpful ISP arranged this. The third option is to use SQLServer, which is suitable for web farms. Storing session state outside the application process means that it survives pool recycling.

Note the small print though. Once you move away from InProc, session variables are serialized, not just held in memory. This means that classes must have the System.Serializable attribute. Note also that objects might emerge from serialization and deserialization a little different from how they went in, if they hold state that is more complex than simple properties. The constructor is not called, for example. Further, some properties cannot sensibly be serialized. See this article for more information, and why you might need to do custom serialization for some classes.

After tweaking the application to work with the State Service though, the outcome was depressing. The session still died. Failure three.

Why might a session die when the pool recycles, even if you are not using InProc mode? The answer seems to be that the new pool generates a new machine key by default. The machine key is used to encrypt and decrypt the session values, so if the key changes, your existing session values are invalid.

The solution was to specify the machine key in web.config. See here for how to configure the machine key.

Everything worked. Success at last.

.net, apple, mobile

Why developers need a Mac

18 Comments

I am by no means an Apple fan. For one thing, I find Windows (and Linux) stable and fast, so you are not going to hear me argue that my computing life was transformed once I made that Switch (with a capital letter). Admittedly that is partly because I am familiar with how to fix and tune Windows and remove foistware, but it is not that hard. For another, I am not an admirer of Apple’s secretive approach, or the fact that most requests for comment from journalists are responded to with silence. For a third, I dislike the notion that all apps for its popular mobile platform must be distributed through the Apple store and subject to a fee, now extended to in-app upgrades and subscriptions as well as initial sales. There is also much that I admire about Apple’s platform, but I hope I have convinced you that I am not so bedazzled by the company that I am unable to think coherently about its products.

Nevertheless, I have run a Mac alongside Windows for years now, and I find myself needing it increasingly. Here are four reasons.

The first is that sooner or later you will need to build or test an app for the Mac or, more likely, for iOS. You can only do so using a Mac (leaving aside the exciting world of the hackintosh). This is because Apple only provides the iOS SDK and simulators for its own operating system.

As an aside, I recently spoke to Keith Varty who is evangelising Windows Phone development at Nokia. I asked about the issue of Visual Studio only running on Windows, was that an obstacle for developers using a Mac? He pointed out that it is the same in reverse with Apple, you need a Mac to develop for the iPhone. In fact, it is easier to develop for Windows using a Mac, thanks to the existence of excellent PC emulators, than it is to develop for a Mac using Windows. In any case, special rules apply for Apple.

Second, other than in the most closed internal environments, some of your users will have a Mac or at least an iPad or iPhone. A few years back both developers and system administrators could get away with a deliberate ignorance of Apple computers, saying they are “not supported” or “untested” or just “I have no idea.” That is no longer acceptable (if it ever was) and it is important to test apps on a Mac where that is appropriate, as with web or cross-platform Java or Adobe AIR applications, and more generally to get a feel for how things work on a Mac so that you can respond intelligently to users.

Third, in many areas of development Macs are now dominant. This means that Windows-only developers may be disadvantaged. Today, for example, I was researching Sencha products and came across this:

image

Yes, to get the preview developer tools for Sencha Touch 2, you need a Mac. No doubt Windows versions will follow, but there are times when you need a Mac just to keep up with the latest technology.

Fourth, and this is the most difficult point to make, it is valuable to spend some time on a Mac to avoid bad assumptions about usability. One example that comes to mind is version control. On Windows there is no problem using Git, or Subversion, or any number of systems including Microsoft’s Team Foundation Server installed either locally or on its own server. There is some setup involved though. On a Mac with the latest Xcode, you will find a checkbox in the new project wizard:

image

It is built-in. There is nothing more to do other than check this box. And yes, I know it is pretty easy to use Subversion or Git on Windows – though I would never describe a Team Foundation setup as trivial – but I am talking about the usability of a single checkbox. If you are thinking about the design of your own UI then spending some time on a Mac is though-provoking and likely to be beneficial.

By the way, some other parts of Xcode are less usable than Visual Studio so do not read too much into this example!

Another example which comes to mind is installing a web server. Windows has IIS, which is a good web server, and you can enable it on Windows 7 by going to Control Panel, Programs, Turn Windows Features on and off, and then waiting while the dialog populates, and then checking which bits of IIS you want to install:

image

Not difficult, though the intricacies of which Application Development Features you need may require some research. But here is how you set up Apache on a Mac. Go to System Preferences, and check Web Sharing. Apache is now up and running, and on my Mac Mini it started instantly:

image

I am sure there are many more examples, and even examples where Windows has better usability than then Mac (I miss the thumbnail previews in the task bar) but my point is this: it pays to have experience beyond Windows from which to evolve your own user interface ideas.

Post sponsored by Monster for the best in IT Jobs.

.net, adobe, flash, professional, software development, web authoring

What next for Adobe Flash? Think runtime not plugin

2 Comments

Adobe is stating that mobile Flash will no longer be developed:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook. We will of course continue to provide critical bug fixes and security updates for existing device configurations. We will also allow our source code licensees to continue working on and release their own implementations.

Although this seems like a major shift in strategy, Adobe has been moving in this direction for some time. At the MAX conference last month the company was clear that most web developers can be expected to use HTML 5 rather than Flash most of the time, reserving use of the plug-in for video, games and certain kinds of application. As for mobile, all the talk was about AIR and the captive runtime, an approach similar to the iOS packager which bundles the Flash runtime into your application so that no plug-in or additional download is required.

This approach is now explicit, and I reckon we can further conclude that if the Flash plugin for mobile is being abandoned, then the Flash plugin for the desktop is also less important than before. Mobile browsing is huge, and likely to grow, so developing web pages for Flash is unattractive other than in cases where there is an easy way to direct mobile browsers to a non-Flash alternative. Flash as a browser plugin will now decline forever, which is a good thing for web standards even if it is not necessarily a good thing for web developers, who must face the challenge of cross-browser development.

So what is Flash now? It is still Adobe’s runtime, and the client for its media services, and in that role it remains significant. Thanks to Adobe’s packaging work, you can take your Flash or Flex application and deploy it to most desktop and recent mobile platforms, though not to Windows Phone or older Android devices. Could you not use HTML 5, JavaScript and PhoneGap instead? Maybe in some cases; but Flash is a richer, faster and more consistent platform, as well as benefiting from Adobe’s design and development tools.

See also my piece for the Register: Down but not out: Flash in an HTML5 world.

Update: Added official Adobe link for statement on mobile Flash.

.net, apple, development, microsoft, mobile, professional, software development, visual studio, windows

Quick thoughts on Xcode and Objective C versus Microsoft’s tools

2 Comments

I have been trying out JetBrains’ AppCode which meant working in an Apple development environment for a time. I took the opportunity to implement my simple calculator app in iOS native code.

image

Objective C is a distinctive language with a mixed reputation, but I enjoy coding with it. I used Automatic Reference Counting (ARC), a feature introduced in Xcode 4.2 and OSX 10.7, iOS 5; ARC now also works with 10.6 and iOS 4. This means objects are automatically disposed, and I did not have to worry about memory management at all in my simple app. This is not a complete memory management solution (if there is such a thing) – if you use malloc you must use free – but it meant that the code in my app is not particularly verbose or complex compared to other languages. Apple’s libraries seem to favour plain English method names like StringByAppendingString which makes for readable code.

I was impressed by how easy it is to make an app that looks good, because the controls are beautifully designed. I understand the attraction of developing solely for Apple’s platform.

I also love the integrated source control in Xcode. You find yourself using a local Git repository almost without thinking about it. Microsoft could learn from that; no need for Team Foundation Server for a solo developer.

I did miss namespaces. In Objective C, if you want to remove the risk of name collision with a library, you have to use your own class prefix (and hope that nobody else picked the same one).

image

Interface Builder, the visual UI designer, is great but many developers do not use it, because coding the UI without it is more flexible. It is a shame that you have to make this choice, unlike IDE’s with “two way tools” that let you edit in code or visually and seamlessly keep the two in synch. I found myself constantly having to re-display windows like the Attributes Inspector though it is not too bad once you learn the keyboard shortcuts. The latest Interface Builder has a storyboard feature which lets you define several screens and link them. It looks useful, though when I played with this I found it difficult to follow all the linking lines the designer drew for me.

It is interesting to compare the Mac and iOS development platform with that for Windows. Microsoft promotes the idea of language choice, though most professional development is either C# or C++, whereas on Apple’s platform it is Objective C and Cocoa or you are on your own. Although Mac and Windows are of a similar age, Microsoft’s platform gives a GUI developer more choices: Win32, MFC, WTL, Windows Forms, Windows Presentation Foundation and Silverlight, and in Windows 8 the new WinRT.

I get the impression that Microsoft is envious of this single-minded approach and trying to bring it to Metro-style Windows 8, where you still have a choice of languages but really only one GUI framework.

That said, Visual Studio is an impressive tool and both C# and C++ have important features which are lacking in Objective C. I would judge that Visual Studio is the more productive tool overall, but Apple’s developer platform has its own attractions.

.net, microsoft, professional, silverlight, software development

Windows Runtime must come to Windows Phone

1 Comment

I’ve been trying Windows Phone 7 in its latest “Mango” version over the last couple of days and mostly enjoying it. One thing I am not impressed by though is the range of apps available. Have a look at the Marketplace – Microsoft may claim 30,000 apps, but given how unexciting even the “top” selections are, you can imagine how bad the bottom ones must be. Microsoft I guess has been guilty of accepting almost anything to puff up the numbers.

What would fix this? Sell more phones, of course; but also improve the platform for developers. Windows Phone 7.x is not a bad platform: you get Silverlight, XNA, C# and Visual Studio.

By contrast though, the Windows Runtime (WinRT) shown at the BUILD conference earlier this month is a platform mobile developers can love. Here are what seem to me three great features:

  • Three first-class languages and programming platforms – C#/.NET, JavaScript and HTML 5, C++ and native code. All three are strategic platforms. I particularly like the native code option, as many mobile developers like native code and it is a weakness of Windows Phone 7.
  • Asynchrony built into the platform. This is a smart move: make every API call that might cause a delay an async-only call. On top of that, build easy async programming into the languages. The result should give apps a responsive user interface almost by default; developers will need to make an effort to freeze the UI.
  • Contracts which integrate apps with the operating system and with one another. There are five contracts: search, share, play to, settings, and app to app picking (for example, file selection).

Microsoft’s Windows chief Steven Sinofsky says Windows 8 is for tablets but not for phones. But he has to say that, because if Microsoft announced that the current Windows Phone 7.5 is a platform without a future, it would further dampen enthusiasm for the product.

Is there any reason why WinRT should not come to Windows Phone? A few:

  • Windows Phone is currently built on Windows CE, a cut-down version of Windows, whereas WinRT runs on top of the full Windows API.
  • The Metro-style UI is designed for tablets rather than phones.
  • Finally, the existence of Desktop Windows is presumed in the current Windows 8 design. If Microsoft has not had time to work out a Metro-style UI for something, you simply use the Desktop version.

All of these are good reasons why the arrival of WinRT on the phone will be delayed, but none are insuperable. Long-term, I find it inconceivable that Microsoft will persevere with a different programming platform for the phone and for tablets.

What are the implications for Windows Phone developers today? Well, WinRT and Metro borrow from the phone OS, so the porting effort should not be too bad, except in the case of XNA, a .NET wrapper for DirectX which WinRT does not support.

Of course this post is entirely speculative, and I have no insight into Microsoft’s plans beyond what is publicly stated, so there might be other compatibility options when and if the time comes.

And it is time that is Microsoft’s biggest enemy. Fumbling tablet computing has been a costly mistake, and the big question is whether anyone will care how good some future Windows Phone will be, if the ecosystem which Nokia likes to talk about is firmly established as Android vs Apple.

.net, apple, linux, microsoft, mobile, windows

Miguel de Icaza talks about Windows 8 and the failure of Linux on the desktop

29 Comments

At Microsoft BUILD earlier this month I arrived early to hear Anders Hejlsberg talk about the future of C#, and found myself next to Miguel de Icaza, co-creator of the GNOME desktop and of Mono, the open source implementation of Microsoft .NET. I took the opportunity to ask a few questions, which I have his permission to post.

I recall that when .NET was first announced in 2000, it was not long before de Icaza announced Mono. I was interested therefore to know his reaction to Windows 8 and the new Window Runtime which powers “Metro-style” apps. Will we get an open source implementation of Metro-style on Linux?

I don’t think so. To be honest, with Linux on the desktop, the benefits of open source have really played against Linux on the desktop in that we keep breaking things. It is not only incompatibilities between Red Hat, Unbuntu, Suse, but even between the same distribution.  Ubuntu from this week is incompatible with the one nine months ago. And then there are multiple editions, the KDE version, the Gnome edition, the one that is the new launching system.

When you count how many great desktop apps there are on Linux, you can probably name 10. You work really hard, you can probably name 20. We’ve managed to piss off developers every step of the way, breaking APIs all the time.

I’m heartbroken, that’s the bottom line.

What about compiling your Metro app for iOS or Android?

I think that Linux has a tough time on the desktop. And the desktop is starting to not matter any more. On the other hand, building WinRT is going to be a significant amount of work. A large chunk probably could be reused from Moonlight. But it is a lot of work, to be able to reuse existing Windows apps, and in the case of iOS they already have their own stack, and Mac has its own, Cocoa is really nice and we have .NET bindings for it.

So I think we’ll learn interesting lessons from Metro. There is stuff that will be useful on other platforms like the JSON reader. But I’m not going to spend any time on WinRT for other systems.

And we can speculate about how well Metro will work in the market …

They are Microsoft, it’s going to succeed. In three years they are going to have this thing on half a billion computers, so it will be out there.

It seems like they are going to use their muscle for two things. It’s going to be a tempting space [for developers], but if you want to go into the right distribution channel for that half a billion computers, you need to abide by the Metro guidelines. They are not going to give you full API access, they are going to give you the sandboxed version. Which is good, because it can finally fix the security problems on Windows. They are going to use their muscle to reset the rules for Windows.

Especially on ARM

Right, and it is needed, they definitely need to fix this mess, a lot of malware, spyware, and the fact that everybody is sysadmin, and has to reinstall their machine every so often.

I’ve heard the word “safe” a number of times.

Right, and think of an iPad, you don’t need to be a sysadmin.

Now, you could argue that by WPF not being available to everybody and being bound to .NET they limited the effect WPF would have had, whereas Metro gives this to C++ developers, but they’re saying, hey, you can’t call Win32, there is all the Win32 stuff you can’t call. You have to use Metro. So they might be repeating that [mistake], but maybe it’s eclipsed by the fact that there’s going to be a rush to the app store. It seems like there is a big enough carrot now.

How are you getting on with the Windows 8 tablet?

I have to say, I actually like Windows 8. I am not a Windows user. It’s probably the first time that I would use a Windows machine.

Miguel de Icaza is now at Xamarin, providing cross-platform tools for using C# and .NET to build apps for Apple iOS and Google Android.

.net, microsoft, professional, software development, visual studio, windows

A simple example of async and await in C# 5

10 Comments

I have been playing with the Visual Studio 11 developer preview and exploring its asynchronous features, specifically the async and await keywords which are new to C# 5.0. These features have actually been available as a CTP (Community Tech Preview) since October 2010, but I had not found time to try it.

I like to keep examples as simple as possible. I have a Windows Forms application which has a long-running task to perform, and I do not want to lock the UI while it runs. Here is my long-running function:

 private int slowFunc(int a,int b)       
 {          
 System.Threading.Thread.Sleep(10000); 
 return a + b;
 }

Yes, it takes 10 seconds! I am going to click a button on a form, call the function, and show the result on a label control.

Now, here is how I might try to achieve the goal of not locking the UI using Visual Studio 2010 and C# 4.0:

 private void button1_Click(object sender, EventArgs e)
 {            
 this.button1.Enabled = false; //prevent re-entry 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2));
 this.label1.Text = "Result: " + someTask.Result.ToString(); //oops, blocks calling thread 
 this.button1.Enabled = true;       
 }

Oops, this did not work at all! The reason is that although I have gone to the trouble of creating a Task in order to run the slow function on a background thread, my work is undone when I call the Result property of the Task object – since this blocks the thread until the Task completes.

Here is how you can fix it in Visual Studio 2010 – remember, there is an easier way in C# 5.0 coming up soon:

 private void button1_Click(object sender, EventArgs e)        
 {
 this.button1.Enabled = false;          
 var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext(); //get UI thread context 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); //create and start the Task 
 someTask.ContinueWith(x =>     
   {                                          
   this.label1.Text = "Result: " + someTask.Result.ToString();   
   this.button1.Enabled = true;   
   }, uiScheduler  
  );        
 }

This one works. I click the button and the UI does not lock up at all; I can minimize the form, move it around the screen, and so on.

However, I have had to do some extra work. The ContinueWith method tells the Task to run some other code after the background thread has completed. By default this code will not run on the UI thread, which means it will raise an exception when it updates the UI, but you can pass in a TaskScheduler object so that it continues on the UI thread.

Now here is a look at the same problem using C# 5.0. The slowFunc is the same, so I will not retype it. Here is the code for the button click:

 private async void button1_Click(object sender, EventArgs e)
 {
 this.button1.Enabled = false; 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); 
 await someTask;  
 this.label1.Text = "Result: " + someTask.Result.ToString(); 
 this.button1.Enabled = true;
 }

Less code, same result, which is usually a good thing.

What is going on here though? First, the async modifier is added to the click event handler. This does not mean that the method runs asynchronously. It means that it contains code that will run asynchronously using await. As Eric Lippert explains, it tells the compiler to rewrite the method for you.

Second, there is the await keyword. I cannot improve on Lippert’s explanation so here it is:

The “await” operator … does not mean “this method now blocks the current thread until the asynchronous operation returns”. That would be making the asynchronous operation back into a synchronous operation, which is precisely what we are attempting to avoid. Rather, it means the opposite of that; it means “if the task we are awaiting has not yet completed then sign up the rest of this method as the continuation of that task, and then return to your caller immediately; the task will invoke the continuation when it completes.”

If you refer back to the Visual Studio 2010 examples, you will see that the code is very close to my first, non-working example. In other words,using await makes the code work in the way that intuitively I hoped that it might, without specifically called the ContinueWith method and messing around with the thread context as in the second example.

This is still concurrent programming though. One thing that C# 5.0 cannot prevent is an impatient user clicking several times on the button when the result does not appear immediately, so in all the examples I have disabled the button while the background thread runs.

.net, microsoft, silverlight, software development

Reflections on Microsoft BUILD 2011

11 Comments

I’m just back from Microsoft’s BUILD conference at Anaheim in California, which lived up to the hype as a key moment of transition for the company. Some said it was the most significant PDC – yes, it was really the Professional Developers Conference renamed – since 2000, when .NET was introduced; some said the most significant ever.

image

“Significant” does not necessarily mean successful, and history will judge whether BUILD 2011 was a new dawn or the beginning of the end for Windows. Nevertheless, I have not heard so much cheering and whooping at a Microsoft conference for a while, and although I am no fan of cheering and whooping I recognise that there was genuine enthusiasm there for the new direction that was unveiled.

So what happened? First, let me mention the Windows Server 8 preview, which looks a solid upgrade to Server 2008 with a hugely improved Hyper-V virtualisation and lots of changes in storage, in IIS, networking, in data de-duplication, in modularisation (enabling seamless transition between Server Core and full Server) and in management, with the ascent of PowerShell scripting and recognition that logging onto a GUI on the server itself is poor practice.

The server team are not suffering the same angst as the client team in terms of direction, though the company has some tricky positioning to do with respect to Azure (platform) and Server 8 (infrastructure) cloud computing, and how much Microsoft hosts in its own datacentres and how much it leaves to partners.

What about Windows client? This is the interesting one, and you can almost hear the discussions among Microsoft execs that led them to create the Windows Runtime and Metro-style apps. There is the Apple iPad; there is cloud; there are smartphones; and Windows looks increasingly like a big, ponderous, legacy operating system with its dependence on keyboard and mouse (or stylus), security issues, and role as a fat client when the industry is moving slowly towards a cloud-plus-device model.

At the same time Windows and Office form a legacy that Microsoft cannot abandon, deeply embedded in the business world and the source of most of the company’s profits. The stage is set for slow decline, though if nothing else BUILD demonstrates that Microsoft is aware of this and making its move to escape that fate.

Its answer is a new platform based on the touch-friendly Metro UI derived from Windows Phone 7, and a new high-performance native code runtime, called Windows Runtime or WinRT. Forget Silverlight or WPF (Windows Presentation Foundation); this is a new platform in which .NET is optional, and which is friendly to all of C#, C/C++, and HTML5/JavaScript. That said, WinRT is a locked-down platform which puts safety and lock-in to Microsoft’s forthcoming Windows Store ahead of developer freedom, especially (and I am speculating a little) in the ARM configuration of which we heard little at BUILD.

BUILD attendees were given a high-end Samsung tablet with Windows 8 pre-installed, and in general the Metro-style UI was a delight, responsive and easy to use, and with some fun example apps, though many of the apps that will come as standard were missing and there was evidence of pre-beta roughness and instability in places.

The client strategy seems to me to look like this:

Windows desktop will trundle on, with a few improvements in areas like boot time, client Hyper-V, and the impressive Windows To Go that runs Windows from a bootable and bitlocker-encrypted USB stick leaving no footprint on the PC itself. Many Windows 8 users will spend all their time in the desktop, and I suspect Microsoft will be under pressure to allow users to stick with the old Start menu if they have no desire or need to see the new Metro-style side of Windows..

A new breed of Intel tablets and touch-screen notebooks will make great devices towards the high end of mobile computing. This is something I look forward to taking with me when I need to work on the road: Metro-style apps for when you are squashed in an aeroplane seat, browsing the web or checking a map, but full Windows only a tap away. These will be useful but slightly odd hybrids, and will tend to be expensive, especially as you will want a keyboard and stylus or trackpad for working in desktop Windows. They will not compete effectively with the iPad or Android tablets, being heavier, with shorter battery life, more expensive and less secure. They may compete well with Mac notebooks, depending on how much value Metro adds for business users mainly focused on desktop applications.

Windows on ARM, which will be mainly for Metro-style apps and priced to compete with other media tablets. This is where Microsoft is being vague, but we definitely heard at BUILD that only Metro-style apps will be available from the Windows Store for ARM, and even hints that there may be no way to install desktop apps. I suspect that Microsoft would like to get rid of desktop Windows on ARM, but that it will be too difficult to achieve that in the first iteration. One unknown factor is Office. It is obvious that Microsoft cannot rework full Office for Metro by this time next year; yet offering desktop Office will be uncomfortable and (knowing Microsoft) expensive on a lightweight, Metro-centric ARM device. Equally, not offering Office might be perceived as throwing away a key advantage of Windows.

Either way, Windows on ARM looks like Microsoft’s iPad competitor, safe, cloud-oriented, inexpensive, long battery life, and lots of fun and delightful apps, if developers rush to the platform in the way Microsoft hopes.

There are several risks for Microsoft here. OEM partners may cheapen the user experience with design flaws and low-quality add-ons. Developers may prove reluctant to invest in an unproven new platform. It may be hard to get the price down low enough, bearing in mind Apple’s advantage with enormous volume purchasing of components for iPad.

Still, one clever aspect of Microsoft’s strategy is that everyone with Windows 8 will have Metro, which means there will be a large installed base even if many of those users only really want desktop Windows.

I also wonder if this is an opportunity for Nokia, to use its hardware expertise to deliver excellent devices for Windows on ARM.

Finally, let me mention a few other BUILD highlights. Anders Hejlsberg spoke on C# and VB futures (though I note that there were few VB developers at BUILD) and I was impressed both by the new asynchronous programming support and the forthcoming compiler API which will enable some amazing new capabilities.

I also enjoyed Don Syme’s session on F#, where he focused on programming information rather than mere algorithms, and showed how the language can query internet data sources with IntelliSense and code hints in the IDE, inferred from schemas retrieved dynamically. You really need to watch his session to understand what this means.

In the end this was a great conference, with an abundance of innovation and though-provoking technology. In saying that, I do not mean to understate the challenges this huge company still faces.