Practicing .NET

Improving developer productivity and software quality

August 2006

So a couple of entries ago I mentioned I was in the midst of some work on a project when I needed to ensure that a legacy 3rd party COM component would be available for my .NET 2.0 application while retaining an XCOPY style deployment!

How so you say?

Recall from the murky, oh-so-glad-it's-over past that COM components are creatable by CoCreateInstance via a unique identifier (GUID) that has been previously installed into the registry. Many developers who've worked with COM have probably hand-registered a COM component by running regsvr32.exe from the command line shell. It runs and in a couple of seconds displays a friendly message that (if all went well) the component is now registered.

Fewer have actually taken the time to ponder just exactly what regsvr32.exe does. Does it have mystical knowledge of every COM component to know what COM objects it contains and how to properly register them? Fortunately, no, it doesn't. The process to register a COM component is amazingly simple. So simple in fact, we can do the same thing ourselves without resorting to regsvr32.exe.

Every COM component is required to export a standard 'C' function entry point named DllRegisterServer that takes zero parameters. This function is expected to perform any and all registrations that the COM component in question requires. Typically, the vendor writes this function as part of creating the COM objects in the component and many support libraries such as Microsoft ATL automate a great deal of the steps.

Now, if we were writing this as native code in something like C++ or 'C', we'd need to do the following:

1. Call LoadLibrary on the COM component (typically a DLL)
2. Call GetProcAddress(HandleToDll,"DllRegisterServer")
3. Call the function pointer we get back from GetProcAddress

Since languages such as 'C' and C++ support function pointers, this is trivial to implement and works like a charm.

So we advance to the .NET world and find ourselves using the latest evolution of the 'C' dialect family namely C#. C# is one awesome, totally cool and very productive language. But it was designed for the managed world, not the unmanaged/native one that came before. And one of the "features" of the 'C' family that was dropped was the notion of function pointers. 99% of the time, you'd never notice as you happily use a managed variant called delegates. But when working with Native Interop in .NET (like when calling ancient 'C' functions), the lack of function pointers really shows up. And boy does it hurt.

Try as we might, there's no way to force a function pointer out of C#. And no, it's not on Anders' crib sheet for C# 3.0. Now, some might say, "No problem-o, I'll just spike a 'C' DLL that does the call and DllImport that 'C' function into my C# code. Let that 'C' function call the other 'C' function". Hmmm. Works yes, Cool not very.

Hanging on the edge?

Have to wait until next post to find out the finale on this one. Show some code too.

Posted by Mark M. Baker at 11:22 PM  Permalink |

Sweet! Got an email today that Juval Lowy's iDesign group is teaming up with CMP Media (parent of DDJ) to hold a .NET 3.0 2006 Roadshow in cities around the U.S. If things go well, they are looking at more cities in other countries.

Speakers include the who's-who of the .NET world - Juval, Michele Leroux Bustamante, Brian Noyes. These are the people Microsoft turns to when they need advice on the design and architecture of leading edge .NET technologies such as WCF, WPF, C#, etc. Juval is also a .NET "legend" - a designation by Microsoft for someone who has made exceptional contributions to .NET.

I've had the good fortune to interview Juval and Brian for episodes on my podcast for CMP called .NET Cast (you can find the feed here). Amazingly bright and insightful not just in the mechanics of the technology but in the larger sphere of best practices. If you're going to spend some $$$ on a conference, you want to be sure you are listening to people who are really on the inside. These people are it.

Lucky for me, one city they're coming to is about 15 minutes from my house. So I'm definitely going. Oh yea.

Mark.. it.. on.. your.. calendar.

Ciao..

Posted by Mark M. Baker at 10:43 PM  Permalink |

I ran into an issue today on a product my team is developing due to a limitation in C#. Some may say it's a feature not a limitation. Like the fact that Java at one time didn't have enums. But I digress.

The ability to XCOPY a .NET application to a new computer along with its dependent binaries, and just run it is one of the coolest aspects of .NET. Especially given the experiences we've all had with older native technologies like C++ and COM. COM in fact, is the issue in my case.

Now, .NET can work with COM components just fine. A little COM Interop via a wrapper generated by VS.NET 2005 when it's added to a project, and voila! you're in business. Looks and feels just like a managed .NET object and not a native one.

There's only one problem.

To use a .NET COM Interop wrapper, the COM component has to be registered. When you create an instance of the COM Interop wrapper class, it actually does some magic and creates an instance of the underlying COM object. To do that, it has to do the same things that any native C++ application had to - namely use CoCreateInstance to ask Windows to look up information about the object in the registry and then create it.

