The Glorious Monster

Fixing ESBT 2.0 Installation Script Errors on 64-Bit OS

2009-06-30T00:40:00.005-04:00

I mentioned in my last post that I got an error running installation scripts for ESB Toolkit 2.0 on my 64-bit Vista machine. Brendon Birdoes from Microsoft on the ESBT Forum pointed out the solution. To run scripts that require a 32-bit OS, use the 32-bit version of cmd.exe, which is at \Windows\SysWOW64\cmd.exe. Not only does that fix the problem I reported, but it also allows the script to call ExplorerOM, which can only run in 32-bit mode.

I had assumed that the Visual Studio 2008 Command Prompt (from Visual Studio Tools on the Start menu) is always 32-bit, even on 1 64-bit Vista machine. I assumed wrongly.

Running BizTalk ESB Toolkit 2.0 on Vista

2009-06-27T18:47:00.003-04:00

I've completed the installation and configuration of BizTalk ESB Toolkit 2.0 on my 64-bit Vista laptop. Aside from not having UDDI, Vista hasn't presented any problems yet. (Of course Microsoft claims not to have tested ESBT on Vista, so this installation is for development only.)

I ran into three main issues during the install:

1. Microsoft's late-breaking decision not to ship source code for the ESBT core components has led to some choppiness in the documentation. For instance the documentation neglects to mention that you need to unzip ESBSource.zip, and that you need to create a strong name key with sn.exe in the \Key folder. The documentation also tells you to install the management portal before you run the ESBT Configuration Wizard, which is backward. These and other documentation shortcomings are discussed by Saravana Kumar here.

2. I got an error running the ManagementPortal installation script:

The term 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com'
is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.
At C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.0\ESBSource\Source\Samples\Management Portal\Install\Scripts\Management_Install.ps1:19 char:3
+ &$ <<<< env:VS\devenv.com "$solutionPath\Samples\Management Portal\ESB.AlertService\ESB.AlertService.sln" /clean $buildType

This is because Management_Install.ps1 assumes that Visual Studio is located in the \Program Files folder, but on 64-bit Vista it's in \Program Files (x86). This may be the case on other 64-bit platforms too.

To fix, change line 12 of Management_Install.ps1 from

$env:VS="${env:ProgramFiles}\Microsoft Visual Studio 9.0\Common7\IDE"

to

$env:VS="${env:ProgramFiles(x86)}\Microsoft Visual Studio 9.0\Common7\IDE"

3. While trying to deploy the BAM definitions in Microsoft.BizTalk.ESB.BAM.Exceptions.xml, I got the BM.exe error, "OLE DB error: OLE DB or ODBC error: Cannot open database "BAMStarSchema" requested by the login. The login failed.; 42000." I found the solution on Henrik Olsson's blog here.

I must say that ESBT 2.0 is far less harrowing to install than was ESB Guidance 1.0, but it can still take up an afternoon the first time.

ESB Toolkit 2.0 Has A Surprise for Enterprise Library 4.1 Users

2009-06-26T15:46:00.006-04:00

I use Enterprise Library 4.1 in a number of apps, and I'm glad that ESB Toolkit 2.0 uses it too. But I'm not so glad about the way ESBT handles its EntLib configuration. It does something the EntLib documents expressly say you should not do: tamper with EntLib configuration settings in machine.config.

When you install ESBT the MSI adds the following to machine.config:

<configSections>
...
<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
...
</configSections>

...

<enterpriseLibrary.ConfigurationSource selectedSource="ESB File Configuration Source">
<sources>
<add name="ESB File Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35" filePath="C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.0\esb.config"/>
<add name="ESB SSO Configuration Source" type="Microsoft.Practices.ESB.SSOConfigurationProvider.SSOConfigurationSource, Microsoft.Practices.ESB.SSOConfigurationProvider, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" applicationName="ESB" description="ESB SSO Configuration" contactInfo="someone@microsoft.com" userGroupName="BizTalk Application Users" adminGroupName="BizTalk Server Administrators"/>
</sources>
</enterpriseLibrary.ConfigurationSource>

