Sunday, June 17, 2012

Bindings and Coupling

Short post today since I just got back from a nice beach vacation. The next Practical Patterns installment should be up shortly, but first, quick detour to explain a couple of concepts that arise frequently when trying to describe patterns: binding and coupling.

When we describe the design and behavior of an object-oriented system, we are mostly interested in how the various objects interact with each other. Patterns, as an example, formalize a set of well-known and well-understood interactions between various objects in a system. In general, there are two different kinds of object-object interactions that we need to understand: the design-time, or architectural, interactions, and the run-time, or implementation, interactions.

The related concepts of binding and coupling describe various aspects of these interactions at run-time and design-time, respectively. Understanding them is a large part of understanding the benefit we get from patterns, so lets take a look.

Saturday, May 19, 2012

Proxyless WCF: Sample Source Code

Now that the blog is being hosted on a real web site, I'm finally getting around to uploading sample code. I've re-uploaded my caching IStream wrapper, and have uploaded the sample solution from the Proxyless WCF Series.

You can find the entire solution here.

Some notes about this solution that will generally apply to any other projects I upload:

The projects are made for Visual Studio 11, but should work fine under Visual Studio 2010. For the time being they all still use .NET Framework v4.0 and C# 4.0, unless otherwise noted. The database projects require you to install the SQL Server Data Tools extension for VS2010. They also assume you have a local SQL Express instance named SQLEXPRESS; if not, you'll need to fix up the connection strings and deployment options.

The web site and service host projects are configured to use IIS Express. Generally speaking, if you have IIS Express installed, just opening the project in Studio will configure everything properly. However, IIS Express can sometimes get confused when you first open a project that has an https base URL (such as the Proxyless WCF service.)

