Jeez

• Pipeline components - put them in a folder


• Functoids - put them in a folder and gac em [sometimes]


• Everything else - gac it and deploy it

why?

BizTalk file dumping utility is no more

Charles Young - despite being not your average joe, knows when to admit his code is redundant. Looks like you can get Visual Studio to show you the temporary files used when creating BizTalk artifacts without an extra tool:
BizTalk Server 2004: Generating C# source files

NB: This only seems to work when the artifact compiles...

BizTalk Server 2004 Content Based Routing (CBR) and Quotation Marks

This: BizTalk Server 2004 Content Based Routing (CBR) and Quotation Marks came up the other day, although I had it the wrong way round:

SendPort Filters = no quotation marks for string values

Receive Shape Filters (in Orchestration) = quotation marks for string values.

Failed to retreive [sic] the basic properties of the Pipeline component: 'xxx'

I wanted to provide a character encoding property on a pipeline component, so that the developer using the component could select the appropriate encoding that the incoming and outgoing stream should use. Having seen a similar property in the flat file assembler, I cracked open reflector and pointed it at ffasm.dll. The TargetCharset property is typed for a class called "CharsetList", which is basically just a class that takes a codepage and the name of the charset and is marked with the following attributes

[Serializable, Editor(typeof(CharsetPropertyEditor), typeof(UITypeEditor))]
public class CharsetList


Also defined is the class CharsetPropertyEditor : UITypeEditor. This has a DrawItem method that produces the nice dropdown list of available character sets. In the same assembly there appears to be a similar affair for the schema selection list you've seen a million times, so I'll be stealing that when the need arises.

So, I created the property, typed it for CharsetList (which lives in Microsoft.BizTalk.Component.Utilities), added code to persist the field in the propertybag, deployed the pipeline component, but everytime I used it in a pipeline, and tried to save the pipeline, vstudio pipes up with the above error.

After a bit of digging, the answer was obvious. CharsetList doesn't implement IPersistPropertyBag - I'm so used to expecting everything to work for me when I see [Serializable] that I forgot about the plumbing of this old ActiveX interface. The code to persist the charsetlist now looks like:


Object charSetName = ReadPropertyBag(pb, "charSetName");
Object charSetCodePage = ReadPropertyBag(pb, "charSetCodePage");
if (charSetName != null && charSetCodePage != null && (int)charSetCodePage != 0) CharSet = new CharsetList((string)charSetName, (int)charSetCodePage);


So I just sidestepped the issue and persisted the two fields in the object seperately. You could also inherit from charsetlist and implement IPersistPropertybag.

Out of Memory Errors on Enlisting Orchestrations

[Note - this issue has now been addressed]

Having added a number of orchestrations to my orchestration project, I started getting a variety of out of memory errors when enlisting orchestrations using WMI:

"Exception of type System.OutOfMemoryException was thrown.(HRESULT: 80131600)."

"External component has thrown an exception.(HRESULT: 80131600).

BizTalk Server cannot access SQL server. This could be due to
one of the following reasons:
1. Access permissions have been denied to the current user. ..."

"An SEHException exception occurred while the XLANG/s runtime enlisted a
service.
Error message:External component has thrown an exception.
Call stack: at Microsoft.BizTalk.MetaDataOM.ICLRType.GetFields(UInt32
dwBindingFlags)..."


I applied Lee Graber's suggestion of increasing the amount of memory available to WMI using the following script:

var locator = WScript.CreateObject ("WbemScripting.SWbemLocator");
var wmi = locator.ConnectServer ("", "root");
var quota = wmi.Get ("__providerhostquotaconfiguration=@");
quota.MemoryPerHost = 384*1024*1024;


But this just gave me GPF errors gpf faults from wmiprvse.exe.

Finally, I found splitting the orchestrations into tiers, in seperate projects greatly lessened the problem as it decreases the amount of memory required to enlist the orchestrations in an assembly - the problems still occured but far less frequently. still, wmiprvse is using hundreds of megabytes of RAM to enlist an orchestration what is it doing?