Being an MVP

I’ve been a Microsoft “Most Valued Professional,” or MVP, for a long time now.  So long that I had to actually go look up when I was first got the award (2002).  Over those years, the program has changed, the technology for which I am an MVP has changed, and I’m certain that I’ve changed.

When I first got my MVP status, it was not long after I co-authored a book on embedded Visual Basic with a friend, Tim Bassett and at the time I was being pretty prolific in that extremely niche segment of the development community, publishing articles on DevBuzz and answering question in the now-defunct Usenet groups from embedded development (as a side note Microsoft has tried many incarnations to replace those groups, and have never found one that was as easy to use or navigate).

I remember that I felt a bit out of place at my first MVP Summit – the annual meeting of all MVPs in Redmond – because I was seeing and meeting all sorts of people that I had been using for information since I had started developing.

It wasn’t long, and my focus changed from eVB to the .NET Compact Framework – largely because Microsoft killed eVB as a product.  I embraced the CF and continued writing articles for MSDN and answering loads of questions and even doing the speaking circuit at what was then called Embedded DevCon.  I helped “start” OpenNETCF, which at the time was really just a collection of Compact Framework MVPs trying to answer questions, cover the stuff Microsoft was missing, and not duplicate effort.

In those early days of the CF, being an MVP was fantastic – it really was.  A few times a year the MVPs and the product teams would actually get together in the same room.  They would tell us what they were planning.  They would ask for feedback.  They’d listen to our ideas and our criticisms.  You could count on seeing direct results from those meetings in future releases of products coming out of Redmond, and so the MVPs continued to pour effort into keeping the community vibrant and well-informed.

Back in those days I knew both PMs and developers from most of the teams involved in the products I used.  I knew people on the CF team.  The test team.  The CE kernel and drivers teams.  The CE tools team.  The Visual Studio for Devices team.  And when I say I “knew” them, I don’t mean that at a conference, I could point them out, I mean that at the conference we went to the bars together.  I had their phone numbers and email addresses, and they would respond if I needed to get a hold of them.

Those I now know were the golden days of the program, at least from the embedded perspective. It could well be that C# MVPs or some other group still sees that kind of interaction, but the embedded side doesn’t see much of that any longer.  In fact, I know very few people on any of the teams, and I guess that most of those people probably wouldn’t answer my emails.

What’s changed, then?  Well, Microsoft is a business, of course.  A large one at that.  As such, they have constant internal churn.  Most of the people I one knew are still at Microsoft – they’ve just moved on to other things, other groups and other positions and the people that came in to replace them didn’t necessarily have the mechanism (or maybe the desire) to get to know the community of experts in the field.  The teams also shifted a lot – Embedded got moved from one group to another and to another inside of Microsoft, and the business unit got less and less priority for quite some time – especially when it and the group shipping quantity (Windows Mobile) were separated.  The Embedded DevCon became the Mobile and Embedded DevCon, then it went away.  Budgets shrank.  Community interaction receded.

I can’t say I fault Microsoft for this.  After all, they are a business, and they make decisions based on what provides shareholder value.  I may disagree with some, or even many of their decisions on the embedded side, but I don’t work at Microsoft, and I’m definitely not in their management team, so my opinions simply do not matter.

So why do I bother mentioning all of this, if not to complain?  Because I want you, as a reader, to understand where I come from in some of the articles I’ll be posting over the coming weeks.  I no longer have any inside information about the future of Windows CE or the Compact Framework.  I don’t know what Microsoft intends to do or not do.  I find out things about the technologies at the same time as the rest of the world.

This means that if you see me write something about the future of Windows CE, now called Windows Embedded Compact (and yes, expect to see something on that soon), it’s all based on my personal opinion and thoughts based on history *not* on any insider information.  If what I predict happens, it’s only because my guesses were educated and/or lucky.  If it doesn’t, it’s not because I was trying to be misleading, it’s because I simply got it wrong.  Basically, as with anything you read, I expect you to use your own critical thinking skills, and I fully encourage discussion and debate.

OpenNETCF.IO.Serial Library moved to Codeplex

As you may have guessed from some of my recent blog entries, we’re making a push to get a lot of our shared source code out to the Codeplex servers.  Our serial library is the latest one to make the move.  It’s now available at http://serial.codeplex.com.  As with all of these libraries, if you have the desire to contribute, fix, extend, or whatever just let us know and we’ll add you as a developer.

OpenNETCF.Desktop.Communication library has moved to Codeplex

In an effort to clean up our servers, to make code easier to find, and to hopefully make it easier for the community at-large to contribute, we’ve moved our popular Desktop Communication library over to the Codeplex servers.


Visit the project at rapi.codeplex.com.

OpenNETCF.Telephony library (TAPI) released under shared-source license