In these cases, Visual Studio will likely try to set up a standard http binding, but using the https port. This doesn't actually work, and Studio usually complains that it didn't have sufficient access to configure the site. In reality, you just need to manually edit the bindings to add both secure and non-secure ports separately. Find the applicationhost.config file (in your Documents\IISExpress folder), and locate the <site> element for the project. (If you've tried to open the project more than once, you may have several copies; just delete all but the first.) Then edit the bindings to specify the correct ports for both protocols. For example, the Proxyless WCF service should have the following bindings set up:

  <binding protocol="http" bindingInformation="*:6067:localhost" />
  <binding protocol="https" bindingInformation="*:44302:localhost" />

Make sure you set up a non-secure binding, even if you never use it; this will prevent Studio from getting confused the next time you open the project.

Tuesday, May 08, 2012

Practical Patterns 2: Iterators

As mentioned last time, this installment of Practical Patterns will focus on a pattern that is (hopefully) familiar to most programmers, even if they don't realize it: the Iterator pattern. This is another broadly useful utility pattern, that shows up in some for or another in almost any production application. It is such a useful pattern that many languages have built it into their standard libraries. So, lets take a look at the Iterator.

Thursday, April 12, 2012

Practical Patterns 1: Singleton

As I've mentioned before, patterns are practically a way of life for modern software developers. But too many programmers are still unfamiliar with them, even as they unknowingly use (or worse, re-invent) them. This series hopes to provide a solid introduction to pattern development in C#.

For the first entry in this series, I wanted to start simple, with one of the most popular design patterns: the Singleton. This is a pattern that many developers are familiar with, even those otherwise unaware of design patterns in general. This should give us a nice, gentle introduction into the topic. Even so, there's a lot of detail here that is often overlooked. (Singletons are also one of the most commonly poorly implemented patterns.)

As this is the first post in the series, I'm still working out the format. For now, each post will discuss a single pattern, broken down into the following segments:
  • Who - The name and basic description of the patter.
  • What - A longer description of the patterns behavior, requirements, and purpose.
  • When - Major use cases and types of problems this pattern can solve.
  • Where - The kind of applications, frameworks, and other patterns where this pattern is often found.
  • Why - The reason we apply this pattern to solve a problem, as opposed to other possible solutions.
  • How - A detailed implementation of this pattern in C#, and how it was derived.
So, lets get to it.

Tuesday, April 10, 2012

What is NP and why is it so hard?

For some reason that now escapes me, I recently got into a discussion with a fellow developer about the Japanese puzzle game Nurikabe in which I mentioned that solving Nurikabe was in NP. (In fact, "does this puzzle have a solution" is NP-Complete.) I then realized this person had no idea what I was talking about.

(UPDATE: I think this excellent STL video is what started this whole mess. Blame Stephan!)

If you spend enough time in certain areas of the computer industry (notably cryptography, language/compiler design, or game theory) you will frequently hear phrases like "this problem is NP-hard", or "that's equivalent to solving the halting problem." Claiming that a problem is NP-hard or even unsolvable is a very important statement, but one that is often misunderstood even by people with a general idea of what those terms mean.

So, as is my habit recently, I'm taking to my blog to expand on that conversation; this is somewhat outside the usual subject matter, but hopefully as developers you will find it interesting anyway. (And hope that no one at work ever asks me how a neutron star forms.) Also, fair warning: math ahead.

Wednesday, April 04, 2012

Marshaling UTF-8: Harder than it ought to be.

A few days ago, I was looking at the codeplex project libspotifydotnet, published by a friend of mine, Scott. The project is a managed wrapper around Spotify's cross-platform API which, of course, is written in C.

Some of you may know Scott as the author of Jamcast, a super-awesome media server that lets you play your local media library over all kinds of UPnP devices: game consoles, PCs, purpose-built DLNA devices, even an Android smartphone. Some of the most interesting interop work I've ever done has been to support Jamcast, including a fasincating dive into JNI and the Android bionic runtime. So, I was not surprised that this particular interop API yielded some more interesting stuff.

In this case, the wrapper around libspotify brought up a couple of issues that are commonly found in third-party libraries, particularly cross-platform ones, but rarely arise when you're doing Windows P/Invoke. The one I want to focus on today is the string handling: libspotify strings are UTF-8 encoded, and if you're not careful, this case wreak havoc on your interop code. So, lets see how to be careful.

Saturday, March 24, 2012

Practical Patterns - Introduction

Design patterns are a key aspect of modern software development. The (re-)use of known patterns is almost universally accepted as a sign of a well-designed system. Resources ranging from community forums and blogs, to magazine articles, to official development guidance promotes their use.

So why do so many software developers continue to develop applications without them?

There is probably not one single answer to that question, but I suspect the problem is mostly due to a simple lack of understanding about patterns and their usage. By that, I partly mean that many developers still don't know what patterns are, or what they are called. But even once that hurdle is overcome, there is still a lack of awareness of the best way to use a given pattern. And using a pattern incorrectly can often be worse than simply cooking up your own solution to a problem.

By their very nature, patterns are language-agnostic. Most discussion and information about them is written in terms of their broad goals, their design philosophy, and their abstract behaviors. Instead of doing more of that, I'd starting what (I hope will be) a recurring series on the practical application of design patterns, specifically in applications written in C#, using WCF and WPF, for .NET 4.5, in Visual Studio 11. (I'll try to avoid too many .NET 4.5isms, or at least point them out when they show up.)

For this first post, though, I thought I'd start with a brief introduction to patterns as a concept. This won't be anything too ground-breaking; if you've read the Gang of Four book then you will probably find this post somewhat repetitive. If you have no idea what the Gang of Four book is, keep reading.

Monday, March 19, 2012

Major Props to Bright House Networks

Just wanted to give some well-deserved kudos to BrightHouse for having some pretty impressive customer service. Decided to upgrade both my standard DVRs to HD and my standard Internet to "wideband" in one weekend. Of course things went wrong, but BH sent out a technician at the last minute at 7pm on a Sunday to fix my DVR. Then their phone support reconfigured my Lightning modem to work with my Gentoo firewall/mail server/etc without even batting an eyelash.

WAY better than my experiences with Comcast, I must say.

Plus now I have wideband, which is clearly wider than broadband and thus better.

Thursday, March 08, 2012

Proxy-Free WCF: Bonus Round:Entity Framework

In a few previous posts, we've seen how to go about eliminating the auto-generated service references from your WCF clients. This is done by using a ChannelFactory and sharing your model objects through a channel independent of the WCF service itself (e.g. a shared assembly.)

In those posts, our model was a very simple, single POCO entity that we moved into a class library, which we then shared between client and server. In practice, your model is probably going to be significantly more complex. It might be something like an Entity Framework model, which we certainly don't want to share in its entirety with our client!

Today, we'll look at how the Entity Framework already supports being used as a data contract for WCF, and how we can extend this to support our proxy-free WCF clients.

UPDATE: See this blog post for the sample code for this article.

Wednesday, March 07, 2012

Proxy-Free WCF: Ditching The Proxy

Last time, we took a peek inside the auto-generated code that makes up a Visual Studio Service Reference. When you strip away all the tooling support and configuration data, what we're left with is a very thin wrapper around a dynamically-generated proxy class, courtesy of the ChannelFactory object.

Today, we'll see how to take advantage of that class directly, and eliminate the need for a Service Reference at all. Along the way, we'll also see how to use this new-found knowledge to help with unit testing and a few other interesting scenarios.

UPDATE: See this blog post for the sample code for this article.

Saturday, March 03, 2012

Visual Studio 11: First Impressions

So, like probably every other C# developer in the world, I downloaded and installed the Visual Studio 11 beta a few days ago. I've decided to start using it for all of the sample code for the blog, so I thought I'd give you some early impressions.

The usual caveats apply, of course. This is a beta so I'm not terribly worried about bugs yet; I'm mostly interested in the new features and enhancements. Also, I'm playing with the Ultimate edition of VS11 but I will probably only end up using the Premium edition, so I'm going to ignore some of the advanced features that aren't part of Premium. That said, lets take a look.

Thursday, March 01, 2012

Proxy-Free WCF: What's In A Proxy

Writing services-based applications using Visual Studio has always been fairly easy, dating all the way back to the web services support in Visual Studio 2003. These days, services means WCF services, but the IDE support has remained largely the same. You just need to supply Visual Studio with the URL for your web service, close your eyes, tap your heels together, and poof! You get a fully-functioning WCF client proxy class all ready to go.

This process works very well for simple applications, or applications using third-party web services. But when you start writing applications against your own services, and factor in things like deployment, unit testing, etc., the default client proxy generate can really start to work against you. Fortunately, you do not need to use these client proxy classes: WCF includes everything you need to generate them on demand, at runtime, with only a tiny bit of effort.

Friday, February 24, 2012

Out Of Control InteractionRequestTriggers

Recently at $DAYJOB, I ran into an interesting problem with Prism's interaction framework, which made our InteractionRequest actions start firing themselves off more than once. It turns out that the problem was in the InteractionRequestTriggers, specifically, the ones found on a particular view that was nested inside two levels of ContentControl. Tracking down the problem took the better part of a day; fortunately, fixing the problem took less than 10 minutes. (In fairness: the problem wasn't Prism's fault; it's a problem in the Blend classes that Prism derives from. We just happened to be using Prism when we found it.)

Monday, February 20, 2012

We Are Marshal(ing)!

If you've been following my interop posts you've seen me toss around the word "marshaling" a lot, without really talking about what that means or how it works. This is an unfortunate oversight, since marshaling is possibly the most central concept behind interop programming. So, lets remedy that. Lets see what it means to marshal.

Friday, February 03, 2012

Seeking The Unseekable: Managed IStream Wrapper

Previously, we took a look at one of the most useful COM interfaces around, IStream. We first briefly looked at the built-in BCL translation for this interface, before building up a new and improved version. But there were a couple of other salient points in that post, unrelated to the actual translation of IStream:
  1. Despite being part of the BCL, none of the BCL Stream types implement IStream, and
  2. Implementing IStream is more complex than simply deriving an IStream wrapper from the Stream base class.
