Introduction and Background
C# programming language has evolved a lot over the years and many frameworks and platforms have been created and developed that support C# language as their primary programming language. Indeed, C# was release with the .
NET framework but has grown out to support Windows Runtime applications, ASP.NET applications, many .NET framework platforms such as WPF, WinForms, etc. I have programmed for all of these frameworks, taught beginners in these frameworks, and also written a lot of articles for these frameworks. However, the framework that appealed to my interests the most was Windows Runtime. Windows Runtime is the new kid on the block with an object-oriented design and performance factor much similar to that of C++ applications.
At a higher level, it seems like a very simple, easy, and straightforward application development framework. At its core, it has a large number of validations and checkpoints. I remember the days when I was developing applications for the .NET framework. WPF, WinForms, ASP.NET, and other similar ones. I did have a few problems learning and starting, but there was one thing: The underlying framework was a very patient one. They never showed hatred for beginners or newbies. But when I started to write applications for Windows Runtime, I found out that it had no patience in it, at all. It was like, do this or it’s not gonna work.
Figure 1: Windows kernel services and how it branches into different frameworks
In this post, I am going to collectively talk about a few things that Windows Runtime may teach C# programmers, for a better overview of the applications that they are going to develop.
1. As a framework
Windows Runtime came into existence way after the .NET framework itself and the child frameworks of the .NET framework. But one thing that I find in Windows Runtime is that it is very much based on asynchronous patterns for programming. Microsoft never wanted to provide a good UI and UX but to leave out the performance factors.
One of the things that I find in Windows Runtime is that it still uses the same philosophy of C# programming language. But, it adds the asynchronous pattern, too much. Not too much in a bad way, but in a positive way. The benefit is that you get to perform many things at the same time and let the framework handle stuff. So a few of the things that it teaches are, that you should always consider having tasks when there is a chance of latency.
- Network
- File I/O
- Long-running tasks
These are the bottlenecks in the performance. Windows Runtime allows you to overcome these. .NET framework also uses the same mechanism, but developers typically leave out that part and go for the non-async functions. Bad practice!
References
For more on asynchronous programming, please refer to:
- Diving deep with WinRT and await
- Asynchronous Programming with Async and Await
2. Modularity
C++ programmers have been using modular programming, developing small snippets of codes, and then using them here and there. Basically, modularity provides you with an efficient way of reusing the code in many areas of the application. Windows Runtime has a great modularity philosophy.
The foundation has been laid down on categories, and under those categories, there are namespaces that contain the objects that communicate and bring an outstanding experience for the developers.
C# is object-oriented programming, which means that even if you’re forcing yourself to have a single source file you are still going to have multiple objects, working collectively for each of the purposes of that application.
Yet, it is recommended that you keep things where they belong.
Figure 2: Modules can contain the functionality in them, through which user can communicate with the underlying objects and data sources
References
- Windows API reference for Windows Runtime apps
- Modularity
3. Simplicity of the development
I don’t want to lie here, Windows Runtime is simple, it takes time to understand its simplicity.
When I started to write applications for the Windows Runtime framework, I did not understand the framework or how to develop the application. That is because I was fond of straightforward small programs. Windows Runtime is a beast, a humungousaur, with its handles hanging down to the developers through the interfaces of the C# language. Windows Runtime has everything already set up in different areas. Like, the views, source code, capabilities, properties, resources, and much more.
Visual Studio brings a way simpler means of development. I mean, Visual Studio handled everything,
- Managing the source code.
- Managing the output directories and how binaries are generated.
- Managing the visual items; the image assets may be difficult to add, Visual Studio makes it really very easy to add the assets of different sizes.
- The properties and manifest of the application are also written in XML. But Visual Studio makes really very simple to edit and update the manifest of the application.
While building applications for other platforms and frameworks, like WPF, we can use the same philosophy of Windows Runtime to build a great project and package directory. The settings and configuration files can be kept separate to make it simpler to build the development process.
4. Keep all architectures in mind
.NET framework developers don’t have to worry about the architecture that they are going to target. That made them forget the way that applications would be targeted on multiple devices and environments. Windows Runtime is not like that. Windows Runtime generates multiple binaries for multiple environments, multiple architectures, and devices.
- x86
- x64
- ARM
These are a few of the configurations for which binaries are generated and since the code that gets generated in a native one, the code must match the architecture, otherwise, the results are undefined.
However implementing the multiple architecture pattern would also require more manpower, more time for testing and implementing the patterns. Windows Runtime in Visual Studio has all of that already supported, but the thing is, you need your men ready for any new framework to be included and tested on.
5. You may want to test it again!
Before Windows Runtime, I thought, if everything works correctly it is going to work anyways. But, ever since I have started to write applications for Windows Runtime and Windows Store I forgot that mindset and wanted to ensure that it passed all of the tests that it must undergo. That all started when I was about to upload my application, “Note It! App” to Windows Store. The application was passing all of the tests in Debug mode. Yet, when it was tested in the Release mode, it failed many of the tests.
Note: I am not talking about the Windows App Certification Tests.
The thing is, the code in the Debug mode has a debugger attached, which knows when something is going wrong and tells the developers about it and we can fix it. In Release mode, it is not the same. The error checks, the memory segmentation, and other stuff in Windows Runtime are not same as it is in .NET framework. .NET framework uses Just-in-time compilation and performs many checks. However, in Windows Runtime, that is not the case. Everything is pre-compiled to overcome the JIT latency; delay.
That is exactly why you should build the application in debug mode. However, always test the applications in Release mode. If you test the application in debug mode, you will skip a few of the key points in your application where it needs to be checked against.
Also, in the end, the App Cert Kit will be useful to test if other tests, like resources, binaries and signature packaging is all well.
Figure 3: App Certification Kit
References
For more about it, read these:
- Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks
- Debugging Release Mode Problems
Points of Interest
No developer wants to publish their buggy and faulty application on the Internet. I try not to publish the application until it has passed every possible condition of the test. However, no software is 100% bug-free and a perfect solution.
In this post, I didn’t mean to target Windows Runtime as an ideal case for solution building, instead, I wanted to just share a few of the great cards it has up its sleeves. .NET framework is simple, easy, and agile to build on. But agility may drive you insane someday.
Always keep these things in mind, and write applications by keeping these things in mind.
Read more articles on .NET Core: