Painless SSL On Your Desktop

I was developing a WCF solution that called for UserNameOverTransport authentication. "OverTransport" meant using SSL. Since I'm a coding/architect kind of guy, I had to dig around to find out how to get an X509 certificate installed in my local IIS so I could run SSL on it.

Creating a certificate is easy with makecert.exe, a utility that comes with the Visual Studio SDK. Getting one that works is another matter. By "works" I mean (1) you can install the certificate in IIS, (2) it will be fully trusted by WCF, and (3) you can use it with URLs containing "localhost" without hearing grief about the certificate being issued to a different name.

The keys to success turn out to be (i) installing a ginned-up "authority" into the Trusted Root Certificate Authorities store, and (2) installing a certificate issued by that "authority", in the name of "localhost", into your Personal store.

Getting makecert.exe to do these things requires a lot of fancy parameters. This fine blog post by Michael Howard explains most of what you need to do. The only shortcoming of Howard's otherwise excellent instructions is that he installs the issuer's certificate into the Personal store instead of into Trusted Root Certificate Authorities, and thus WCF won't trust it. To fix that I changed the -ss parameter from "MY" to "ROOT".

Here is text of the batch file I used to create my fully SSL-ready certificate:

@echo off

makecert.exe -r -pe -n "CN=Acme Test And Dev Root Authority" -ss ROOT -sr LocalMachine -a sha1 -sky signature "Acme Test And Dev Root Authority.cer"

makecert -pe -n "CN=localhost" -ss MY -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Acme Test And Dev Root Authority" -is ROOT -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 localhost.cer

Once the batch file ran, I opened the IIS Admin Console and configured Default Web Site to use the certificate named "localhost" for SSL. Et voila, I can use any address on my local machine beginning with https://localhost/..., and it transports over SSL!

BIzTalk Presentation at the Cleveland .NET SIG

Next month I'm going to give a presentation to the Cleveland .NET SIG titled "The Intelligent Programmer's Guide to BizTalk". This will be geared to the BizTalk novice and will answer the question, "What can I do with BizTalk?" I'll have time for three demonstrations, which I'm currently planning to cover (1) how to set up decoupled publish/subscribe communication, (2) how to manage long-running transactions, and (2) how to achieve massive performance scalability.

I'd welcome anybody's suggestions of things they like included.

The meeting will be Tuesday, April 8, at 5:45. Directions and other info here.

... Which Sometimes Splits Too Fine

Then there are little gotchas in C++/CLI that just go to show how tough it is to get everything smoothed out in such a complex product.

• You can strong name your assemblies, but you'll get a runtime exception if you do it the way you're used to, in the AssemblyInfo file. Instead you must use a linker switch.
• Visual Studio won't automatically rename and copy an app.config file for you. You have to write a custom build event.
• IntelliSense is brittle and feeble, like C# was in VS 2002. It's comforting that the C++ Team plans to re-architect this feature in the next big release.

Perhaps my hordes of readers would like to post their own favorite glitches.

C++ fans are fond of sports car metaphores, and it's certainly not always built for comfort!

The Split-Brain Language

In C++/CLI we have the merging of two nearly opposite things:

• C++, a language designed to generate unmanaged code. It offers nearly unlimited run-time access to hardware, operating system and drivers, but almost no run-time access to the program's own type system.


• CLI, a managed runtime. It offers only limited access to hardware, OS and drivers, but rich access to the program's type system at run-time.

C++/CLI is a language that can write both managed or unmanaged code. We'll leave aside for now whether mixing managed and unmanaged code is something we'd like to do, and just look at how well C++/CLI supports managed code. (We can force the compiler to produce a 100% managed assembly using the /clr:safe switch.)

There's no doubt that the unmanaged legacy of C++ makes some things more awkward, or at least more verbose, than they are in all-managed languages like C#. For instance, in C++/CLI you can't use the traditional C-ish syntax to declare a managed array, as you can in C#. That's because in C++ the C-style syntax is reserved for unmanaged arrays; so if you want a managed array you must explicitly invoke the managed type:

int[] someInts = {1,2,3}; // declares a managed array in C# but an unmanaged array in C++/CLI

array^ someInts = {1,2,3}; // what C++/CLI requires

Then there are time-honored C++ restrictions that, however necessary in the early 1970's, are useless today. For instance, the C++ compiler insists on reading a source file from top to bottom.

ref class A { B^ _b; }; // error: compiler can't find definition of B, even though it's on the next line
ref class B {};

And so the programmer resorts to a forward declaration, just to make the compiler shut up:

ref class B; // declares B but doesn't define it
ref class A { B^ _b; }; // compiler willing to be patient now
ref class B {}; // definition of B

In the next post I'll look at whether the unmanaged legacy of C++ can help us (or force us) to write better managed code.

Another Monster

I now learn that there's a contemporary band out there named "Glorious Monster". According to this review their music is "moody, electro-pop", and includes the lyric: “Am I a brain / Or is my brain me / Consciousness or biology?” I gotta love that, must give them a listen.

C++ as a Domain Modelling Language

In Object Thinking David West says that C++ "inhibits the direct expression of application designs in any domain except that of the computer itself". In other words, C++ is great if you need to be intensely aware of the machine, but if you need to model a domain outside the machine -- say, an order entry system -- then C++ inhibits you. He doesn't spell out what's so inhibiting about it, but no doubt he's thinking of the complexity of the language.

When COM was king, Visual C++ was the only Microsoft language that let you really understand how COM worked and fully exploit what COM could do. A lot of us who struggled to program COM in C++ fancied we could design better programs in C++ than in Visual Basic. But did the ability to express COM better bring along the power to express the problem domain better?

I am going to argue on this blog that C++, whether in its traditional unmanaged form or in .NET C++/CLI, is as strong a language for domain modelling as any other, and I'll try and show that it is actually stronger than simpler languages like C# and Java. If that succeeds, then C++ will have a legitimate claim to being the best language (still) for all-purpose programming.

Perhaps I'll not succeed in persuading you, or even myself. But to find out, I (and perhaps you) will need to start attempting to use C++ to accomplish the same sorts of programming tasks that we now do in our "day job" languages (C#, in my case). Now that nothing forces me to use C++, it will take some extra effort to find out if I want to use it.

The Title

"The Glorious Monster" is the title of an all-percussion piece by Max Roach. He composed it for his 8-man drumming ensemble, MBoom!, and it appears on MBoom!'s first album. It is notable for featured solos on xylophone, vibraphone and orchestral tom-toms.

"The Glorious Monster" was, for a long time, my pet nickname for my favorite and most dreaded progamming language, C++. The name has a sense of dread and delight, no?

And now I also apply that name to my favorite and most dreaded server technology, Microsoft BizTalk Server 2006 R2.

So this is going to be a blog about programming and software design, but maybe with some music thrown in. Let C++, BizTalk and Max Roach be the blog's xylophone, vibraphone and tom-toms.