The problem is, there is not a one-to-one mapping between the things an IStream can do, and the things a Stream can do. In particular, all IStream implementations are seekable: IStream makes no provision for a non-seekable stream. This means you can't wrap a NetworkStream, for example from WCF, in an IStream wrapper and hand it off to COM.

Today, we're going to see how to solve that problem, and in the process, look at a real implementation of a COM interface in managed code.

Wednesday, February 01, 2012

The Zynga Consumer Protection Agency

Lately on Facebook, I've been noticing a massive upswing in the Zynga hate. I'm not sure what's triggering this all at once, though it seems to be centered on Mafia Wars (which I don't play). That there are Zynga hate groups doesn't really surprise me; any company with over 200 million customers is bound to piss off a bunch of them at some point.

One of the biggest complaints leveled at the company are "lost" or "missing" in-game purchases. This got me thinking about the whole concept of app purchases, especially the way social games implement them, and how there is a huge problem here waiting just under the surface.


Every brand of microwave popcorn you can buy says not to use the "Popcorn" button on my microwave to cook it. 

So why do they keep putting "Popcorn" buttons on microwaves?

Monday, January 30, 2012

Managed IStreams

Most of the time, when we want to use some unmanaged Windows feature in C#, we have a lot of work to do first. But there's a small set of types that come pre-translated, in the System.Runtime.InteropServices.ComTypes namespace. These types provide basic COM features, like activation, naming, storage, etc.

One of those types is the IStream interface, used by COM to represent a data stream. As interfaces go, IStream is a pretty good choice to be one of the few types Microsoft translates for us. In COM, an IStream is the de facto standard for sending data between COM components. And C# developers love the Stream object, for much the same reason. This sounds like a match made in heaven!

Unfortunately, there are some problems with the Framework's version of IStream that makes it harder to use that it really needs to be. Beyond that, the way COM handles streams is a bit different from the way the Framework does, making the two not-entirely-compatible. These differences make the IStream interface, as designed, less useful that it ought to be. So today, we're going to fix it.

Thursday, January 26, 2012

MVPVM: The Best of Both Patterns?

In the past few posts, we've been looking at some architectural patterns that are in common use among .NET developers, including the classic Model-View-Controller, and derivatives like Model-View-Presenter and Model-View-ViewModel. My original motivation for writing these posts, however, comes from an even newer pattern, an extension of the MVVM pattern called the Model-View-Presenter-ViewModel pattern.

Until recently, I had been using these various patterns in different projects without really thinking too much about where they came from or how they were related. I (like many other developers, I suspect) was just using the pattern that seemed to work best: MVP for my Windows Forms app, MVC for my new ASP.NET apps, MVVM for my WPF apps, etc. But as I was reading an article in MSDN magazine from December 2011, on a new pattern for WPF applications, everything semed to "click" for me, how these patterns evolved, how they were related, and why a given pattern works better than any other in a given situation.

I wrote out this series of blog posts, in part, to help crystallize this new understanding in my own mind, and in part to share it with other people who may still be unclear on what all this "pattern" stuff is all about. So, it seemed only fitting to wrap up by giving a brief overview of this new pattern, and my thoughts on it. First, though, a couple of caveats:
  1. I have never used this pattern in production, so I am in no way an expert on it. These are just my early impressions.
  2. This pattern is still fairly new -- even the name is not yet in common use. So I'm pretty confident that this pattern will evolve as people learn and understand more about it.
  3. So far, I'm not entirely convinced that this pattern is something I'll ever use, but see point #1.
  4. Because of point #1, this is going to be a much shorter post, with less code, than usual. Hopefully, as I get more acquainted with this pattern, I can come back and do a better one.
So, consider this just my first impressions and musings on an emerging idea in pattern-based development.

The Composite Application Library