(On a 64-bit machine, this will happen in both 32-bit and 64-bit versions of machine.config.)

What this does is, it forces Enterprise Library to ignore your app.config and/or web.config files and look for configuration information exclusively in ESBT's default configuration source, which happens to be the file "C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.0\esb.config". Since you probably didn't put your EntLib configuration settings in esb.config, EntLib won't find your apps' configuration at all, and they will crash. For example, a call to DatabaseFactory.CreateDatabase("myDatabase") will throw "System.Configuration.ConfigurationErrorsException: The requested database myDatabase is not defined in configuration."

I posted this on Microsoft's ESBT Forum yesterday and got a prompt response that led to a solution. Enterprise Library still looks in your app./web.config first, so if you insert your own <enterpriseLibrary.ConfigurationSource> section there, Enterprise Library will honor it.

So in my web.config file I inserted the following:

<configSections>
...
<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
...
</configSections>

...

<enterpriseLibrary.ConfigurationSource selectedSource="Local File Configuration Source">
<sources>
<add name="Local File Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35" filePath="web.config"/>
</sources>
</enterpriseLibrary.ConfigurationSource>

This causes Enterprise Library to look for my app's configuration settings in my web.config file once again, and thus my app works as it did before ESBT came along.

I'm even thinking that it's always a good idea to put a <enterpriseLibrary.ConfigurationSource> in every config file that uses Enterprise Library, since you never know when some joker is going to pull the same stunt as ESBT in machine.config.

This is not a totally joyous solution though, because the Enterprise Library Configuration Editor tool seems not to understand that different <enterpriseLibrary.ConfigurationSource> sections can exist in machine.config and web.config at the same time, and so it complains when I try to use it to edit my web.config.

For more details you can read the whole ESBT Forum thread here.

Speaking on BizTalk at July 2009 Cleveland .NET SIG

2009-06-25T12:06:00.003-04:00

I'll be giving another talk on BizTalk at the Cleveland .NET SIG on July 14, 2009. The topic will be "Achieving Reliable Message Delivery with BizTalk". I'll cover techniques common to BizTalk 2006 R2 and BizTalk 2009, as well as a look at some features in the new BizTalk Enterprise Toolkit 2.0.

You can get more info and register here:

http://www.bennettadelson.com/Events.aspx

Fixing BizTalk ENTSSO Failure on Windows Vista

2009-06-07T16:42:00.004-04:00

I've been running BizTalk 2009 on my Windows Vista laptop, and suddenly today the Enterprise Single Sign-On Service stopped working. When I tried to start it manually, I got this error in the event log:

Could not create SSOSQL. To fix the problem, reinstall SSO or try 'regasm SSOSQL.dll' from a Visual Studio command prompt.
Error Code: 0x80131700

It turns out this error told me everything I needed to know -- except the location of SSOSQL.dll. Took me a little digging, but I found it here:

C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSQL.dll

So, navigating to that folder in the Visual Studio Commmand prompt and running 'regasm SSOSQL.dll' fixed it right up.

The only lingering mystery is why the DLL got unregistered in the first place. I'm suspicious of Visual Studio 2010 Beta 1, which I installed yesterday. But I've got no proof of that.

(And yes, I do install a lot of goodies on my laptop.)

Enhancing the BizTalk Mapper: How to Wrap XSLT in Custom Functoids

2009-04-21T12:48:00.004-04:00

I've published an article on this topic in the latest issue of BizTalk HotRod, the online magazine for BizTalk developers. It's at page 44.

http://biztalkhotrod.com/Documents/BizTalk_HotRod_Issue6_Q2_2009.pdf