Over the past few months we’ve been working hard to consolidate the products we at OpenNETCF offer.  What this means is that products that didn’t sell well or that had high support loads compared to sales got dropped.  Our Telephony library is one of those that we decided to discontinue.  But that’s good news for all!  Instead of just letting it wither and die in the depths of our own source control server, we figure it might as well be thrown out to the community to see if it will flourish.


SO with that, we give you the OpenNETCF.Telephony Library, hosted over at Codeplex as tapi.codeplex.com.  Enjoy.

RAS, Windows Mobile and Windows CE

OpenNETCF used to have a product that provided RAS capabilities.  Well Microsoft deprecated RAS in WindowsMobile – starting with WinMo 5.0 as near as I can figure – in favor of Connection Manager.  That depracation actually broke RAS in some scenarios.  FOr example, if you create a RAS connection and then try to use a managed TcpClient, it will try to create it’s own connection through the Connection Manager instead of using the connection you created through RAS.


What this did was skyrocket our support incidents for something that we sold very, very few licenses for.  In the interest of keeping our sanity, yet allowing people using plain of Windows CE to still use RAS, we made the decision to just make it a shared source project.  It’s now out on CodePlex.  If you need support for it, we still offer consulting services, but everything is there to get you going.

The OpenNETCF.IoC Framework: Items and Services

Articles in this series
Part I: Inversion of Control and the Compact Framework
Part II: The OpenNETCF.IoC Framework: Items and Services (this article)
Part III: The OpenNETCF.IoC Framework: Events
Part IV: The OpenNETCF.IoC Framework: Performance (TBD)

Downloads
Code and Sample available through CodePlex.


The OpenNETCF.IoC Framework

Since I don’t expect that everyone has used the SCSF and since the OpenNETCF IoC framework is a very small subset, let’s walk through what it is and how it works.  First, the OpenNETCF.IoC framework is based on the concept of “Components.”  A Component is simply an instance of a class and our framework has two flavors of Components: an Item and a Service.  Generally speaking, the difference between an Item and a Service is that an Item is a uniquely-named instance of a Type (so you can have any number of them provided each instance has a unique name) whereas there can only be one Instance of a service per registered type (it acts somewhat like a Singleton).

Both Items and Services are contained as collections in a root container called the RootWorkItem (a name that comes from the CAB framework).  Let’s take a look more in depth at each of these components and how you might use them together.  For this example we’ll get a little more concrete that the Cars and People example from before, and instead look at classes more actual applications might use.

Items

As I mentioned, Items are simply uniquely named instances of objects.  They can be of any Type – the Items collection doesn’t need to contain only a set of a specific type.  The Items are contained, conveniently enough, in the RootWorkItem.Items collection.  So exactly what advantages to we gain by putting our items in this collection?  The primary benefit is that the RootWorkItem becomes an instance manager and, as we’ll see in a little bit, it can also be a factory.

Let’s assume that our application contains the following Forms: MenuForm, EntryForm and SettingsForm and to make things simple, we’ll assume that they are named with their type name.  If we have these forms in the IoC framework, then any time we need to reference one of them we can simply do something like this:

 

desiredForm = RootWorkItem.Items[“EntryForm”];

 

and ta-da, we get the instance of the Form.  We don’t need to pass around a reference to it or store it in some other application global location.  So that’s pretty useful right there.  But the RootWorkItem really is just an application global, right, so it must provide some other benefit.  Well it’s also a factory.  If we want to create the entry form we can use a basic create-and-insert mechanism like this:

EntryForm form = new EntryForm();
RootWorkItem.Items.Add(form, “EntryForm”);

But that really isn’t all that interesting.  Where it gets interesting is that you can let the framework do the construction for you by simply giving it a Type and name (the name is actually optional, as the framework will assign it a GUID if you don’t provide one):

RootWorkItem.AddNew<EntryForm>(“EntryForm”);

That’s handy.  No need to call the object contructor to get an instance and then stuff it into the collection.  Less code is always a good thing.  But what else can it do (right now I’m feeling a bit like Ron Popeil)?

Well that’s not all!  Where it gets fun is in its ability to do injection.  This requires a little more complex of a scenario.  Let’s assume that the MenuForm requires an instance of both an EntryForm and a SettingsForm.  Something like this:

class MenuForm
{
  public MenuForm(EntryForm entryForm, MenuForm menuForm) {…}
}
 

Well the OpenNETCF.IoC framework can actually do these injections for you – all you have to do it provide it a little direction with attributes.  If we simply decorate the constructor with the InjectionConstructor attribute, the framework will search the Items collection for existing items of the proper type to inject.  So the MenuForm looks like this:

class MenuForm
{
[InjectionConstructor]
  public MenuForm(EntryForm entryForm, MenuForm menuForm) {…}
}

And construction now looks like this:

