Starting a new line of business application on the Windows platform has never been harder. Gone are the days where there was one obvious choice for given class of problems. For most of the last two decades we’ve had good options. Visual Basic for time to delivery or MFC for raw performance and capabilities. Then it was WinForms for speed vs WPF for appearance. As WinForms left we gained Silverlight as our second choice, less powerful than WPF but easier to deploy.
But today we have more options than ever before, and they are all dismal. WinRT offers three development models, none of which are suitable for business applications, while WPF is joining Silverlight and WinForms on the bone yard.
WinRT: Not Ready Yet
I’m not going to talk about the problem with choosing a platform that requires Windows 8 because eventually businesses will adopt it. Not am I going to talk about the current problems with WinRT 8 such as being limited to a single window or no device integration. At Build 2013 Microsoft announced that these issues are being fixed in WinRT 8.1.
No, the problem I’m going to talk about is simpler than that and much, much stupider. The deployment scenario is, to put it bluntly, insane. In a clear case of Dissociative Identity Disorder, the consumer and enterprise sides of Microsoft are at war with each other. The consumer side of Microsoft wants to keep WinRT locked inside the Windows Store so that they can receive their percentage on every software sale, a successful strategy for Apple and Google. Meanwhile the enterprise side of Microsoft is toting WinRT as the future without even acknowledging the problems the other side has created.
Deploying WinRT Apps in the Enterprise
The first requirement is that all machines be part of a domain. This requirement isn’t entirely unreasonable for larger companies, but many small and even some mid-sized companies simply don’t have the resources to maintain a set of Active Directory servers. It is easy to forget that most companies are not in the technology business and just want a handful of custom applications, not an entire IT infrastructure.
Another problem is that some companies that do have an Active Directory installation still don’t necessarily have all machines join it. The reasons for this vary, and are not always justifiable, but none the less the needs of those companies should be addressed.
Supposedly there was going to be an alternate plan for non-domain machines. In April of 2012 Antoine Leblond promised to have a follow-up post describing how to get the product keys necessary to do this. That blog post was never written.
The next requirement is that the “Allow all trusted apps to install” group policy, which is reasonable enough for domain machines. For non-domain machines it requires manually editing the registry, a practice that is generally frowned upon. Still, that can be added to a script.
The final requirement is less palatable. All applications need to be signed with a certificate trusted by all of the machines. This requires either creating a self-signing certificate and manually installing it on each machine or spending hundreds of dollars on a code signing certificate from a reputable certificate authority.
Once all that is done, users can be taught how to invoke PowerShell commands to install the application. No ClickOnce installer here. Not even batch files they can click on, because PowerShell defaults to no letting scripts run from Windows Explorer.
Updating WinRT Apps
Antoine writes,
There is no standard way for the end-user to detect and acquire updates for these apps.
After nearly a decade of using ClickOnce for automatic updates, we are back the situation of manually updating workstations. Instead users have to again type in PowerShell commands. The difference being this time they need to include the version number in the path. For example,
add-appxpackage \\fileserver\ContosoApp\v1.1\ExpenseApp.appx
Silverlight: Retired
Silverlight is essentially a dead technology. Unlike Adobe Flash, it isn’t even fully supported in Internet Explorer 10. And on ARM-based computers it doesn’t run at all.
Is Silverlight Complete? No.
Some current and former Microsoft employees have argued that Silverlight is “complete” and that it doesn’t need any improvements. I find that claim to be laughable.
The Silverlight Toolkit, home of a lot of crucial user controls, hasn’t seen an update since December 2011 and many of the controls are not close to being production ready.
Even worse, Silverlight still doesn’t have a usable unit testing framework. There is a preview of one in the toolkit, but it has design flaws that cause the tests to take O(n^2) time. Our own experimentation found that even a few thousand unit tests can cause the test run to take well over an hour even though each test individually takes only a few milliseconds. One work-around is to alter the UI so that it doesn’t display tests that have passed.
WPF: Also in Maintenance Mode
I hate saying this, but it seems that WPF’s future seems dimmer than ever.
Performance Problems are Not Being Fixed
WPF can be slow, really slow. Much of this can be blamed on the developer for doing reckless things like loading thousands of screen elements in tabs that are not even visible. Or by adding excessive decoration to user controls; I saw one project with 9 borders around each textbox, and each of those had its own gradient brush.
But that said, there are still a lot of things that Microsoft can do to fine tune the WPF rendering pipeline. Things that are being applied to WinRT/XAML that they have consciously chosen to not back port to WPF or Silverlight.
A Roadmap Abandoned
The WPF Toolkit hasn’t seen a release since April of 2010. At first it seemed that it was merely put on hold so that the new kid, Silverlight, could get some attention. But since then no work has been done towards completing the WPF Ribbon Toolbar, the AutoCompleteBox or Accordion controls, or anything on the WPF Futures roadmap.
Not Allowed On Low Power Machines
The Windows RT edition was supposed to represent a class of cheap low power, high battery life machines suitable for both casual users and wide-spread deployments. They aren’t cheap yet, but the prices are coming down. But since they are not able to run “real .NET”, they aren’t an option for companies that choose to use WPF for their line of business applications.
No Hints of a Future
Microsoft likes to pretend that it is like Apple and keep secret major announcements about its future plans. This means that they could be working on major enhancements to WPF and just want to keep it a surprise. But Apple is a hardware company. When you invest in an iPod, your investment expires when the hardware wears out. And when that does start to happen, it’s exciting to see what Apple unveils for its replacement.
When you write an application in WPF or Silverlight, you are investing in a platform that you may need to use for years. That kind of uncertainty isn’t exciting, it is terrifying. And the fact that we have to go through it every couple of years makes it even more so.
What’s worse is that Microsoft rarely admits that it is abandoning a technology to themselves or other. There was no end of life announcement for WinForms. Nor was there a press release when the Silverlight teams were decommissioned and scattered onto other projects. No one noticed when typed data sets were dropped in favor of LINQ to SQL. And we only realized that the beloved LINQ to SQL was killed off when it was adopted by the ADO.NET team, which already had their own competing framework.
Viable for Today
So where does this put WPF? Well it is still the most viable line of business platform for today’s Windows users. With deep OS integration, few of Silverlight’s problems, and automatic updates through ClickOnce, there is nothing comparable to it when it comes to true rich client development. But there is also a very good chance that anything that doesn’t work today will never be fixed. And that makes it hard to justify for new application development.
ASP.NET: Websites Instead of Applications
I strongly believe that installed applications offer the best experience for the user. Though the web is getting better, it still handicaps the developer in numerous ways. Even basic things like using F1 for help or F5 to refresh the currently selected view don’t work because the web browser intercepts the keyboard shortcuts. More complex scenarios such as supporting multiple-windows is an exercise in frustration for the both the user and the developer. And printing multi-page reports, something that was possible in Visual Basic 1, isn’t even worth attempting unless you want to generate a PDF.
That said, the technology is stable and growing. It is available across all Windows machines from the lowly netbook or ancient desktop running Windows XP to the latest convertible tablet running a preview of Windows 8.1. And with sufficient effort you can even get your application to be acceptable on mobile phones from Apple, Google, and Blackberry.
While most of the Microsoft-specific advances are occurring in MVC, WebForms is still seeing progress. Many of the MVC features were back-ported to WebForms 4.5 or are simply applicable to both. And the two can be freely mixed within a web site, so that if you do choose to abandon one or the other you can do so incrementally.
And you can’t ignore the fact that HTML 5 is getting better all the time. Technologies like TypeScript are making large scale, single-page web applications a viable option for even modestly sized teams. Or the site can be broken down into a series of smaller, feature specific pages that are easier to handle than one monolithic application.
Time to delivery is still a concern with web sites, as they generally take 3 to 4 times longer to deliver the same functionality. But as browsers become more compatible with one another, that difference is shrinking.
So while it pains me to say it, companies that are looking to develop a new line of business applications should seriously consider abandoning that idea and build an internal website instead.
About the Author
Jonathan Allen has been writing news report for InfoQ since 2006 and is currently the lead editor for the .NET queue. If you are interested in writing news or educational articles for InfoQ please contact him at jonathan@infoq.com.