In the article I describe a problem that's easy to solve using an Inline XSLT Call Template. Then I show how to turn the Inline XSLT Call Template into a custom functoid that can be deployed to the Mapper toolbox, so that developers with no XSLT knowledge can use it without seeing the script or writing any code.

BizTalk 2009 on my Laptop

2009-04-15T20:39:00.004-04:00

The RTM of BizTalk Server 2009 and installed it on my laptop. So far no problems! Imagine seeing BizTalk Administrative Console with glass!

Speaking on BizTalk ESB Guidance at MOCSDUG

2008-06-01T16:42:00.010-04:00

I'm going to give the June presentation to the Mid-Ohio Connected Systems Developers User Group (MOCSDUG) on "Introduction to the Microsoft ESB Guidance for BizTalk Server 2006 R2". The talk will be on Thursday, June 5, 2008 at 6:00 PM. You can see it in person or over the web via LiveMeeting.

The ESB Guidance gives you free, prebuilt components and services, complete with source code, that allow you to turn BizTalk into a true Enterprise Service Bus.

Here's some of what the ESB Guidance can do:

Discover and configure message endpoints at runtime
Discover and perform message transformations at runtime
Select which combination of services to execute, in what sequence, at runtime
Handle exceptions consistently from anywhere inside or outside BizTalk

Many of the cool things we're expecting in Oslo are available in the ESB Guidance right now. So come check it out!

The 30-Day PowerShell Diet

2008-05-22T01:05:00.007-04:00

Inspired by this example, I have resolved to go on a 30-day PowerShell diet. For 30 days I will not use the Windows command window. I will use PowerShell instead. It should hopefully take only a few days to get used to using PowerShell to do all the things I normally do in a command window, and then I can start learning all the cool extra things in PowerShell. If after 30 days I don't like it,then I will stop using PowerShell for good.

The first challenge to the beginner is getting hold of a copy. A quick search leads to the official Microsoft site, but unfortunately you can't download there without installing a Windows Genuine Advantage plug-in, which I avoid whenever possible. (Not that I'm a thief, but I consider WGA an intrusion of privacy.) Happily this site lets us take advantage of PowerShell downloading without any Genuine Advantage.

After the installation I had a shortcut to PowerShell on my Start menu, which I copied to my desktop and thence to my Quick Start tray. And then came the second challenge. I almost never run the plain vanilla command window; instead I run the Visual Studio command window, which pre-loads path and environment variables so I'll be ready to run devenv.exe, sn.exe, wsdl.exe, and the whole rest of the Visual Studio tools. The command window shortcut does this by running a batch file, which in VS2008 is called vcvarsall.bat. If you try passing the batch file as a startup parameter to PowerShell you'll get syntax errors which I'm too green to understand yet. Plus, if you make it work it won't help, because PowerShell will run the batch file in a separate process, so it won't affect PowerShell's own environment.

The solution is for the shortcut to run the batch file first, then launch PowerShell. And so I edited the shortcut's properties as follows:

Start in: %HOMEDRIVE%%HOMEPATH%
* this is the default

Target: %comspec% /k ""D:\Programs\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"" x86 && %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

And now I think I'm ready to live in PowerShell for the next 29 days.

WCF Security at Cleveland Day of .NET

2008-05-19T09:34:00.003-04:00

I want to say that Cleveland Day of .NET was terrific experience for me. Between the excellent presentations and the stimulating conversations, I learned a lot and had a great time. I won't try to list all the folks I should thank, 'cause I'd leave some out, but to everyone who helped put on the event, Thank You and Well Done!

I was gratified by the turnout at my presentation, on "WCF Security", especially considering that we started at 8:30 AM! A copy of the slides and the demo code is available from the Cleveland .NET SIG site. (I've discovered I can't upload the files directly to this blog. I don't pay anything to BlogSpot, so I guess I'm not in a position to complain.) I've also sent the material to DoDN and will post a link to it on their site as soon as it's available.

