Error:  Failed to update binding information. (mscorlib)

Object reference not set to an instance of object (Microsoft.BizTalk.ExplorerOM)

This happened when I created a new empty application.  It took a binding file, i.e. “a feed” from another app, exported it, changed the environment names, and re-imported it.

The problem was that the binding used maps and pipelines from another app.  There was nothing wrong with the binding file.  The way to get around the error was to add a reference in the new app to the old app that contains the maps and pipelines.

BizTalk Admin Console - Could not Create the Snap-In MMC

There might be many reasons for the above error, but here’s one we couldn’t find anywhere else.   We had a licensed copy of Windows 2008/R2, then realized we could save a license and use our MSDN subscription on this developer virtual machine.  So my worker upgrade to the Enterprise Developer edition.  That seemed to mess with BizTalk’s registry settings.  The secret to fix the above error for us was to run the BizTalk install and select the “repair” option.

 

 

 

I was at a new client, trying to run a Powershell to help build my BizTalk binding files for the BizTalk Deployment Framework,
and I got this error:

PS C:developmentAllProjects.Deployment> .GenerateMasterBindingsFromLocal.ps1
File C:developmentAllProjects.DeploymentGenerateMasterBindingsFromLocal.ps1 cannot be loaded because the execution o
f scripts is disabled on this system. Please see "get-help about_signing" for more details.
At line:1 char:38
+ .GenerateMasterBindingsFromLocal.ps1 <<<< + CategoryInfo : NotSpecified: (:) [], PSSecurityException + FullyQualifiedErrorId : RuntimeException

At first, I thought maybe the issue was a Group Policy, but it wasn't. You just need to run the command below, however, it does update the registry, so if you are not running as Administrator, you get this error:

PS C:developmentAllProjects.Deployment> set-executionpolicy remotesigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution
policy?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
Set-ExecutionPolicy : Access to the registry key 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft
.PowerShell' is denied.
At line:1 char:20
+ set-executionpolicy <<<< remotesigned + CategoryInfo : NotSpecified: (:) [Set-ExecutionPolicy], UnauthorizedAccessException + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetExecutionPolicyComma nd

When you open Powershell as Admin, then run the same command, it runs and looks like this:

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution
policy?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y

Got this error when importing a series of 5 SendPorts into a newly created BizTalk application:

Failed to update binding information. (mscorlib).
Additional Information:
Object reference not set to an instance of an object. (Microsoft.BizTalk.ExplorerOM).

My solution was that I needed to make a reference from the new application, to an existing application, which contained schemas, maps, etc.. used by these send ports. Basically, one of our developers needed a copy of the send ports to post data to the DEV database; so I exported my binding files, deleted everything except the 5 SQL SendPorts, then tried to import them into a new application to keep them separate.

We have several deployment scripts that have to run on both 32-bit and 64-bit environments. Until now, we just modified the script with a “replace all’ command for the 64-bit, which had to use “C:Program Files (x86)” instead of the traditional “C:Program Files” directory.

This was my first attempt:

set BTDFProgFiles="%programfiles(x86)%"
if %BTDFProgFiles%=="" set BTDFProgFiles="%programfiles%"
echo BTDFProgFiles=%BTDFProgFiles%

rem Then run the desired program 
%BTDFMSBuildPath% "%BTDFProgFiles%ABC.Common%2DeploymentABC.Common.BizTalk.Deployment.btdfproj"  /p:%PARMS% /l:FileLogger,Microsoft.Build.Engine;logfile="%BTDFProgFiles%ABC.EC.Common%2DeployResults

Then later, I was finding the quotes weren’t working, so this was the fix:

@ECHO OFF
setlocal EnableDelayedExpansion 
IF (%1) ==() GOTO NOPARM1 
IF (%2) ==() GOTO NOPARM2 

IF EXIST "%windir%Microsoft.NETFrameworkv3.5MSBuild.exe" (
SET BTDFMSBuildPath="%windir%Microsoft.NETFrameworkv3.5MSBuild.exe"
) ELSE IF EXIST "%windir%Microsoft.NETFrameworkv2.0.50727MSBuild.exe" (
SET BTDFMSBuildPath="%windir%Microsoft.NETFrameworkv2.0.50727MSBuild.exe"
)
@echo on 
set "BTDFProgFiles=%programfiles(x86)%"
if "%BTDFProgFiles%"=="" set "BTDFProgFiles=%programfiles%"
echo BTDFProgFiles=%BTDFProgFiles%

rem Then run the desired program 
%BTDFMSBuildPath% "%BTDFProgFiles%ABC.Common%2DeploymentABC.Common.BizTalk.Deployment.btdfproj"  /p:%PARMS% /l:FileLogger,Microsoft.Build.Engine;logfile="%BTDFProgFiles%ABC.EC.Common%2DeployResultsDeployResults.txt" 

NOTE: This was in conjunction with a wrapper script to run a series of BTDF (BizTalk Deployment Framework) scripts to deploy about 8 apps in one script.

I don’t think I ever even tried the left and right arrows in BizTalk Admin Console until this week.  A voice called to may saying “click me”, “click me”.

Left and Right Arrows at top of BizTalk Admin Console

BizTalk Admin console can be notoriously slow; sometimes I keep two of them open, one to restart host instances, and the other to deal with applications, send ports, and receive locations.

But for example, if you wanted to bop back and forth between host instances and an application, you could use the left and right arrows.

Try it, you’ll like it.

BizTalk itself can be installed and configured in about an hour if everything goes well.

If you are starting from scatch however, you should probably allow at least one full work day. By this, I mean you build a Virtual PC or a new machine and install all the prerequisites.

Here is a list of things I installed on a new Virtual PC, in preparation for creating a new WCF/BizTalk course:

  1. Windows 2003 – about 1.5 hours
  2. Windows 2003 SP2 – about an hour
  3. SQL 2005 – about an hour
  4. SQL 2005 SP3 – about an hour
  5. Visual Studio 2005 – about an hour
  6. Visual Studio 2005 SP1 – about an hour
  7. Visual Studio 2008 – about an hour
  8. Visual Studio 2008 SP1 – about 1.5 hours
  9. Create userids and groups before BizTalk Install – about 10 minutes
  10. BizTalk 2006 R2 – about an hour

It all adds up fast. All the above take about 10 hours, but you can be doing other things while all the installs are running.

I did the above on a 500 GB USB drive, so it might actually run faster on a real machine, local disk, non-virtual.
I did not include SharePoint or MOSS on the above install. The time above also excludes the time to install Office (Excel and Infopath – needed for BAM and Trading Partner Management).

Neal Walters
March 6, 2009

BizTalk Server 2006 is not available or configured. Verify BizTalk Server 2006 on server xxxxx using management database BizTalkMgmtDb is accessible and configured with a compatible version.


This frequently occurs in the company I’m working. All development is done on VMWare virtual machines, when the systems guys do a backup of VMWare “LabManager”, the virtual machine are shutdown and then restarted. For some odd reason, after the restart, SQL frequently does not start (even though it is set as “automatic start”.

To solve the problem, go to System Services, and if SQL is not started, then start it.