RootWorkItem.AddNew<SettingsForm>(“SettingsForm”);
RootWorkItem.AddNew<EntryForm>(“EntryForm”);
RootWorkItem.AddNew<MenuForm>(“MenuForm”);

And the magic of the OpenNETCF.IoC framework will inject the first two instances into the third.  An interesting note here is that the Injection Constructor does not have to be public.  The OpenNETCF.IoC framework looks for internal and private constructors as well so you can actually create objects that can only be generated via injection if you wish.

Of course the framework also supports Injection Methods as well, in the event that an InjectionConstructor doesn’t meet your needs:


class MenuForm
{
  public MenuForm() {…}

[InjectionMethod]
void InjectEntryForm(EntryForm entryForm) {…}

[InjectionMethod]
void InjectSettingsForm(SettingsForm settingsForm) {…}
}

But wait, there’s more!  In the examples so far the RootWorkItem.Items collection must contain the SettingsForm and EntryForm before the MenuForm is created.  Well what if we are lazy and don’t even want to do that?  Well the OpenNETCF.IoC framework can handle that too.  Just add the CreateNew attribute like this:

 

class MenuForm
{
[InjectionConstructor]
  public MenuForm([CreateNew]EntryForm entryForm, [CreateNew]MenuForm menuForm) {…}
}

 

And the framework will create a new instance of the Type if it can’t find it in the Items collection. Construction of all three objects and injecting them now looks like this:

 

RootWorkItem.AddNew<MenuForm>(“MenuForm”);

 

Extremely simple and clean.

Services

The RootWorkItem also contains a collection of Services.  A Service is very similar to an Item except for the fact that there can only be one service of any given registered type (we’ll covered what “registered” means in a moment).  The collection provides a very similar set of methods and attributes as items.  Again, let’s consider a more concrete example.  Assume your application has a class that handles reading and setting configurations.  There really would only be one instance of this class and in a lot of classic cases people would use the global-wrapped-in-a-new-name called a Singleton.

In the OpenNETCF.IoC framework this would be a service.  Since there can only be one pre registered type, there’s no need to name a Service – the registration type becomes the identifier.  So as a simple construct/add/retrieve a Service operation would look  like this:


Configuration config = new Configuration();
RootWorkItem.Services.Add<Configuration>(config);

Configuration retrievedConfig = RootWorkItem.Services.Get<Configuration>();

As with the Items collection, there is a lot more power and convenience in the framework.  First, we can have the framework do construction for us:

 

RootWorkItem.Services.AddNew<Configuration>();

 

 

Like the Items collection, InjectionConstructor or InjectionMethod attributes can be used to control which constructor for the service class gets called.

The OpenNETCF.IoC framework also offers lazy loading of services, so the service instance isn’t actually created until it is first accessed (instead of when it’s added).

 

RootWorkItem.Services.AddOnDemand<Configuration>();

 

 

We saw earlier that the OpenNETCF.IoC framework would walk the Items collection looking for instances to use during injection.  Well what if an object depends on a Service rather than another Item?  The framework also provides a mechanism for that as well using the ServiceDependency attribute.  So to inject a Service into a consumer class using Constructor Injection it would look like this:

class ServiceConsumer
{
[InjectionConstructor]
  public ServiceConsumer([ServiceDependency]Configuration config) {…}
}

And of course there is a way to do setter injection instead of constructor injection.  Here it injects into a property instead of using a method like the Items collection:

 

class ServiceConsumer
{
  public ServiceConsumer() {…}

[ServiceDependency]
  public Configuration Config { set; get; }
}

 

And if you want the framework to construct the service if it doesn’t already exist, you simply set the EnsureExists member of the ServiceDependency attribute like this:


[ServiceDependency(EnsureExists=true)]
public Configuration Config { set; get; }

The only other aspect of a Service that an Item does not have is a “registration type”.  This allows you to register a service instance as a type other than its actual base type.  For example you may have a Configuration class that you want to register as a service, but you want to register it as an IConfiguration (this would allow consumers to extract the service by the interface type without ever knowing about or having a reference to the concrete implementation).

 


Up next: The OpenNETCF.IoC Framework: Event Publication and Subscription

New Article: Determining Form and Process Changes in Windows CE

Today I saw two separate posts on pretty much the same question.  How can you determine if the foreground window changes in a WinMo application?  Moreover, how can you determine if the new foreground window is your own, or in some other process?  My initial thoughts were to do some work in the Form’s Deactivate event, but that would lead to having to plumb it into every Form, and then you’d still need special case handlers for MessageBoxes and Dialogs and it would be an unmaintainable pain in the ass. I decided to put some time aside this afternoon and see if I could come up with a better solution, and what I came up with is outlined in a new article entitled ‘Determining Form and Process Changes in Windows CE‘.  It’s available over in the Archives.