The origins of this pattern, which was largely unnamed until recently, was the Microsoft Composite Application Guidance, also known as the Prism project, which was designed to guide developers writing enterprise-level WPF applications. It takes advantage of other Microsoft frameworks, like Unity or the Managed Extensibility Framework, to combine loosely-coupled elements of your application in various ways at run-time.

Although the guidance talks a lot about the MVVM pattern, if you look closely, you'll see that the actual pattern  is not a typical "triad", like the other patterns we've looked at. Instead, there is a fourth component included in the mix, which is used to coordinate among the other three. For lack of a better term, this component is called a Presenter, since it behaves much like an MVP Presenter is supposed to.

One of the key aspects of Prism is that every element in the application is very loosely coupled to the other elements. Prism uses various techniques at run-time to bind those elements together in combinations as needed, so the elements themselves must be highly reusable and flexible. One of the flaws in the MVVM pattern is the tight binding between the View and ViewModel, especially once your ViewModel starts asking for user input (confirmation dialogs, etc.)

Splitting the View and ViewModel

This is where the MVPVM pattern comes into play. Its target audience is very large-scale enterprise applications where multiple views, with different business requirements, may need to bind to the same ViewModel, which means your ViewModel cannot include view-specific business logic. It also means you will definitely be doing extensive unit testing and coded UI testing of your components, so you need that process to be as efficient as possible.

Here is one place that I start to lose the thread of why this new pattern is really necessary for my purposes. To quote Bill Kratochvil (author of the referenced article) on why this new pattern is needed:
If you have to put code in your WPF code-behind, for any reason, then you've run into a limitation of MVVM alone;  a limitation that will prevent reuse, prevent proper unit testing and cause code bloat. --
(An interesting note from that blog post, that I missed in my original MVP and MVVM posts, is that MVVM is really just a new name for an old pattern, the PresentationModel pattern, updated and enhanced for WPF). But the key here, IMO, is this contention that any WPF code-behind at all represents a serious flaw in your architecture. To me, that's just silly, and represents a strange belief that the code-behind is somehow a separate and independent component of the system. To me, the code-behind class behind a WPF Page or UserControl is part of the View: anything I would logically be able to place in the View I can just as logically place in the code-behind. Obviously, there are a lot of benefits to keeping the code here small and letting WPF do the work, but something like this, for example, represents a perfectly natual use of code-behind for me:
private void DataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
    var old = e.OldValue as TransactionTenderWindowViewModel;
    if (old != null)
        old.ValidateOperation -= ValidateOperation;

    var value = e.NewValue as TransactionTenderWindowViewModel;
    if (value != null)
        value.ValidateOperation+= ValidateOperation;

private void ValidateOperation(object sender, ValidateOperationEventArgs e)
    var message = string.Format("Please confirm that you really want to {0} your {1}.", e.Operation, e.Target);
    var result = MessageBox.Show(message, "Validate Operation", MessageBoxButton.OKCancel, MessageBoxImage.Information);
    e.Cancel = (result == MessageBoxResult.Cancel);
Here, my ViewModel is firing an event that says "any Views that are listening to me, if you don't want me to Operation my Target, now's your chance.".

Under the MVPVM model, this code would instead belong in a Presenter class that handles this validation for the views that need it, and ignores the validation for views that don't care. In this model, it is only the Presenter that has any tight coupling to other components: it is bound to a View, a Model, and a ViewModel, and ferries information and operations between the three. This is a Supervisory Controller style Presenter: the View and ViewModel still have some direct data binding, but complex operations are offloaded to the Presenter. The following diagram from the MSDN article shows these relationships (note that the business and data logic, and domain models, all fall under the Model aspect of this pattern):

The MVPVM Architectural Pattern

Of course, the problem here is that the target environment for this pattern are applications on a far larger scale than anything I typically have to deal with. (I don't think I've ever seen the kind of application that Prism considers "enterprise-level", based on their description). The focus of the MVPVM pattern isn't simply to get code-behind out of the View, but to get view-specific logic out of the ViewModel, to make the entire application modular, scalable, and testable.

