Windows and Line of Business Applications: No Good Options

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.

I rolled my dice in late 2012 after a personal WinRT project became soul destroying finish. This after a different personal WPF project that was equally a riot of half-baked implementations and guidance was the last straw.

If it's too hard to implement small personal projects, I'm not putting my hand up for when the next Microsoft job rolls around!

I sticked with Windows Forms until my last Desktop App project because WPF had performance issues and was exceptical about Silverlight and WPF and I guess I was right!

For my future projects I will ditch Windows Desktop Apps Developtment (Android seems like a better bet) because WinRT seems like a flawed Architechture, it has so many things done the wrong way as the article states so I will stick to ASP .NET MVC and Azure.

The underlying architecture of WinRT is vastly superior to the Win32/COM base that WinForms and WPF are built on. But it remains to be seen how much of that will bubble up to the APIs that developers actually use.

Windows 8.1 will bring a lot of much needed improvements that I think people will be happy with. (Assuming of course they can tolerate the deployment story.)

Re: If 2013 Build Conf. is any indication, we have hope...
by
Jonathan Allen

The focus at Build was performance, something that WinJS sucks at on multi-core machines. JavaScript code has to run on a UI thread, even when using web workers. So if you want to really do something on the background you need to write your important code as a C++ module.

Microsoft has always ditched technology which didn't help their vision, which changes too frequently to get on board with. Try stepping outside the MS eco system and you'll find things are much more stable.

The latest round of changes were precipitated in response to Apple's iPad. The older technologies WPF/Silverlight are not competitive anymore. I have a Windows 8 touch laptop and the smoothness of the controls is very impressive and this is what is needed to stay competitive with Apple.

Having said that it will take a few rounds for things to settle down but this is a price we all have to pay to keep abreast of the changes. I agree with Jonathan, though, that MS should not alienate enterprise customers in its quest to become Apple.

If you do go with Silverlight, you can take advantage of the new Async/Await keywords using an add-on pack. It will greatly simplify your development experience and I see no justification for making service calls any other way.

Your comment is ridiculous. "Unprofessional developers" or "pseudo architects"? We are talking line of business applications, not rocket science.

Every large WPF project I've worked on was a disaster, and there were some really smart people working on the same projects.

The vast majority of business developers out there are average, and they need tools that don't require advanced computer science degrees in order to "get it right."

There are a gazillion Visual Basic apps out there that might not have the perfect architecture or might not be blazingly fast, but they get the job done, and they are able to be maintained by junior developers.

It takes from six months to a year to get proficient and productive with WPF. Back in the day, a seasoned developer could whip out a solid, working, and fully tested VB or C# winforms app in that same amount of time.

I'm glad WPF is on the way out, it was a mistaken technology to start with. But forcing everyone to write HTML5 apps is also a mistake.

It is ridiculous to say that this is not a problem. This is also ludicrous to say - this is simple to write enterprise level applications - considering that tons of books were written about it.

It looks strange for me to hear that the same "smart people" bump to some issues utilizing WPF from project to project (I hope that was at least not the same issue). I don't want to say that WPF is ideal. Surely in my practice we had bumped into some WPF "surprises" but they all were avoided and managed (I'm also talking about a set of mid and large size projects).

I can just confirm that WPF is not simple to start with it so the good development will not be at a low price.

The blog "Random ASCII" just published a good article on one of the performance issues caused by WPF. When you are running any WPF application, the Windows timer resolution is bumped up from 15.6 ms to 1 ms. And this happens even if you aren't doing anything that needs that resolution. This wastes both CPU cycles and battery life.

These kinds of design problems are all over WPF. Some are internal and potentially fixable, others are a result of offering too many options to the application developer. That's part of the reason why they restarted from scratch when they wrote WinRT/XAML.

I got a bad feeling since I first saw WPF. The whole model did not seemed justified, when you are making an installed application.

Can there be something more fundamental at play here? I think the problem is ownership, it seems like it is the lesser evil that a platform is owned by everybody. That if it is owned by a corporation. The reason being is that in order to make money a company has to limit access. And those "artificial" limitations eventually hurt the technology adoption. Nobody controls the browser world, microsoft tried to control it and failed. With all it's huge problems it is dependable, in that it will be there for good.

asm.js, Dart, Web Components, App models. There is a spectrum of solutions and opinions here, but it's clear that web tech is evolving aggressively to close the gap with native applications platforms: developer experience, deployment, management, etc.