0 comments
.NET 
Today we started our second day at build with a keynote session that was very developer oriented. We got a great set of demo’s from top Microsoft Executives that code on stage.(Jason Zander, Scott Guthrie, etc.) How cool is that!
Follow my new blog on http://fluentbytes.com
Today we we tried to get a better grasp on what the different parts we saw yesterday really mean for us as developers. How can we translate this into a good advice for our customers who have heavy investments in .NET and desktop enterprise applications.
So to start of, I take it back to the picture we saw earlier yesterday on how the current windows desktop applications live side by side with the new Metro Style applications. Current applications written for .NET, native on Win32 or using the web with HTML and JavaScript. One of the things that became crystal clear today is that they did not draw an important line between the Green and the blue part on this slide!
The big line that should be on that slide is to indicate that as of windows 8 there are 2 types of applications you build. Either Metro Style, or desktop. there is no way both sides can talk to each other or directly share anything together other then file sharing or service operations via a server on the backend. So we don’t get the option for desktop apps to share information using the newly introduced charms and there is also no way to share data from a metro style application to the desktop application using the charms.
So when we write an application for WinRT (metro style) then we get to use the WinRT to communicate to the operating system and we get a set of libraries that run in the runtime, but this is a subset of .NET as we know it today! Only the .NET framework classes that made sense for Metro Style apps are available and not the full fledged .NET framework.
So what does that mean for the average .NET developer currently working on a application that runs on the desktop? Should he port all his code to the metro style application type?
I think this really depends on what your application is trying to achieve. If you build an application used for day 2 day data entry and has no natural reason to use touch input, I would say no. Just build the app as you have done in the past. Just create a desktop application, use Silverlight as your primary runtime. (only use WPF if you really need those special features not available in Silverlight) When you do have an application that would benefit from a Touch interface, different form factors, sensors etc. then I would consider to port my application over to Metro style. Also when you are building apps for the consumer space, Metro Style will be a great way to expose your app and even use the windows store to market your application.
So next is the question, what are the differences I notice as a C# developer, between Metro Style apps and desktop apps? As a C# developer who has done some XAML in the past, all feels the same. You only include a new set of namespaces and use some other “assembly” references. Now I put Assembly in quotation, because in the WinRT environment those libraries are no real assemblies anymore. They are only files that use the same rich metatdata description as we have in .NET. You can compare those files best to Primary interop assemblies, those also only contain metadata and no IL instructions. So this metadata reflects the underlying System, and Microsoft created a very clever mapping infrastructure that enables the applications to call into the operating system using this metadata. Hence giving you a great performance, since the libraries exposed through the metadata are all native instruction set for that machine.
I hope to dive further into the details in a later post, but as for now you can just see an application you used to build in the .NET runtime, feels exactly the same as when using WinRT. You still have a garbage collector taking care of your .NET classes and you just have a set of new API’s you can call into using a standard Using Statement and by setting a reference to the metadata.
Friday there will be a session where they will go through the full steps on what happens behind the scenes when you run a Metro Style application. After I attended that session I will try to give a summary of what happens.
One thing to note is that during the conference you will see everybody talk about metro style apps. Of course that is the case, since we are at the build conference where they introduce the new Metro Style applications. But please do not take that to start thinking that desktop apps are of the past. There are plenty of applications that are not and never will be a Metro Style application, just because they are never usable with touch first, and they just need a mouse and keyboard to operate properly. So when you are an ISV that builds applications for the desktop then that is perfectly fine. You can of course look and see if you can port some code over to Metro to create an Metro Style application for portions of your system, but you do not have to do a complete overhaul of your system. The desktop is there to stay, we only got a new segment of applications that have a different feel an need of interaction. Only when that touch first, fast and fluid style is applicable to your problem space you should think of building these types of apps. Otherwise you are just fine in building your productivity apps, you always build and they will be supported. You can also see that in all the announcements this week on new stuff coming to the .NET 4.5 version of the framework and Silverlight 5.
Great thing about all of this is that we get a whole new ecosystem of apps that can be build from scratch and we can apply all skills we learned in the past building our desktop applications. With this new Eco System, we also can welcome millions of web developers that are now empowered to leverage their skillset with HTML 5 and JavaScript to build native windows applications as well. Opening up windows to this audience is a great gain for the windows platform and will probably attract a big group of developers to start and build new apps. This is also a great new influence where we .NET developers will learn from, since they have worked for years in the more creative environment as the web. So it will be fun to see what they will come up with and how we can learn from their skills as well.
I think one key thing surrounding all of this is not stated yet and that is that application UI design is starting to matter more then it has ever done before. Meaning we will also see the group of professional UI designers will grow and blossom as well from this new ecosystem. With the great tools like Blend being opened up to web developers as well, will be a great gain for all of us. I really like what I have seen thus far and sure am glad we can work on this software in these interesting times.
Cheers from the beautiful architected convention center in Anaheim California
Marcel