Kratochvil uses an example of a set of search results screens, all using the same underlying ViewModel, where some views display a certain field and other don't. Instead of polluting the ViewModel with the knowledge of its parent View and logic to set/clear the field's visibility, that logic is moved into a Presenter that coordinates between the two, now decoupled View and ViewModel objects as needed.

Now, in my understanding of the MVVM pattern, it is not common practice to reuse a ViewModel for multiple Views. In the above scenario, there would simply be more than one ViewModel, possibly with the common operations refactored into a base class. (Arguably they may also belong in the Model itself.) However, as your application scales in size, having lots of redundant ViewModels can become a problem. This is particularly true if your application has Views for lots of different target environments (web, client, mobile, etc) that are slightly different in their requirements: maybe none of your mobile Views are allowed to see social security numbers, or something.

Final Impressions

Overall, I'm still getting familiar with this pattern, so take these comments for what they're worth. When I started reading about this pattern, my first thought was an old programming adage:
All problems in computer science can be solved by another level of indirection -- David Wheeler
That clearly seems to be what's going on here: the pattern is solving the "problem" of having tightly-bound View and ViewModel classes by adding an indirection layer between them. The second thought I had was (with sincere apologies to Jamie Zawinski):
Some people, when confronted with a problem, think "I know, I'll use another level of indirection." Now they have two problems.
One of the biggest complaints about the MVVM pattern is that it's adding too much overhead, for too little benefit, to what is already a complex framework (WPF). This pattern takes that overhead and layers on another pile of overhead, for arguably even less benefit.

My impression here is, if you are actually writing an application where the Prism library and guidance can be useful for you, the runtime overhead of adding a Presenter to MVVM will be swallowed up in the noise. And the benefits you gain from testing efficiency and responding to changing requirements will probably add up to a major net gain over the added development complexity. But for me, for now, MVPVM is staying on my shelf as one of those ideas that never found a need for.

Tuesday, January 24, 2012

The MVVM Pattern: MVP Evolved

So far, we have taken a close look at two of the architectural patterns in the Model-View-Whatever family, the MVC and MVP patterns. These patterns both enjoy widespread use across platforms, languages, and runtime environments, and are both still in heavy use.

Today, we're going to look at a pattern that is somewhat more specialized, and at least at this point, primarily finds use in WPF applications: the Model-View-ViewModel pattern. MVVM is a natural evolution of MVP that takes advantage of WPF's features, as we'll see in a minute. But first, what is MVVM and how did it develop?

Saturday, January 21, 2012

The MVP Pattern: Son of MVC

Last time, we starting looking at the concept of architectural patterns, and how they are used in software development. We also traced the history of the prototypical architectural pattern, the Model-View-Controller or MVC pattern, from its Smalltalk roots in 1979 through 3 decades of progress, to modern MVC frameworks, like Ruby on Rails or ASP.NET MVC.

But MVC isn't the end of the story, not by a long shot. Besides evolving into new versions of itself, the MVC pattern has also spawned an array of alternative patterns. These patterns take the same core concept, separation of concerns at a fundamental architectural level, and just reorganize where all the pieces go.

Today, we'll take a look at some of the common elements of this family of patterns, then examine one  of those variations in more detail: the Model-View-Presenter or MVP pattern.

Tuesday, January 17, 2012


One of the things I and my colleagues at my $DAYJOB have been dealing with on our current project is understanding a popular WPF architectural pattern called the "Model-View-ViewModel" pattern, or MVVM. It is the latest in a growing trend of alphabet soup coming out of the .NET developer's community. For myself, and I suspect many others, it is sometimes a struggle to understand what all the fuss is about, and why I should waste my valuable development time learning some new technique that will just disappear when the next big thing comes along.

Much of the problem is that these new design patterns seem to require me to write code in a dramatically new and different way than I am used to, without providing any real, tangible benefits for doing so. Worse, these concepts seem to be coming out of nowhere, with no background or foundation behind them, and immediately being touted as the next great thing in software development. Recently, however, I have had an epiphany of sorts. Not really anything so dramatic, but a number of things seemed to "click" for me in a way they had not before.