I've made a bunch of enhancements to the demo code. The service host now has five different endpoints, one for each demo scenario, and the test client calls all five in succession. The demo also includes the two scenarios that I didn't have time to show in the presentation. You're welcome to post comments here or contact me directly if you have any questions or suggestions. I'm also planning to write some more blog posts about WCF Security in coming weeks.

Speaking at Cleveland Day of .NET

2008-05-13T14:16:00.002-04:00

I've been added to the speakers lineup at Cleveland Day of .NET this Saturday, May 17. This is such a late-breaking development that it's not on the schedule yet, though it may be by the time you read this. My topic will be "WCF Security", not the sexiest but it might help you keep your job (certainly helped me keep mine).

And yes, it's been a while since I updated this blog! Stay tuned ...

Review: John Stockton Silverlight 2.0 Presentation

2008-04-23T20:23:00.003-04:00

Last night I got to the Cleveland C#/VB.NET SIG to hear John Stockton talk about Silverlight 2.0 Beta 1. Although this beta has only been out a few weeks, John has already written a couple of apps in it, which he demonstrated. The first demo was based on a POC John had written for an actual client in about 10 days. It took an XML file containing a description of a telephone switching system, and it drew a two-dimensional picture of the system. Drawing the picture seemed straitforward enough (they're just boxes stacked in racks), but each box was animated to display its specs when touched with the mouse. The second demo was an early iteration of the web page that will display events at Cleveland Day of .NET. I was a bit disturbed by that one because it said John and I would be the only presenters. (Fear not, that will change!)

Though he freely admits that he's still learning, John's experience playing with Silverlight 2.0 beta 1 from its day of release has made him already one of the world's top experts. I admired his willingness to get right to work with it, and he made it seem approachable to the rest of us.

I still have a lot of questions about how ready Silverlight is for prime time. (How's the security? How's it deal with latency, concurrency, message brokering? Is the cross-platform cross-browser story real? How far can you really get away from Javascript?) And of course a lot of that approachability we perceived is because it's .NET and we're .NET developers. But the fastest way to the answers is to try the stuff out, as John has done.

After the meeting a gang of 16 or so escaped to Winking Lizard, which appears to be a strong tradition with this SIG, although we're doing much more of it now in that other Cleveland .NET SIG that I chair. I enjoyed meeting new .NET developers as well as catching up with Sam and some Twitterati.

Overall a very enjoyable and informative geek night out.

Fixing BizTalk's WCF Message Contract Mix-Up, Part 3

2008-04-12T18:25:00.010-04:00

The final solution to the Message Contract Mix-Up doesn’t require you to define your own message contracts, but does require some tricks in both the operation contract and the BizTalk ports.

First, modify the operation contract by adding a MessageParameterAttribute to the argument and return type:

[OperationContract]
[return:MessageParameter(Name="OrderStatus")] PurchaseOrderStatus PlaceOrder([MessageParameter(Name="PurchaseOrder")]PurchaseOrder po);

MessageParameterAttribute lets you change the names that the parameter and return value will have in the SOAP body. The names need to be changed to “PurchaseOrder” and “OrderStatus” so BizTalk can associate the schemas PurchaseOrder.xsd and OrderStatus.xsd with those elements. (Without MessageParameterAttribute, WCF would force the names of the parameter and return value to be “po” and “PlaceOrderResult”, which mean nothing to BizTalk).

Now you need to modify the WCF adapter settings in the two-way receive location in BizTalk. For general instructions and screenshots illustrating the following steps see the BizTalk documentation here. Open the Messages tab of the WCF adapter. Under “Specify the source of the inboud BizTalk message body”, check the third radio button, “Path – content located by body path”. In the text box type an XPATH expression consisting of the name of your operation contract, followed by the name of your data contract schema:

