I got a lot of positive feedback for my VTD presentation. I guess, the fact that we decided to actually build the presentation around problem scenarios had a greater positive impact. In the next few write-up, I am going to put up my views about each of the topics that I covered, with relevant reference links and code samples. Hopefully that will help in seeing the virtues, learning and adopting the new framework!

Stay tuned!

Hello! The VTD this time was exciting and it was fun to do a session on .NET 4.0. I hope most of you benefitted from my session, if not all. Once again, the objective was to put forth some of the interesting issues and problems that we face today in general. Perhaps because the problem initially was not realized or probably because of the framework limitations earlier. Frameworks are ever evolving and as our demands grow in terms of productivity, hardware and software, there is a necessity to constantly upgrade our framework so that it meets the most current and immediate future needs.

.NET Framework 4.0 has a load of new things that specifically target, productivity of the developer, performance of the app and overall scalability of the app to co-align with new hardware paradigm that are lately coming into being.

I wish I had a little bit more time to do a few more demos. Nevertheless, we spoke / touched-base on the following with some demos as well:

• Code Contracts
• Background GC
• Type Equivalence and Type Embedding
• Dynamic Language Runtime
• Managed Extensibility Framework

As promised here are some of the demos that I did along with the slide deck. I am intentionally omitting some of the demos, since the code is yet not shareable. However, once I am all set to share that code, I will do so.

Note: The code is for demo purpose only and bucketed from various online / internal sources. I am thankful to my friends in the CLR team for giving me their valuable time and sharing some demos with me in order to make this session successful.

NET4Demos.zip (416.26 kb)

AdvancesInNet4.pdf (543.17 kb)

Cheers!

One of the key thought that comes up as we scratch the surface of MEF is...So what's new? I can use reflection and do that. It's important to understand that MEF is not a magic wand that can dynamically discover "altogether new" functionalities and dynamically plug it in an app. I don't think the programming world has reached up to that level yet where a program is as powerful as a human mind (which by far is the strongest processing machine to date).

If a human is exposed to new things then he has obvious and predictable actions/reactions. E.g. -

1. If someone gives me a book, I know it's a book, I look at the preface section, I look at the index and then I know whether to read the entire book or some sections inside it or just not read it. However, if someone hands me a book that is written in a language that I don't understand, the least I would know is that "This looks like a book" but that's about it. Full stop.
2. You place a ball in my hand. My mind, perhaps by experience knows whether it's a cricket ball, a soccer ball, a football, a tennis ball, etc. And based on that I will try to discover additional equipment that I might have to actually use that ball. E.g. I might look for a bat or soccer shoes or a tennis racquet.

MEF is pretty much the same thing. The application has to know what interface the new/dynamic component is going to expose. The component by-n-large can tweak the functionality specific to it's existence. The application has to be aware of what it is going to expect and clearly communicate that to the external world. I can't blind-fold you and then expect you to know and recognize which object I am throwing at you and to also know how to use it. :) lol.

So to say:

1. An MEF compliant application doesn't need to know the inner workings of the component that is dynamically going to be discovered. Note the component is discovered, but the interface is already know to the application.
2. An MEF application can be compared to an abstraction or a standard that promotes effective reusability of components.
3. As long as the MEF application is capable of publicly declaring that "I can understand and execute an Interface X with functionality Foo", all is good.

A simple yet great example that Sanjay Vyas (a.k.a Guruji) gave me was: Let's say my MEF application (let's say App A) understands an interface called IPrinter that has a Print method. Then there are several possibilities:

1. The developer can write his component / plug-in (e.g. which Prints to a printer) against this interface without worrying about how the App A will discover, load it and execute it.
2. The same component can be plugged into another app B which also complies to IPrinter interface with Print method.
3. The developer of neither App A or B or the component itself have to write any pieces of complex reflection code or some config file based code to dynamically discover and used the component.
4. Moreover another developer can implement the same interface and write a component that prints to a PDF file and drop the assembly into the path required by the application and the application can there-after dynamically discover this new component. The fact remains that the app will still be able to only call the Print method of the component. If the new component has a "Sing" method, the application will slap you back! (just kidding...no it will not know what to do with it and it won't even discover it).

In short what we are making available is a framework which will promote in-app, cross-app, cross-vendor reusability. It's a solid vision and it will take time to first establish itself as a standard that developers start adopting and adapting to. It's all about simplifying the not-so standard process of dynamically loading a plug-in. We (Microsoft) take care of the framework, you (end-user developer) just focuses on the functionality or the business problem that the component is trying to solve.

I hope that helps to clarify the thought.

My humble thanks to Sanjay for sharing his insight. It's important to understand the problem that exists, before really jumping to using a technology that is created or brought into existence to solve that problem :) [Well, it's another thing to not know that the problem was actually a problem :)]

Cheers!

DevCon was great fun! It was exciting to be delivering a session on .NET 4.0 and it was even more exciting to be co-delivering it with Sanjay Vyas (a.k.a Guruji). With the new version of .NET it's time the development experience rises to a new and an exciting level. I am uploading the PPT that we used for the session. Readers, feel free to ping me if you have any queries or doubts or share your comments.

Inside_the_guts_of_.NET_4.0.zip (1.04 mb)

Cheers and stay tuned for some more posts on 4.0!

-Sarang

For the past several months, me and my team have been working intensely on Microsoft Office Programming - VSTO and OpenXML. There have been so many discoveries around approaches to take and what works the best. Both OpenXML and VSTO have their own sets of pros and cons. Once the Office Environment (e.g. MS Word) is open, we were pretty much tied down with VSTO and the Word Object model, until we discovered that Range.InsertXML method is pretty much a legal method (hack) to actually manipulate the document at runtime using OpenXML. With OpenXML SDK 1.0, it's not very simple though and with a good deal of inputs from OpenXML Power tools team and other experts we found our way to simplify usage of OpenXML using LINQ and building a helper object wrapper around SDK 1.0. The key is to build it as close as possible to SDK 2.0 which is still in CTP, because the advantage is of that of portabilty when moving from SDK 1.0 to 2.0 whenever it RTM's.

I the next several blog posts, I am going to write about some of the cool things that can be done to solve certain specific Word programming scenarios using VSTO  and OpenXML.

Keep tuned!