Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Windows and Line of Business Applications: No Good Options

Windows and Line of Business Applications: No Good Options

This item in japanese


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



Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • If 2013 Build Conf. is any indication, we have hope...

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Build 2012 WinJS sessions = 6

    Buidl 2013 WinJS sessions = 3

    The love affair with javascript for business apps may be over so the focus will shift to XAML and .Net again and hopefully better options in the future.

  • Great write up

    by harvey siege,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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!

  • R.I.P Windows Desktop

    by Alfredo Canas,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: R.I.P Windows Desktop

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • No Surprise Here

    by Andy Till,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Look around ...

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There are good options for Windows and LOB apps. Just maybe not with .NET. Maybe it is time to look outside the box. ;)

  • Re: R.I.P Windows Desktop

    by Andreas Kleffel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    WPF is a complicated technology. It takes months if not longer to cope with it. If you have certain use-cases WPF can't handle, well you're free to use the Windows Forms integration.

    But probably, if you sticked with WinForms you don't have that much of UI requirements or have extremely complex GDI codings.

  • Re: No Surprise Here

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In Microsoft's defense I have to say that Microsoft has to periodically reinvent itself to stay competitive (witness IE <-> Mozilla; .Net <-> Java; Silverlight <-> Flash; Bing <-> Google; Office Web Apps <-> Google Docs; Azure <-> Amazon; Xbox <-> PS3/Wii; SQL Server <-> Oracle; WP <-> iPhone/Android).

    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.


  • Great summarization of problems!

    by Florin Neamtu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've started a LOB application and the original plan was to go for Silverlight ...

  • Re: Great summarization of problems!

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Inadequate article

    by Oleksii Dukhno,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    All modern microsoft desktop OSs supports WPF and dotNET. WPF the best technology to develop really beautiful and fast desktop applications ever!

    Performance issues (in 99% cases) in applications occur only due to unprofessional developers and pseudo architects.

    The issue will be if the next version of MS OS does not support dotNET. But IMHO such situation is impossible.

  • Re: Inadequate article

    by Charles Cherry,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Inadequate article

    by Oleksii Dukhno,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Inadequate article

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Amazing stuff and what is the underlying reason

    by Arturo Hernandez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • XAML is what counts

    by Paulo Pinto,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    As long as XAML is being developed, it doesn't matter if Silverlight or WPF are being developed or not.

  • Mozilla and Google are pushing the future here

    by Kevin Moore,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    In my opinion, this is clearly the future.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p