Back to Biz

As my readers (Hi Mom!) know, I haven't posted in a long time. But like BizTalk I didn't go away. You will see some hopefully interesting things here soon.

Fixing ESBT 2.0 Installation Script Errors on 64-Bit OS

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

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

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

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

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

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.