No issues yet.

Of course, this depends on the COM component being registered - that is, having its entries added to the HKEY_CLASSES area of the registry. Normally this happens by using REGSVR32.EXE that comes with Windows to ask the component to register. In C++, it would have been snap also - a call to LoadLibrary, GetProcAddress and FreeLibrary would have sufficed. Asking GetProcAddress to fetch the function DllRegisterServer and then calling that function would have the COM component do its thing to register itself. Basically how all COM components manage this.

Back to the XCOPY intersection.

When copying files to a new computer, at what point does the COM component get registered? Answer - it doesn't. At least not automatically. My problem arose at this point since C# doesn't permit calling functions (event Interop ones) via a function pointer. It's that limitation, ..er feature thing again. After some head scratching, I wrote some code that registered my COM component on-demand and allowed me to keep my nice little XCOPY mode of deployment.

Next time I'll show you what I did.

And no, I didn't resort to C++ to do this.

Posted by Mark M. Baker at 05:05 PM  Permalink |

I mentioned before that I've been using the Microsoft Composite UI App Block (CAB) for 8 months now and it's one of the most impressive tookits ever to come out of Microsoft. It's version 1.0 and unlike the conventional wisdom that Microsoft needs three versions to get it right, CAB is right from the get-go. Likely a result of the intense use of Agile practices by that team.

That's not to say that I haven't seen places where it can improve. Not the "I have this special need to override some down in the weeds behavior" kind of thing, but something that hits anyone who uses CAB (and its cousin SC-SF) - performance lag due to ObjectBuilder reflecting through assemblies looking for its attributes each time an application starts.

Interestingly enough the Mobile SC-SF team solved this problem with that variant of SC-SF. The solution they came up with is relevant to the Desktop variety also. Basically, scan the assemblies and build an XML profile of where the attributes are, but do this during a build cycle, not when an application starts up. Essentially build a cache of the data and re-use it.

Sounds like a v2.0 feature for the mainline CAB/SC-SF in my book.

Posted by Mark M. Baker at 11:35 PM  Permalink |

The busy beavers in the Microsoft Patterns & Practices group released the Mobile Smart Client Software Factory that you can find here.

If you're doing development for the Mobile platform,
Stop.
Right.
Now.

Go checkout this toolkit before you write another line of code. And bookmark the .NET Cast podcast RSS feed for an upcoming series of podcast episodes where my co-host and I interviewed Ed Jezierski, Architect on the Mobile SC-SF.

Adapted from the Desktop version of the Smart Client Software Factory, but wholly redeveloped in spots for the nuances of the Mobile platform, this toolkit will provide you a rich architecture to glue together your application.

I've been working hard with the Desktop variety since early in 2006, and I've been in close contact with members of the team in Redmond. Suffice to say, the P&P team is the jewel (in my mind) of leading edge development practices at Microsoft. They're so forward leaning, they're almost horizontal. To get a flavor of just how much disruption their Agile practices are causing at Microsoft, check out what Microsoft people are saying.

Posted by Mark M. Baker at 11:23 PM  Permalink |

My first blog entry for Dr. Dobbs comes alive tonight..

Thought long and hard about what to focus my wandering attention to as I get started and finally came to rest on an area that I've long had an affinity for - evolving software development into a craft based on best practices and expressive patterns.

I'm going to muse over what's going on in software development in .NET along these lines and where things are going for developers in general. I'm hugely enthusiastic about what Microsoft is doing in the Patterns & Practices group, and I've had the great fortune of interacting with many of the members of that team through my podcast for Dr. Dobbs called .NET Cast - speaking of which you can find the RSS feed here. I'll be spending a lot of time groking through their stuff as we move forward.

A friend of mine recently recounted to me how people who really get something at a deeper level than the average Joe (or Jane) get into an almost Zen-like level with it. They see the dimensions to the issue and more importantly how those dimensions interact while deducing the essence of relevant truth. I've seen it with my own eyes on various projects and I hope to leave you thinking and exploring along with me.

Let's get started...

Posted by Mark M. Baker at 10:32 PM  Permalink |

"Practicing .NET" will focus on technologies and practices aimed at improving developer productivity and software quality. Examples will include Agile development, patterns, refactoring, Smart Clients, Windows Communications Framework, and C# 3.0.

Posted by Mark M. Baker at 01:38 PM  Permalink |