For many of you, particularly if your background is not Windows desktop development in C/Delphi/VB/C#, some of this will be like going back to grade school. However, I suspect I'm not the only one overwhelmed by all these big ideas, so I'm going to try and explain the concepts behind these "new" techniques, at least how I understand them, for the benefit of anyone else that's struggling to figure them out.

Friday, January 13, 2012

Hungarian Notation and Interop Code

Those of you without a lot of pre-.NET programming experience may have noticed the very bizarre names used by the various Windows SDK functions, interfaces, and types we looked at during the COM interop series. You may be wondering what, if anything, those cryptic jumbles of letters meant.

The short answer is, they are called Hungarian Notation (a reference to the proper name style used in Hungary, the native country of the developer who invented it), and it has largely fallen out of favor. You can get into some very vicious arguments with long-time developers by simply declaring your love/hate for it. Personally, I don't like to use it simply because it clashes with the current prefix-free style of C# naming conventions.  I have already mentioned my preference for translating structure names into friendlier names; I generally do the same thing for fields and parameters as well (but, somewhat arbitrarily, not interfaces or functions... see below.)

The longer answer is much more interesting, and somewhat of a tragedy, in that something with the potential to be very useful was misused to the point of meaninglessness. If you're interested in the details, read on...

Wednesday, January 11, 2012

COM Interop Part 10: Recapping And Wrapping Up

Wow, this turned out to be a much bigger series that I originally planned, but we covered a LOT. To wrap up, I want to just summarize some of the most important information we've covered so far, in preparation for future posts where we do cool things with COM Interop. Consider this something of a cheat sheet for interop translations.

Monday, January 09, 2012

COM Interop Part 9: Custom Activations

So far, we've seen how to activate a single instance of a COM object, both locally and remotely, using CoCreateInstance or CoCreateInstanceEx. But there are many other ways to get a COM object activated, some of which allow us to do pretty interesting things. Today, to finish out this introductory series on COM interop, we're going to take at those other methods: CoGetClassObject, DllGetClassObject, and custom SDK functions.

Friday, January 06, 2012

COM Interop Part 8: Strings, Arrays and Structures

In the last installment of this increasingly long series, we saw how to activate a new COM object for the first time on a local machine. One of the features of COM programming (and a big deal at the time it first came out) was the fact that remote, or "distributed", COM programming was almost as easy as local programming: all the complex work was handled by DCOM and the client could largely ignore the distinction.

Activating remote COM servers through COM interop turns out to be almost as easy as activating local ones. Translating those methods properly, however, means digging into some new details of the data marshalling logic: arrays, strings and structures. We're starting to get into the really good stuff here, but it's a lot to take in, so hold on tight and lets get to it.

Wednesday, January 04, 2012

COM Interop Part 7: COM Activation

So far in this series, we have focused on how to translate the methods of a COM interface. To fully exploit the power of interop, however, we need to understand a couple more types of native code element: structured types, enumerations, and functions. (For clarity, from here on out, when I say "function" I mean a native non-COM function, as opposed to a "method" which is part of a COM interface.) Windows-provided COM components make frequent use of all of these elements, so it's important that we understand the rules for those as much as the COM interfaces themselves.

This time, we're going to focus on native function calls. These are accessed via an interop mechanism called "platform invoke", or P/Invoke, which is subtly different than COM Interop. For the most part, P/Invoke calls are used to deal with part of the Windows API that are not based on COM, particularly the kernel itself, the GDI engine, and the windowing system. However, the COM-based SDK components also expose a small, but critical, number of P/Invoke calls that we need to use. To start off, we're going to take a look at the P/Invoke methods that do something we've kind of glossed over up until now: give us an initial reference to a new COM instance.

Monday, January 02, 2012

COM Interop Part 6: IUnknown and RetVal Rewriting

