Microsoft's Open XML standard for Office documents is controversial. Depending on your point of view, it somewhere between a breakthrough in opening up the standard in which the world's most popular office suite saves documents, or a cynical ploy to counter the momentum behind OpenOffice and its rival Open Document XML standard. Amidst all the arguments, it is easy to lose sight of the simple fact that, whatever its merits, Microsoft Office does now save by default in an XML format.
When Office 2007 came out, it was not really sensible to use the new XML formats, such as .docx for Word and .xlsx for Excel, outside the safety of an intranet. If you sent one as an email attachment, there was a good chance the recipient would not be able to read it. Still, now we have Office 2010 and SharePoint 2010, and Open XML has become both more important and less troublesome. It is the only format fully supported by the new Office Web Apps, for example. Further, most of us have had to come to terms with Open XML, at least to the extent that we can open them. Maybe it is time to see if the new formats might actually be useful.
The most obvious advantage of XML is that you can read and write documents using standard XML libraries. There is no need to have Microsoft Office installed, or to try and run it behind the scenes on a web server in order to parse or generate documents. That said, an Open XML document is not a single file akin to an HTML page. Instead, it is a set of related XML files bundled together as a ZIP archive, using another Microsoft standard called the Open Packaging Convention (OPC) If you are curious, you can rename a .docx to .zip, extract the files, and have a look.
If you have in mind to generate Office documents using an XML library, the bad news is that it is not a trivial thing to get right. The good news, at least for .NET developers, is that Microsoft has an Open XML SDK that wraps this complexity. The further bad news though is that the SDK does not free you from having to understand how an Open XML document is put together.
I discovered this for myself after downloading the latest version of the SDK, newly updated for Office 2010. I wanted to investigate how easy it would be to have a web application generate Word documents for download. It turned out to be frustrating. There is what looks like a nice help document with the SDK, including Getting Started articles and a complete reference. Unfortunately, it does not tell the whole story. I was able to generate a simple document in no time, but was soon troubleshooting issues. For example, I found that whitespace at the end of text snippets was getting truncated, so that words ran together, until I figured out that a text element needs the space="preserve" attribute, wrapped by the .NET library as SpaceProcessingModeValues.Preserve. Using styles was also tricky. I followed the supplied article on applying a style to a paragraph, but although I used a standard Word style it was ignored. Styles are no use without a StylesDefinitionPart that contains definitions for the styles you will use.
In the end, the SDK documentation is little more than the famously lengthy Open XML specification, presented as classes and members instead of plain XML. There are few useful code examples.
Open XML is also verbose, and makes you realise how concise HTML is by comparison. You can embolden a word in HTML with a simple <b> element, but in Open XML you have to add a RunProperties element to the Run element that has your text, and then add the Bold element to RunProperties. Microsoft mitigates this verbosity by using very short element names; it is also one of the reasons for using ZIP compression on the final bundle.
It does get better, once you have done your homework on the OPC and Open XML, and created your own wrapper code for the .NET API. There is also a fantastic Productivity Tool included with the SDK, with which you can open and inspect Open XML documents. Its best feature is called Reflect Code, and generates the C# which creates the document you have opened. This means you can get a working example for any document, which can also be used as a starting point for your own document generation. For example, you can set up a document with some dummy text using the styles you need, generate the code, and then amend it to replace the dummy text with your own dynamic content. The only snag is that an innocent-looking and nearly blank Word document includes a large amount of metadata, themes and other stuff, so the generated code is over 2,000 lines long.
Microsoft could do a better job with the SDK documentation, but this is still a powerful tool for parsing and generating documents, and delivers a means of processing Microsoft Office files on the server without Office or SharePoint installed. If you want to know more, the official resource site is here. Finally, a commercial alternative with a more developer-friendly API for both binary and Open XML Office documents is Syncfusion's Essential DocIO; I've not used it but have heard good reports.
Microsoft has made a release candidate for Visual Studio 2010 available for download, and the rumour is that the final build should be ready in time for the official launch on April 12th. Should you care?
I'd argue that Microsoft's platform is in decline, despite good financial results recently on the back of the success of Windows 7. Windows-only development is increasingly unattractive in a world where Macs, iPhones and Linux devices such as Android and some netbooks jostle for attention alongside the once all-conquering Windows PC. Microsoft does internet too, of course, and even cross-platform for the desktop if you count what is coming in Silverlight 4.0; but even after the launch of Windows Azure this month, the company is not the first to come to mind when you think cloud.
That said, Visual Studio 2010 is a mighty impressive release. It is not just a new IDE, but also includes .NET Framework 4.0, the first complete update since version 2.0 in 2005. Versions 3.0 and 3.5 used the same underlying runtime as 2.0. The Chief Architect is Rico Mariani, Microsoft's .NET performance expert, which has no doubt helped in the tricky transition to Windows Presentation Foundation for the Visual Studio editor and shell; and much of the product is under the oversight of VP Scott Guthrie, one person who still knows how to communicate with developers, and whose presentation on Silverlight 4.0 rescued last year's Professional Developer's Conference from tedium.
Leaving aside the people involved, there is a ton of interesting stuff to explore, including the new F# language, IntelliTrace debugging that lets you step backwards through code, standard UML diagramming, source code management and issue tracking through Team Foundation no matter how small your team, greatly improved libraries and tools for concurrent programming, and if you have the Ultimate edition and the patience to set it up, an extraordinary thing called Lab Management which integrates virtual machines into the automated build and test cycle so that you can verify clean installs into complex multi-machine environments on every build, and use snapshots to analyse bugs at the moment they occur. This is also the first release to be designed with ASP.NET MVC in mind, and to have a full visual designer for Silverlight. Microsoft has also done some good work with Windows Workflow Foundation, in conjunction with a new runtime for the IIS web server called Windows AppFabric, making it easier to build and deploy applications that depend on long-running state management.
There are some disappointments. One is that Visual Studio is out of synch with Silverlight 4.0, so despite developer attention having largely shifted to the 4.0 release, Visual Studio 2010 will ship with Silverlight 3.0 support. There will be an add-on in due course that will put that right. Another is that Windows Azure development is not as smoothly integrated as I had hoped. SharePoint development, while much improved, remains an arduous process that tends to take over your development machine; and there is not much new in mobile development as yet. I am sure there will be plenty of other problems and frustrations; so much here is new that it is nearly inevitable.
These issue have not stopped me from enjoying my work so far with the beta and now the RC. If you have any interest in Microsoft's platform, I suggest you take a look.
So you need a new Windows application. You fire up Visual Studio, but which project type do you select? Windows Forms application, or WPF application?
Windows Presentation Foundation was introduced at the same time as Windows Vista, with final code released in November 2006 as part of .NET Framework 3.0. It was designed to replace existing Windows graphics APIs such as GDI and GDI+ with a more powerful, flexible and scaleable framework for buiding a graphical user interface, taking advantage of DirectX hardware acceleration and rich graphical effects. If Vista had proceeeded as originally planned, it would probably have been deeply baked into Windows itself, but in the end took a lesser role, presumably for performance reasons. Microsoft also added Windows XP support to make WPF more attractive to developers.
Another goal was to improve designer/developer workflow. WPF uses XAML, a declarative XML language, and is amenable to manipulation through a visual design tool. Microsoft released Expression Blend and Expression Design, which export XAML, as well as supporting WPF in Visual Studio.
Developing a Windows GUI can be frustrating. If you have ever wrestled with dialog units or the impact of "small" vs "large" fonts, you will know how badly scaling is handled. WPF is a huge improvement, with sensible layout management as well as great support for multimedia and effects.
Nevertheless, WPF was slow to take off. Issues included the large memory footprint of a WPF application, deployment of the latest .NET runtime, and lack of pre-built components; in fact, for a long time Microsoft itself advised against using WPF for line of business applications.
There was another factor too. Long-term Microsoft platform users have learned to be cautious about any technology that is not much used within Microsoft itself. WPF was a great example, with little obvious use beyond the Expression tools themselves. In this context, it was fascinating the hear the talk from Principal Software Engineer Paul Harrington at PDC in November, about how Visual Studio 2010 has been rebuilt with WPF. Harrington's team has an advantage over most of us, in that they can press the WPF team to fix bugs and make changes, and that is exactly what happened. Visual Studio needed to use invisible windows for some operations; WPF did not support that, but now now in version 4.0 it does. The text rendering in the new editor was making some developers feel physically ill, apparently, because of its blurry appearance on some systems, so a new text stack was built, enabled by turning off ClearType. The Visual Studio team ran into problems with focus and activation, and new modes have now been added to WPF to fix them.
My guess is that the stress-testing of the Visual Studio team combined with other improvements in WPF, such as new business-oriented components, will make it the sensible choice for a Windows GUI application, other things being equal (which they never are), once Visual Studio 2010 is released.
The big caveat is that developing new applications using a Windows-only API does not look like a smart choice in many scenarios, though it could still make sense within some organisations, or if your application is strongly hooked into Windows anyway. WPF has good support for new Windows 7 features, for example. But Microsoft is also releasing Silverlight 4.0, which has considerable compatibility with WPF but runs on the Mac as well as on Windows, is easier to deploy, and which fits with the web model for data handling. Silverlight 4.0 now has COM support on Windows, when run out of the browser, which means you can add native code if you really need to, and integrate with other applications such as Microsoft Office.
In some curious way then, WPF is maturing to become an excellent development framework at just the wrong moment. Nevertheless, I'd now think twice before hitting the Windows Forms option on a new application.
I'm just back from Microsoft's Professional Developers Conference in Los Angeles, where the star of the show was the latest update to the Silverlight browser plug-in that lets you run .NET applications cross-platform and within the browser. The pace of development is remarkable. It is only 9 months ago that we were first shown the beta of Silverlight 3, at the Mix conference in March. Silverlight 3 was fully released in July; and now we have version 4.0 beta, with release promised for the first half of 2010.
It is a big release too. Many of the top Silverlight feature requests are being implemented, including printing, right-click and mouse wheel support, a rich text control with editing, clipboard support (though text-only in the beta), drag-and-drop, interaction with Webcams and microphones, multitouch control, improved just-in-time compilation for faster performance, and improved databinding for business applications.
In addition, the forthcoming Visual Studio 2010 is the first to have the kind of Silverlight development tools you would expect, with a true visual design surface and drag-and-drop data binding. On the server, WCF (Windows Communication Foundation) RIA Services simplify the effort of authentication, talking to data, and integrating with ASP.NET.
Another notable feature is the ability to run a Silverlight application out of the browser, started from a desktop shortcut and displayed in a custom window. New in version 4.0 is an HTML control, which embeds IE on Windows and WebKit (used in Safari) on the Mac. These are desktop/web application hybrids. Silverlight 4 blurs the boundaries, by adding a new trusted mode. Subject to the user passing a security dialog, a trusted out-of-browser application gets local file access to user data, cross-domain network access, and on Windows native code interop through COM automation.
The snag with this last point is that any Silverlight application which uses COM automation will only run on Windows, breaking the cross-platform compatibility which is a key reason to use Silverlight in the first place. Although Microsoft says the feature has been put in simply to meet the requirements of a few Enterprise customers, it seems to me that it goes well beyond that, making Silverlight viable in many scenarios that previously would have required a native solution.
Microsoft's ideal scenario is one where applications run everywhere, but run best on Windows, preserving its desktop lock-in. The company calls this "lighting up the platform"; but Windows is somehow the only platform that gets lit up.
I still think it is time to learn Silverlight. The reason is not only Microsoft's signposting of this as its key technology for future client development, but something else I saw last week: Google's Chrome OS. I'll be writing more about this; but I was impressed by how this forthcoming browser-based operating system promises to solve long-standing problems: cheap, lightweight computers that are secure, that start up instantly, that give us access to all our data, but can be left in the back of a taxi without compromising our secrets.
What if Chrome OS catches on? Does Microsoft become irrelevant? The real world does not move that fast; but considering the continuing popularity of the Mac along with the prospect of Chrome OS, it strikes me as brave to presume a Windows-only client for future development. Silverlight on the other hand should run in Chrome OS, either using Mono's Moonlight, or the Intel port being done for Moblin, or perhaps Microsoft itself will have to dirty its hands with Linux. Google might block Silverlight - it was non-committal on the subject at the Chrome OS press briefing - but I'm guessing that concerns over appearing excessively controlling will trump the desire to shut out a competitor.
The point here is not that Silverlight is the answer for all client development; there are plenty of other strong choices. The point rather is that for Microsoft platform developers Silverlight is the technology that makes it possible to take your C# or VB.Net skills and transition them to a new cross-platform, web-oriented world.
It is one of the dirty secrets of software development: the number of memory leaks that find their way into production code. Memory leaks are a special category of bug because they can easily go unnoticed. The user's perspective is that they start work using your application and everything is fine. If it is an application that is used lightly, maybe run once every morning to create a report, than everything is fine for ever. If it is a long-running application then eventually it will cause problems, though the user may not know which bit of software is to blame. Since Windows rarely runs out of memory, the user might just notice everything slowing down. It is one of the reasons why restarting Windows from time to time tends to be beneficial.
The huge amounts of RAM in today's machines disguise memory leaks. An application can leak a little bit of memory with every operation, and still run fine for ages. That's not good though; and the migration to web applications makes the problem worse. Web applications tend to be exercised heavily for long periods, which means memory leaks are more likely to have severe consequences.
Although garbage collection in the .NET Framework is meant to relieve developers of the burden of memory management, the reality is a little different. In some respects managed code is more prone to memory leaks than unmanaged code. The problem is that the garbage collector will only free objects for which no valid references exist, and it is easy to maintain such references inadvertently.
So how do you find these guys? You observe memory usage externally with a utility like Sysinternals Process Explorer, or write your own tests with code such as calls to GC.GetTotalMemory, or use a dedicated tool. There are performance tools built into some versions of Visual Studio, which can be configured to do .NET memory profiling, though making sense of the reports takes some effort. If you want to try this in Visual Studio 2008, open the Performance Explorer, right-click a Performance session, and check the boxes for .NET memory profiling collection. This can be useful, though I'm going to suggest a third-party tool which is modestly priced and more productive: Scitech .NET Memory Profiler. Others worth investigating include Micro Focus DevPartner Studio (which does far more than just memory profiling) and Rational Purify Plus.
Here is a quick example. Let's say I'm writing a VB.NET Windows Forms application. I have a main Form1, and a second Form2 which I create and display as needed. I want to have the second form respond to events on the main form, so in Form2 I declare a reference to Form1, which I set when Form2 is displayed:
Private WithEvents mainForm As Form1
Using the Visual Studio editor I hook up an event handler for mainForm.
Everything works fine, until a user complains that the more she uses the app, the more her machine slows down. What's the problem? Well, if you run the Performance Explorer with memory profiling enabled, you might notice something odd. Run the app, and display and close Form2 three times over. The report tells us (among many less useful things) that there were three instances of Form2 created, and that all three were alive at the end. We've found a memory leak.
What's the problem? You can guess that it is something to do with the reference to Form1. The Scitech memory profiler easily identifies the exact problem. In order to find it, run the application in a Memory Profiler session, then immediately choose Collect Heap Snapshot. Open and close the three instances of Form2, then again Collect Heap Snapshot. Finally, filter the view to show new or removed instances only. You can see that the number of instances of Form2 is now 3, where it should be 0. Double-click this line in the report to see a list of instances, and double-click the first to see the references to it that are preventing it from being garbage-collected. Although there are several of these, only one really matters, which you can find by checking the option Only show instances included in root paths. The culprit is an instance of System.EventHandler.
You can actually fix this memory leak without changing the way the app works. Remove the handles clause from the event handler for the mainForm reference, and replace it with a manual event hook-up in the Form2 constructor:
AddHandler mainform.Click, AddressOf mainform_Click
Then, override Dispose and manually remove the event handler:
RemoveHandler mainform.Click, AddressOf mainform_Click
Try the application again under a profiler, and you'll see that the problem has disappeared, and no instances of Form2 remain in memory after it is closed.
No doubt there are other, better ways to code this application; but it illustrates the troubleshooting process.
The reason this kind of leak is so troublesome is the chain effect. If a form remains in memory, so too do all the objects referenced by that form, and so on. Unfortunately there are occasionally bugs in the Framework itself that make this hard to avoid - see for example this post by the author of Memory Profiler, Andreas Suurkuusk, where he tracks down a problem with the toolstrip control.
I'd argue that .NET applications of a significant size are more likely than not to have some memory leak issues, and that a tool like Memory Profiler is near-essential for troubleshooting them.
Microsoft has completed Windows 7 and released it for manufacturing with much fanfare. It is a key step in terms of Microsoft's battle with Apple for hearts, minds, and above all sales; but does it matter to the average corporate developer?
There are a couple of ways of looking at the question. Windows 7 has new features, and although it is unlikely that you would want to require Windows 7 for your application at this early stage, you might want the kudos of adding a few enhancements that appear when running on the new operating system.
The other angle is simply this: if some early adopter insists on running your app on Windows 7, against corporate policy, will it still work?
Windows 7 is an unequivocal improvement on Vista and makes XP look distinctly dated and insecure, so it's likely that adoption will be relatively rapid, especially in the consumer market.
The official line is that application compatibility should be good, and my experience bears that out. In particular, if an application runs OK on Vista it will almost certainly be fine on Windows 7 as well. An XP application is more likely to break on Vista, than a Vista application on Windows 7. User Account Control (UAC) is the biggest source of compatibility issues, particularly for applications that assumed the user to be running with local administrator rights. Test your applications, of course; but unless you are writing tricksy things like anti-virus utilities they will most likely work as well on Windows 7 as they did on Vista.
What about enhancements? Some Windows 7 features are worth supporting, because they improve usability. The most obvious example is the taskbar, the heart of the Windows 7 user interface. Taskbar jump lists, which are right-click menus for taskbar icons, can be customised to support tasks specific to your application; and taskbar preview windows can include controls enabling a miniature user interface for the most common actions. This means users can do some of what they need without opening the main application window at all, which can be a great time-saver.
So how hard is it to add Windows 7 features to your application? An interesting question. Despite the popularity of .NET Languages like C# and Visual Basic for business applications, Windows is mainly written in C++, and when it comes to supporting new features that shows. If you are a C++ developer, you can download the latest SDK and get going immediately.
.NET developers have a more difficult set of choices. You can wait for Windows 7 features to be added to the .NET Framework (it could be a while), or roll your own interop code, or use one of Microsoft's .NET libraries, which are as yet incomplete. The last route is the most tempting, though Microsoft has gone out of its way to confuse matters by producing both sample libraries targetting specific areas, like the Windows 7 Taskbar and Libraries .NET Interop Sample Library, as well as an all-embracing Windows API Code Pack which is I think the preferred solution but which is in some respects even less complete.
Still, it should not be too hard to add some Windows 7 bling to your app using one of the .NET offerings. Then again, hasn't the boss started using a Mac at home? Is it better to invest your time in polishing the experience on Windows, or looking into how you might port to web-based and/or cross-platform applications? Like everything else, it depends; but if you work in .NET it is well worth keeping an eye on Silverlight as well as the latest developments with Windows 7.
This official blog post is an overview of the main API changes in Windows 7.
The Windows SDK blog has detailed info and gotchas for bleeding-edge Windows developers.
Question: which is best for cross-platform, managed code using a runtime such as Java, .NET, or Flash, or is it native code? When Java arrived in 1996, Sun promoted write-once-run-everywhere as one of its key benefits. The arrival of just-in-time compilers for all the runtimes mentioned above removes many performance concerns. So is managed code the best solution?
My assumptions about this were challenged when I spoke to Embarcadero's CEO Wayne Williams last week. His company is the one that now owns Delphi and C++ Builder, the RAD software development tools, after acquiring Borland's Codegear division last year. Williams told me that taking Delphi and C++ Builder cross-platform is now the top priority for the team working on those products. Concerning native code, he said: "It's crystal clear. If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town." That means at least x86 code for Windows, Mac and Linux, and he added, "there's no reason mobile devices shouldn't be on that roadmap as well."
What's wrong with Java then? "There's always been two approaches to target multiple platforms. One is interpreted, where you shield the code the developer is writing from those differences. The Virtual Machine is responsible for that, and if you want to add another platform, it's all centralised. It's easier, but the result is poor, it's a least common denominator approach.
"It's a bigger investment and it's more difficult to cross-compile, where you natively target these platforms, but the end result is much better. You're running true native code with full access to whatever hardware there is on that platform."
It was like going back in time: I recall similar arguments about Java back in the nineties. Since then, we've had not only JIT compilers but also huge increases in hardware performance. Is Williams living in the past?
Before dismissing what he says, it's worth noting that native code has never gone away. I use cross-platform native code applications all the time, from the SQLite database engine to the Audacity sound editor, and I enjoy their small size and fast performance. Over at Google, the Chrome team is hard at work delivering a new web browser, and it is mostly written in C++. Most of Windows is written in C++, despite Microsoft's commitment to .NET; and Java is an afterthought in Apple's OS X.
Although hardware performance has improved, the increasing numbers of mobile devices with constrained resources is a counter-balance to the idea that hardware takes care of inefficient code; and although managed code is fine for many business applications, it's hard to quibble with Williams' contention above that "If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town."
There is another argument for managed code, which is that applications are quicker to write and safer to run when they are under the control of a runtime virtual machine. That is generally true as well. Still, Delphi does a great job of hiding the complexity of native code development. It may be just a little anachronistic, but if Embarcadero successfully deliver a cross-platform Delphi compiler, I think there will be plenty of take-up.
Williams says we may see cross-platform Delphi as soon as next year.
Recently I have been working with Microsoft Silverlight, looking at how to put together a simple database application. I am no designer; my interest in Silverlight is to do with cross-platform deployment, a consistent runtime, and an alternative to HTML and Javascript. It seems I am not alone in this respect; the Silverlight forums are dominated by programming rather than design queries. Here are the message counts at the time of writing:
The Silverlight 3 wish list is also illuminating. You soon get a feel for what developers are most frustrated about, such as: no printing support, no easy way to save documents to the user's hard drive, ugly fonts, no clipboard support, no access to devices like web cams and microphones, and no support for WSHttpBinding which adds transactions and reliable messaging to web services.
Only a few of these things are fixed in the Silverlight 3.0 beta. There is a file save dialog, and text rendering is improved though Microsoft is a long way behind Adobe Flash in this respect.
That said, Silverlight 3 does offer substantial improvements for business applications. For example, in Silverlight 2.0 you have to handle client-side validation manually, whereas Silverlight 3.0 adds validation support similar to what is in ASP.NET. There is also a new server-side piece called .NET RIA Services, which wraps key areas like authentication and transactions. Although Silverlight cannot do real transactions, .NET RIA Services introduces changesets, which let you bundle a set of database updates into a single web service call. You can also include arbitrary custom operations, such as approving a purchase order. On the server side, where you do have transaction support, this is processed and can succeed or fail as an entire unit.
Despite the snags, there is a lot to like in Silverlight. As a GUI framework it works really well, and it is good to know that special effects and transitions are available are available if you need them. Microsoft appears to have executed well on the challenge of creating a smaller, cross-platform build of the .NET Framework, which is really Silverlight's key advantage.
Another plus is the ability to work in Visual Studio with the server and client projects side by side, integrated for debugging. You can set a breakpoint in the Silverlight client, and another in the ASP.NET web service implementation, and it just works.
Presuming that Microsoft's continues its rapid pace of Silverlight development, my guess it that it will evolve into an excellent client for .NET applications, since this is what the community is demanding. As yet though, Silverlight has made little impact on the wider world of web design, which remains dominated by Flash, and it is hard to see that changing.
Too strong? Maybe, but the ASP.NET Web Forms programming model has run its course. It was hugely impressive when it originally appeared - I remember it being announced as ASP+ in 2000, and how phenomenal it seemed. You can build a web page visually, using a rich set of controls, and have ASP.NET abstract away much of the problem of managing state. It also lets you write code in any .NET language, which is just-in-time compiled at runtime for fast performance.
ASP.NET works the same as ever today; but the web has moved on. The Web Forms model makes programming the web more like programming Windows, which was cool at the time but not any longer.
Fortunately for Microsoft, it has an alternative, called ASP.NET MVC. The first full release was announced at the Mix09 conference last week, and you can download it now. I took the opportunity to ask some of the delegates what they thought of it.
The reactions I got fell into two broad categories. The first group found it difficult to puzzle out what it really was, even those who had attended sessions on the subject. The second group loved it, and never ever wanted to go near Web Forms again. In fact, such was the frustration with Web Forms among some developers, that they had developed their own alternative frameworks but were now moving to the official one.
So what's wrong with Web Forms? Complaints I heard include that it is not testable; that it is not really compatible with AJAX; that it is inflexible; that ViewState, hidden form data which preserves state across page refreshes, is a nuisance; and that it is hard to write REST-style applications or those which properly support the Back button.
Enter ASP.NET MVC, which answers all of these complaints. MVC stands for Model View Controller, though having played with it a little I find the name somewhat misleading, as well as being a mouthful (contrast the delightfully-named MonoRail, which is an interesting alternative). Why misleading? Well, it doesn't have much of a Model, as this post observes. It does have views and controllers; but I think one of the reasons developers find it hard to grok is that starting with a discussion about MVC architecture is not the best way to teach it.
I think the place to start is with URLs and routing. It also helps to know that ASP.NET MVC follows the principle of convention over configuration (though not to the same extent as Ruby on Rails). In a nutshell, ASP.NET MVC breaks the link between the URL in the browser and aspx files on the web server; instead, it processes the URL and returns what you want it to return.
A "View" in ASP.NET MVC is an .aspx page, but in the form of a lightweight template, not a Web Forms with a complex page lifecycle.
I've been playing with ASP.NET MVC recently, and it is a delight. Yes, there is more manual coding than with Web Forms, but it is worth it for the additional control you gain. Even the performance seems better, a consequence of the lightweight approach. As it happens, I'm also a believer in test-driven development. I guess I'm in the second group that I spoke to at Mix09.
Microsoft is not killing off Web Forms; rather, it is very insistent that they remain under full development. I get the impression that the company expects ASP.NET MVC to be a minority choice.
Nevertheless, if you work with ASP.NET do not hesitate to check out the new framework. Personally I think ASP.NET MVC might just rescue its web platform from a slow but inevitable decline.
Historically, the web development choice between the Microsoft platform and open source has been a fork in the road with many consequences. Choose Microsoft, and you generally use Visual Studio, Internet Information Server, ASP.NET, C# or Visual Basic, and SQL Server for the database manager. Choose open source, and you most likely target LAMP in one of its guises, the most common being Linux, Apache, MySQL and PHP, and work in Eclipse or almost anything other than Visual Studio.
Recently the boundaries have been blurring a little. Apache actually runs nicely on Windows, and I've used it happily to host a Subversion repository, while on the other side Microsoft has been making an effort to support PHP in IIS 7.0. But what about running ASP.NET on Linux, is that a silly idea?
I've been following the efforts of the Mono project in this area for some time, though it's been a while since I've tried it out. Mono was originally focused more on desktop than web applications, and I've used it mostly in that context. When laterooms.com tried Mono in early 2006 it quickly gave up, citing problems with Mono's Boehm garbage collector; see the developer's comments to my blog post at the time.
Still, that was three years ago. I had another look a couple of weeks ago, and I've been impressed. In particular, the ability to develop in Visual Studio and deploy to Linux is interesting. I'm working on a small project, and getting this working is remarkably simple. I used Visual Studio 2008, but set the project to target .NET Framework 2.0, as Mono lags behind Microsoft in implementing the latest .NET APIs, and using MySQL rather than SQL Server, since this is available on my Linux web server. Using MySQL with .NET is straightforward thanks to the official ADO.Net provider, which specifically supports Mono as well as Microsoft .NET.
On the web server, running Debian 5.0 Linux (Lenny), I installed the libapache2-mod-mono and mono-apache-server2 packages using Aptitude. Next, I configured Apache to use Mono on a particular web site, with a few lines of manual configuration, as explained here, and imported the MySQL database from the Windows development machine to the Linux web server.
Back in Visual Studio, I compiled the web site, uploaded it, and it worked first try. Performance is good as well.
I realise that a number of caveats apply. It's worth reading this page, the current Mono todo list, which notes some of the important areas where Mono is lacking and includes the comment:
Mono is known to be not as performant as the .NET Framework.
Note that Mono still uses the Boehm garbage collector, though an alternative is in development. Further, Mono does not implement the entire .NET Framework. Mono is a brave choice; Windows and IIS the sensible option for .NET applications.
It still seems to me significant that you can easily deploy to Linux and Apache using Mono. Not all applications are mission-critical, and not all applications need to scale as well as Laterooms.com. Mono has a number of attractions. First, it is open source, so in the event of problems you can always obtain and amend the source code. Second, running on Apache and Linux is a considerable saving in license costs. Third, you can get official developer support from Novell.
Why would you use C# and ASP.NET rather than PHP or Java? The main reason would be because you know and like the language, the platform, and/or the Visual Studio IDE. In an interesting report on the state of the computer book market, O'Reilly notes that C# is now the largest programming language for all book sales. Thanks to Mono, you can use C# but still deploy to an open source platform.
It also seems to me that Microsoft's official support for Moonlight, the Mono implementation of Silverlight, is important. Microsoft now needs Mono, in order to tick the cross-platform box and compete with Flash, giving more assurance to its long-term future.
Mono's growth over nearly a decade has been slow but steady. Perhaps now is the moment that it creeps into the mainstream.
Are you using Mono, for web or desktop development? I'd be interested in your comments.
Concurrent programming was a major theme at Microsoft's recent Professional Developers Conference. We all know the reasoning: processors are no longer getting faster, but multiple processors are now commonplace. Even my desktop PC is a quad-core. However, having multiple processors is no guarantee that applications will run faster. For that to happen, the application has to be coded with concurrency in mind. Therefore, if we want to write fast applications, we have to learn concurrent programming.
Unfortunately concurrent programming is hard. Think deadlocks, synchronisation, non-determinant, race conditions, and so on. Fortunately, Microsoft is good at making hard things easy. The original Visual Basic transformed the coding of a graphical user interface from something intricate done in C or C++, to something anyone could do with a few clicks of the mouse.
Now Microsoft aims to do something similar for concurrency. The .NET Framework 4.0 incorporates the Parallel FX Library, which does a great job of simplifying multi-threaded development. The new Task Parallel Library is smart about how many processors it finds at runtime, and spins the right number of threads to take advantage of them. PLINQ lets you easily apply parallelism to LINQ queries. Daniel Moth does a great job of demonstrating the benefits in his session at PDC, which you can watch online; and if you work with .NET I highly recommend it.
The worrying aspect is that while Microsoft is making concurrency easy, it is not making it safe. When I was playing around with Visual Studio 2010 and .NET Framework 4.0, one of the first things I did was to look at my code for counting primes and to see how I could optimize it. I found I could do so easily by changing a For loop to use Parallel.For instead, one of the features of the new library. I got a nice speed boost on a two-core machine, not quite double, but nearly so. One snag: the result changed every time I ran it.
I soon figured out what was wrong. My code declares a numprimes variable, then increments it within the loop. Everything is fine when single-threaded, but if you have two threads running the loop in parallel, they might both increment the variable at nearly the same time. That means reading the value, incrementing it, and writing it back. Occasionally this happens:
Result: the value is one less than it should be. The fix is to lock the value first, or to find a better approach; this exact problem is discussed here (scroll down to Aggregation).
Bugs are nothing new in programming, but concurrency bugs are particularly tiresome. The code may work fine on some machines; in my example, the bug would not occur on a single-core PC. If your loop is a little less tight than a prime number calculator, it might be that the odds of the bug occurring at all are rather small. It could even pass all your unit tests. Deploy the application though, and you can bet that wrong results will soon crop up with the usual potential for calamity.
Haven't we already had, and survived, this problem with previous abstractions like BackgroundWorker, a class in .NET Framework 2.0 that makes it easy to push some code into a background thread? True to some extent, but BackgroundWorker is less dangerous because it is typically used more for keeping an application responsive, than to increase performance with parallel threads on a multi-core system.
The bottom line is that while I am full of admiration for the work Microsoft has done with the Parallel FX, I have a nagging worry that as more and less skilled programmers are encouraged to do this, we may be introducing a new wave of buggy code, as argued in detail by Edward Lee in his paper The Problem with Threads [PDF]. The hardware trend is real though, so I suspect greater concurrency in everyday business applications is coming whether we like it or not.
The other conclusion is that before using something even as apparently simple as Parallel.For, developers have a responsibility to learn about the pitfalls as well as the benefits.