/*[local-name()='PlaceOrder']/*[local-name()='PurchaseOrder']

Make sure the combo box below the text box, “Node encoding”, is set to XML.

The first element in the XPATH is actually the WCF-generated message contract, which has the same name as the operation contract (“PlaceOrder”). The following element is the name of the parameter inside the message contract, which we forced to be “PurchaseOrder” by applying the MessageParameterAttribute.

The consequence of these settings is that the WCF adapter will drill through the message contract and pass the PurchaseOrder element to BizTalk as the message body. Bingo!

Since this is a two-way port, we need to return a data contract back to the caller, and to do that we need to tell the WCF adapter how to wrap the data contract inside a message contract. To do that, go to the bottom half of the tab and check “Template – content specified by template.” In the text box below, be careful not to delete or change the bts-msg-body element that’s already there, since that represents the data contract part of the message. Instead, insert an XML element around the bts-msg-body to represent the message contract. The name of this element is the operation contract’s name plus the suffix “Response”, and it must include the correct XML namespace:

<PlaceOrderResponse xmlns="urn://MyCompany.Purchasing.1_0_0.com" >
<bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="xml" >
</PlaceOrderResponse >

If this were a one-way send port we would follow the same procedure.

The result is that BizTalk will send the return value to client wrapped inside the same message contract that WCF would have generated automatically if the service were hosted in a pure .NET application. Bingo Bingo!

So there you have three ways to solve the Message Contract Mix-Up with the BizTalk WCF adapters. If you’ve read all the way through this series, I surmise that you either find the subject fascinating, or you need to solve these problems as badly as I did.

Fixing BizTalk's WCF Message Contract Mix-Up, Part 2

2008-04-12T17:02:00.008-04:00

I know of three ways to fix the Message Contract Mix-Up discussed in the last post. The first two require changing the signatures of your operation contracts to replace the WCF-generated message contracts with message contracts you define yourself. (Perhaps you've read books or heard WCF experts who say you needn't bother defining message contracts except in the unusual case. Then I guess BizTalk is an unusual case, as you might have suspected.)

1. Change the operation contract’s parameter and return value to message contracts with IsWrapped = false, like this:

[ServiceContract(Namespace = "urn://MyCompany.Purchasing.1_0_0.com")]
public interface IPurchasing
{
[OperationContract]
OrderStatusMessage PlaceOrder(PurchaseOrderMessage message);
}

[MessageContract(IsWrapped=false)]
public class PurchaseOrderMessage
{
[MessageBodyMember(Namespace = "urn://MyCompany.Purchasing.1_0_0.com")]
public PurchaseOrder PurchaseOrder;
}

[MessageContract(IsWrapped=false)]
public class OrderStatusMessage
{
[MessageBodyMember(Namespace = "urn://MyCompany.Purchasing.1_0_0.com")]
public OrderStatus OrderStatus;
}

If you declare your own message contracts but set IsWrapped to false (the default is true), then WCF will not generate any message contract element in the SOAP message at all. Instead, WCF will place the field with the MessageBodyMember attribute – which happens to be your data contract, PurchaseOrder – directly at the root of the SOAP body. Thus the SOAP message received by BizTalk will have an element named PurchaseOrder at its message type. Bingo! The great thing about this solution is you don’t need to do anything special on the BizTalk side to make your WCF adapters behave as you originally expected.

2. Same as 1. above, except the message contracts have IsWrapped = true. This will make the message contracts visible in your SOAP bodies, but you'll control their content instead of WCF. Generate XSD schemas for the message contracts and put them in your BizTalk project. Write message maps to transform message contract schemas to and from data contract schemas. Use the message maps to transform message contracts into data contracts in your inbound ports and to transform data contracts into message contracts in your outbound ports.

This solution will increase the number of schemas and message maps you’ll maintain. But unlike the previous solution, this one makes the message structures consistent, whether you look at them from the perspective of the WCF contracts, the BizTalk schemas, or the actual SOAP messages on the wire.

3. If you can’t, or aren’t willing, to define your own message contracts, but you’re able to add some WCF attributes, you can work out a compromise that allows BizTalk to navigate through the WCF-generated message contracts without knowing all about their schemas. The final post in this series will explain how to do that.

Fixing BizTalk's WCF Message Contract Mix-Up, Part 1

2008-04-12T15:33:00.007-04:00

WCF developers often write OperationContracts that receive and return DataContracts, like so:

[ServiceContract(Namespace = "urn://MyCompany.Purchasing.1_0_0.com")]
public interface IPurchasing
{
[OperationContract]
OrderStatus PlaceOrder(PurchaseOrder po);
}

Suppose you implement this service in BizTalk using an orchestration. First you use a tool such as XSD.exe or SVCUtil.exe to generate XSD schemas for the PurchaseOrder and OrderStatus data contracts. You add these schemas to a BizTalk project, write an orchestration that receives a PurchaseOrder and returns an OrderStatus, and deploy the schemas and orchestration to BizTalk. Then you bind the orchestration’s receive-send port to a two-way receive location using a WCF adapter and the XmlReceive pipeline.

Your may be shocked to find that when a WCF client sends a message to BizTalk, an error occurs in the receive pipeline: “Finding the document specification by message type "urn://MyCompany.Purchasing.1_0_0.com #PlaceOrder" failed. Verify the schema deployed properly.”

It turns out that the SOAP body that your WCF client sent to BizTalk doesn’t begin with the PurchaseOrder data contract. Instead it begins with a message contract that the WCF client generated behind the scenes. The name of this message contract is “PlaceOrder”, i.e. the name of the operation. Inside that message contract is an element named “po” which contains the data exposed by the data contract. Thus although BizTalk expects to receive a message type named PurchaseOrder, there is no element named PurchaseOrder anywhere in the SOAP body!

There's a symmetrical problem at the other end, when the two-way receive port tries to return an OrderStatus to the caller. If the service were hosted in a .NET application, WCF would automatically generate a message contract element named PlaceOrderResponse and wrap it around the OrderStatus. But BizTalk by default will do no such thing.

I call this impedence mismatch the "BizTalk WCF Message Contract Mix-Up". But so much for lingo, how do you fix it? I can suggest three solutions, each with its pros and cons. I’ll discuss them in the next post.

BizTalk WCF Adapters: OneWay to Nowhere

2008-04-12T14:29:00.004-04:00

Newcomers to the WCF Adapters in BizTalk Server 2006 R2 must be aware of two “gotchas” that they're likely to face when sending or receiving WCF messages with the adapters.

The first gotcha is that the IsOneWay property of operation contracts must be false. Luckily IsOneWay is false by default, but developers sometimes set it to true in an attempt to improve performance.

But the BizTalk WCF adapters always set IsOneWay to false, and so will fail whenever sending to or receiving from a client or service that has IsOneWay = true. (There’s an exception for the NetMsmq adapter.) Details about the errors you’ll receive are in the BizTalk documentation here.

The simple solution is to set IsOneWay back to false on your client or service. If you’re able to do that, the problem goes straight away.

If not – if for instance you lack authority to change the service contract – then you’ll have to put a wrapper service between BizTalk and the real service which, you guessed it, has the same WCF contracts as the real service except that IsOneWay is always false. This can be a pain, though it’s not hard to understand what you’re doing.

The second gotcha requires some deeper knowledge of WCF, so I’ll save it for the next post.

BizTalk Slides and Demos

2008-04-11T19:53:00.002-04:00

The slides and demos from my Intelligent Programmer's Guide to BizTalk presentation are here.

Painless SSL On Your Desktop

2008-03-28T22:12:00.000-04:00

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

2008-03-12T10:19:00.000-04:00

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

2008-03-07T10:02:00.000-05:00

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

2008-03-05T22:28:00.001-05:00

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

2008-03-03T12:45:00.001-05:00

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

2008-03-03T00:25:00.000-05:00

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

2008-03-02T21:23:00.000-05:00

"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.