Today, we're going to finish out the definition of IUknown that we started last time, by adding the three methods to the interface. While it's a very simple interface, compared to some of the others we'll get to later, it does highlight a number of interesting and important behaviors that the runtime marshaller exhibits when calling a COM interface.

[Edited 1/3/2012 to include information about how the runtime translates is/as into QueryInterface].

COM Interop Part 5: Translating IUnknown For Fun And Profit

Well, probably not much profit, but hopefully a little fun.

As promised, this time we're going to write some actual C# interop code. A major downside to learning COM Interop is that there isn't an obvious place to "start small". You basically have to get all of the details right all at once, or things can go catastrophically wrong. Unfortuantely, that means the first few posts will have to include some things that might not make sense right away. Bear with me on this, we'll cover it all eventually.

When starting out to use COM Interop, I typically follow the same basic steps to get from idea to working code.
  1. Identify a COM interface I want to use, and whatever native functions I need to get it.
  2. Locate the IDL or header file in the SDK with the appropriate definitions.
  3. Locate the documentation for the interface or function.
  4. Start translating the interface from IDL
  5. As I encounter additional interfaces, types, etc., repeat steps 2 through 4.
The first step is sometimes the hardest, because Windows has a lot of interfaces available that do some pretty cool things. As you can tell, MSDN is a treasure trove of information here, and is usually where I start. The MSDN page for a function or interface will also tell you what IDL and header files to look in, and describe the intended behavior (the "contract") for the interface. With those two things, we have everything we need to start translating.

So, lets do one. I'm going to start with a relatively simple interface, just to show you how things go. Much of this is boilerplate stuff, so every COM interface you translate will start off the same. The interface we'll be looking at is the same one from last time, IUnknown.

COM Interop Part 4: A Look at IDL

Last time, I promised we would get to some real code. That was only slightly a lie: there's code in this post but it's not C#. Instead, I wanted to talk about one more aspect of COM development that we'll be seeing a lot of, once we get started.

COM Interop Part 3: Every Day I'm Marshalling

(I apologize profusely for the title, but I have that song stuck in my head.)

So far in this series, we've seen what COM Interop is, what it's used for, and why we might want to tackle the job of writing interop code on our own. Before we can get started, though, we need to understand a little bit about the inner workings of interop. The whole process relies very much on everyone knowing and following the rules; if you do, things work great. If you don't, you end up with nearly impossible-to-troubleshoot bugs. The CLR tries to shield you from as much of this as possible, but as always, knowing what's going on is better than flying blind.

COM Interop Part 2: Interop The Easy Way

Last time we got a brief introduction to interop, and in particular COM Interop, and why we might need to use it. The idea of using C# to talk to a non-C# application sounds like it could be a lot of work, and rife with potential bugs. Mostly because it is. Once you leave the safe, cozy confines of a managed environment, we open ourselves up to all kind of errors that managed code left behind a long time ago. Fear not: avoiding these errors is a simple (!) matter of understanding the rules of interop, and following them religiously.

COM Interop Part 1: An Intro to Interop

For those of you who are unaware, I spend most of my time at my $DAYJOB developing software in C#. Managed code is awesome for oh so many reasons, which I won't get into here, but there is one serious drawback when it comes to writing Windows applications in C#: Windows itself is not written in managed code.

In other words, there's almost 20 years worth of existing Windows features, APIs, etc. just waiting for me to use them, and I can't talk to them from C#.

Of course, Microsoft knew this was going to be a problem.  Its a problem they have to deal with themselves, since large chunks of the .NET base class libraries are just exposing Windows features to managed code. So, built into the .NET Framework is the concept of unmanaged code interoperability, or "interop". This is the part of the Framework that allows existing, unmanaged code and new, managed code to cheerfully coexist, even in the same process.

Anyone got a copy of blogging for dummies?

Somehow my blog posts ended up out of order; I'm gonna try to fix it but apologies for anyone that got confused. (Also, it will probably look like 6 posts went up at the same time; oops.)