Windows and Line-of-business applications: no better choice

Creating a new Line-of-business application on the Windows platform is never a problem. But, as before, there is only one clear solution to a certain type of problem--and the days are gone. In the past 20 years, we have had a better choice in the face of most problems. For example, Visual Basic's fast delivery or MFC native performance and functionality. There is also the speed of WinForms and the appearance of WPF. When the WinForms era was over, we took Silverlight as a second choice. Although it is less powerful than WPF, it is easier to deploy.

Today, though, we have a larger choice than ever before, but the alternative is passable. For example, although WINRT provides three development models, none of them are suitable for business applications. At the same time, WPF joined the Silverlight camp, while waiting for WinForms only to perish.

WinRT: Not ready to complete

Whether to choose a platform that relies on Windows 8-I'm not going to discuss it here because the end enterprise will all be using Windows 8. Nor do I intend to discuss the current problems with WINRT 8, such as being limited to a single window or having no device integration. Because at build 2013, Microsoft has announced that these issues will be fixed in WINRT 8.1.

The question I'm going to talk about is much simpler and more elementary than the front. Frankly, the deployment scenario is disconnected from reality. WINRT obviously has a personality split (dissociative Identity disorder), but in this case, Microsoft's consumers and businesses are deadlocked. The consumer wants WINRT to stay locked in the Windows store, so that after each software sale they can get a percentage of the Commission, similar to Apple's and Google's successful strategy. At the same time, Microsoft's corporate side is saddled with a winrt future, but they are not even aware of the problems the other side has created.

Deployment of WINRT applications in the enterprise

Users must meet three requirements if they want to deploy WINRT to the enterprise.

The first requirement is that all machines join a domain. This is a reasonable requirement for large companies, but there is not enough resources to maintain a set of Active Directory servers for many small companies and even midsize enterprises. Most businesses are not technical, they only need a small number of custom applications, not the entire IT infrastructure--and we always forget that.

Another problem is that some companies have deployed Active Directory, but there is no need for all machines to join Active Directory. There are many causes of such problems, which may not be entirely reasonable, but they still need to be met.

It is said that there will be an alternative to computers that are not joined to a domain. In April 2012, Antoine LeBlond promised to post a blog post describing how to do this by obtaining the necessary product key. So far, however, this article has not been written yet.

The second requirement is the Group Policy "Allow all trusted applications to be installed," which is reasonable for a domain-joined computer. For computers that are not joined to a domain, the user is required to manually edit the registry, and I generally disagree with this approach. However, this can be done by adding scripts.

The third and last requirement is not very popular: All machines must trust a certificate, and all applications need to sign it with that certificate. This means that you need to create a self-signed certificate and manually install it on each machine, or get a code signing certificate from a trusted certification authority for $ hundreds of.

Once all of these requirements are met, users can learn how to invoke the PowerShell command to install the application, but they cannot use ClickOnce installation. Users cannot even double-click a batch file installation because PowerShell disables running scripts from Windows Explorer by default.

Updates for WINRT applications

Antoine writes,

For end users, there is no standard way to detect and obtain updates for these applications.

After nearly a decade of ClickOnce Automatic Updates, we went back to the time when the workstation was manually updated. The user must now enter the PowerShell command again. And unlike before, they need to include the version number in the path. For example

Add-appxpackage \\fileserver\ContosoApp\v1.1\ExpenseApp.appx

Silverlight: Obsolete Technologies

Silverlight is essentially an obsolete technology. Unlike Adobe Flash, even internet Explorer 10 does not fully support Silverlight at this time. And, on an arm-based computer, it can't run at all.

is Silverlight perfect? No.

Some incumbent and former Microsoft employees argue that Silverlight is "perfect" and does not require any improvement. I find this kind of statement very funny.

Although the Silverlight Toolkit contains a number of key user controls, I haven't seen any related updates since December 2011, and many controls are not meeting the requirements for a product release. Even worse, there is still no available unit test framework in Silverlight. Although there is a preview version in the toolkit, it has some design flaws, and using it will cause the test to cost O (n^2) time. We've done our own experiments and found that although each unit test takes only a few milliseconds to test individually, thousands of tests together can lead to a one-hour test process. Another problem that needs to be solved is to revise the tests that have been passed by the ui--and show that it takes up too much space.