Web service project name cannot exceed 61 characters!

I think I just figured out the problem I posted below. It turns out that the web service project name can't be longer than 61 characters. Therefore, the assembly's friendly name couldn't exceeds 61 characters for web servie dll. I took the default name

BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy

for the web service when I published it from the ws publishing wizard. It's 67 characters and it exceeds this arbitrary limit. I tried to create a dummy web service on my computer with the name

BancOfMercury_CurrencyLaunderingTechnology_DUI_GrabTheMoneySer

which failed to allow me to access it as well. The error reported by the fusion.exe is very deceiving. It pointed me to other directions when I troubleshoot the problem. I thought error is in the assembly probing process. FUSLOGVW says this:
LOG: Post-policy reference:

BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy, 
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
ERR: Setup failed with hr = 0x80131047.
ERR: Failed to complete setup of assembly (hr = 0x80131047). 
Probing terminated.

Anyway, I tried another dummy project with name

BancOfMercury_CurrencyLaunderingTechnology_DUI_GrabTheMoneySe
BancOfMercury_CurrencyLaunderingTechnology_DUI_GrabTheMoney

and it worked. There's no documentation states that we couldn't name web service project with a name more than 61 chars. It still perplexes me since microsoft uses a cut off to be 61 instead of 64 which is exactly 8 bytes.

0x80131047

I was able to publish the web service from the biztalk and the the web service project was generated successfully. I was able to compile the program okay as well. However, when I browse to the asmx page, I got this configuration error. So far I was not able to figure out why. I also enclosed the fusion output.

Server Error in '/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy' Application.

---

Configuration Error



Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: The given assembly name or codebase, 'BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy', was invalid.

Source Error:

Line 196: <add assembly="System.EnterpriseServices, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> Line 197: <add assembly="System.Web.Mobile, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> Line 198: <add assembly="*"/> Line 199: </assemblies> Line 200: </compilation>

Source File: c:\winnt\microsoft.net\framework\v1.1.4322\Config\machine.config    Line: 198


Assembly Load Trace: The following information can be helpful to determine why the assembly 'BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy' could not be loaded.

=== Pre-bind state information === LOG: DisplayName = BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy (Partial) LOG: Appbase = file:///c:/inetpub/wwwroot/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy LOG: Initial PrivatePath = bin Calling assembly : (Unknown). === LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Post-policy reference: BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET Files/bancofmercury.currencylaunderingtechnology.dui.orchestrations_proxy/a47ccba5/38832147/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy.DLL. LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET Files/bancofmercury.currencylaunderingtechnology.dui.orchestrations_proxy/a47ccba5/38832147/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy.DLL. LOG: Attempting download of new URL file:///c:/inetpub/wwwroot/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy/bin/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy.DLL. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Post-policy reference: BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

---

Version Information: Microsoft .NET Framework Version:1.1.4322.985; ASP.NET Version:1.1.4322.968




Here's the fusion output

*** Assembly Binder Log Entry  (12/30/2004 @ 5:40:59 PM) ***



The operation failed.

Bind result: hr = 0x80131047. No description available.



Assembly manager loaded from:  C:\WINNT\Microsoft.NET\Framework\v1.1.4322\fusion.dll

Running under executable  C:\WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_wp.exe

--- A detailed error log follows. 



=== Pre-bind state information ===

LOG: DisplayName = BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy

 (Partial)

LOG: Appbase = file:///c:/inetpub/wwwroot/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy

LOG: Initial PrivatePath = bin

LOG: Dynamic Base = C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\bancofmercury.currencylaunderingtechnology.dui.orchestrations_proxy\a47ccba5

LOG: Cache Base = C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\bancofmercury.currencylaunderingtechnology.dui.orchestrations_proxy\a47ccba5

LOG: AppName = 38832147

Calling assembly : (Unknown).

===



LOG: Processing DEVPATH.

LOG: DEVPATH is not set. Falling through to regular bind.

LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).

LOG: Post-policy reference: BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy

LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET Files/bancofmercury.currencylaunderingtechnology.dui.orchestrations_proxy/a47ccba5/38832147/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy.DLL.

LOG: Attempting download of new URL file:///C:/WINNT/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET Files/bancofmercury.currencylaunderingtechnology.dui.orchestrations_proxy/a47ccba5/38832147/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy.DLL.

LOG: Attempting download of new URL file:///c:/inetpub/wwwroot/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy/bin/BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy.DLL.

LOG: Assembly download was successful. Attempting setup of file: c:\inetpub\wwwroot\BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy\bin\BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy.DLL

LOG: Entering download cache setup phase.

LOG: A partially-specified assembly bind succeeded from the application directory.

LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).

LOG: Post-policy reference: BancOfMercury.CurrencyLaunderingTechnology.DUI.Orchestrations_Proxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

ERR: Setup failed with hr = 0x80131047.

ERR: Failed to complete setup of assembly (hr = 0x80131047). Probing terminated.

Create a New Message Inside an Orchestration Without using an External Component

BizTalk documentation states: "You construct a message any time that you introduce a message into your orchestration, either by receiving it or by assigning values to a message variable. ... You can invoke a .NET class to create a message, assign one message to another, or use a transform to map certain values within a message to values within another message. Messages are also constructed by a receive action or when your orchestration accepts a message as a parameter."

It basically says this: To create a new message, you have these options:

• Transform from an existing message


• Assign the variables of an existing message


• Assign an existing message or message part to the new message


• Use an external .NET component to construct a new message

Sometime you want to create a simple empty message to start with. This message doesn't have an instance yet. You don't have an existing message to do the message transformation. You don't want to use the external component since it introduces one more layer of complexity. Now what can you do? Looks like you ran out of the options. AMOF, you could easily construct a new message right inside the orchestration by following these steps:

• Add a System.Xml.XmlDocument variable to the documentation. Without losing generality, let's say its name is theXmlDoc


• Add a message assignment shape

In the expression shape of the assignment shape, enter the following:

theXmlDoc = new System.Xml.XmlDocument();
theXmlDoc.LoadXml("<root xmlns=\"http://www.namespace.org\" />");
newMessage = theXmlDoc;


The signature of the map file has changed, some arguments that you specify may not be valid.

Problem:
One of our developers run into this problem when using the Biztalk Mapper. We searched on internet and found out there's a guy had exact same problem on http://www.webservertalk.com. So I am saving my keystrokes and quote his message below:

I had mapping scenario in where I am having 3 input xml file and 1 output xml file, which I can easily specify in the mapping component in the orchestration. The problem is when it opens the mapper. It shows that it had 3 input documents but only shows fields of first input xml and the other two as empty. When I go back to the orchestration and try to click on the transform component it says that the signature of the map file has changed, some arguments that you specify may not be valid. I believe it is possible to have multiple input file and one output file, Am I missing something?.
Amit

Possible Solution:
I am pretty sure the problem you encountered is due to the namespace#rootElement collision. If you are using the same namespace for those 3 inbound xml documents and these documents also have the same root element, you will run into this problem exactly as you described. You need to make sure the definition of your xml namespaces will always allow BizTalk to derive a unique type. The simple solution to your problem could be:

1. use a dinstinct namespace name for each inbound document schema; or


2. use a distinct root element name in each schema.

One common scenario you will run into this problem is when you use the schemas generated by the SQL Adapters invoking the stored procedures. If you let the stored procedure to return "FOR XML RAW" and you have the same namespaces for these stored procedures generated schemas, then BizTalk mapper will not be able to import the rest of schemas since there's a type collision after importing the first schema. You will have these collisions if you define your namespace to be: http://mynamespace.


InputMessagePart_0: http://mynamespace#row
InputMessagePart_1: http://mynamespace#row
InputMessagePart_2: http://mynamespace#row


How to fix Project location not fully trusted by .Net runtime problem?

SOLUTION

1. Go to Settings | Control Panel | Admin Tools | .NET 1.1 Configuration


2. Drill to "Runtime Security Policy/Machine/Code Groups/All_Code"


3. Add a new code group with "_" separated name such as "CC_View_Group"


4. Click on the "Membership Condition" and choose "URL"


5. In the URL: text box, type in "file://V:/*"

The "SOAP" adapter is suspending an outbound message going to destination

Event Type:	Error

Event Source:	BizTalk Server 2004

Event Category:	BizTalk Server 2004 

Event ID:	5754

Date:		15/11/2004

Time:		15:24:02

User:		N/A

Computer:	B000E7F60EAA7

Description:

The "SOAP" adapter is suspending an outbound message going to 

destination URL:"/My.WebService/RetrieveCustomerInfo.asmx". 

Details:"Exception of type System.Runtime.InteropServices.COMException 

was thrown.". 

You just published an web service from your beautiful orchestration and you are expecting that your web service will work like a champ. Suddenly, you are stopped by this error and scratched your head several times trying to figure out what the h... is going on. You should reproduce the error and try to get more detailed exception context. Remember your could turn on the ThrowDetailedError in the web.config file to get more information about the exception.

  <appSettings>

   <add key="ThrowDetailedError" value="True" />

  </appSettings>

Once you turned on this switch, the exception you received from your client application should give you enough information to go about this exception. From my experience, the error is likely due to the transformation of the xml document to the objects in the message pipeline. For example, if you have an integer type element count in your outbound xml document instance you intend to map to a field or property of your object.

 <count>6.0</count>

The floating point number 6.0 will cause a conversion exception: System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info). This will eventually bubble up to throw the mysterious System.Web.Services.Protocols.SoapException.

You need also keep an eye on the possible number overflow. For example, if you have an element mapped to xs:integer which has a value that's not in the range of [-2147483648, 2147483647], you will receive this type of exception as well.

Got tired of running Deployment Wizard?

I found it is very annoying to run the BizTalk deployment wizard to deploy or undeploy the assemblies during development phase. Especially when you have multiple assemblies to deal with. You can actually write a simple batch file to automate the deploy/undeploy process. BizTalk provides a BTSDeploy.exe in the installation directory that can take various arguments to perform these tasks easily. The following code (undeploy.bat) is a very rough sample for the undeployment. The deployment step is just the opposite. In case you don't know how to find out the public key token of your assembly, you could use these commands: sn -T assembly.dll and sn -t keyfile.snk.

@echo off

SETLOCAL



::

:: Set the deploy environmental variables for App

::

SET server=dbserver

SET db=BizTalkMgmtDb

SET btsdir="C:\Program Files\Microsoft BizTalk Server 2004"

SET outdir=..\App\bin\Development

SET log=.\undeployapp.log



::

:: The following section could be repeated if mutiple assemblies

:: to be undeployed...

::

SET name=App

SET version=2.0.0.0

SET pkt=29068414d03ece02

SET culture=neutral



echo Undeploy %name% %version% from GAC and %db% on %server% ...

::

:: Perform undeployment; use BTSDeploy.exe

::

%btsdir%\BTSDeploy 

     REMOVE SERVER=%server% DATABASE=%db% 

     NAME=%name% VERSION=%version% CULTURE=%culture% 

     PUBLICKEYTOKEN=%pkt% UNINSTALL=True LOG=%log%



pause

The node to be inserted is from a different document context

Inside your message assignment shape, if you try to do :

Construct MsgB

{

    theXmlDoc.DocumentElement.AppendChild

    (

         xpath

        (

            MsgA,

            "//*[local-name()='someElement']"

        )

    );

    MsgB = theXmlDoc;

}

You will run into this error:

Event Type:	Error

Event Source:	XLANG/s

Event Category:	None

Event ID:	10034

Date:		10/27/2004

Time:		4:13:29 PM

User:		N/A

Computer:	B00D059B675E2

Description:

Uncaught exception terminated service A, instance B



The node to be inserted is from a different document context.

   

Exception type: ArgumentException

Source: System.Xml

Target Site: System.Xml.XmlNode AppendChild(System.Xml.XmlNode)

Help Link:

Additional error information:

SOLUTION: This is because the node to be copied belongs to another Xml document and is not recognized by the destination xml document. In order to make it work, you will need to import it first. If you read MSDN's documentation for the XmlNode.AppendChild() method, you will notice the following description:

...
If the node being inserted was created from another document, you can use XmlDocument.ImportNode to import the node to the current document. The imported node can then be inserted into the current document. ...

Therefore, all you need to do is to add XmlDocument.ImportNode() method in the message assignment expression editor:

Construct MsgB

{

    theXmlDoc.DocumentElement.AppendChild

    (

       theXmlDoc.ImportNode

       (

           xpath

           (

               MsgA,

               "//*[local-name()='someElement']"

           )

       )

    );

    MsgB = theXmlDoc;

}

Cannot retrieve list of objects due to a WMI provider failure. New transaction cannot enlist in the specified transaction coordinator.

Cannot retrieve list of objects due to a WMI provider failure. New transaction cannot enlist in the specified transaction coordinator.

This problem occurs when you run the BizTalk Server across the fire wall. Take a look at the following links:

KB 250367


KB 306843


KB 300083


Ports need to be opened

Windows Command Line Tricks

• Command Line Expansion:
  
  I am sure you like the command line expansion capability of csh, tcsh and bash in unix family of operating systems. You can have the same capability in Windows Command Line if you enable it. :-) You can use "tab" to expand the whole command line argument after you give a few starting characters. To enable this capability, set the following registry key value to 9.
  
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\PathCompletionChar

  


• Open File Explorer From cmd and Set Address to Current Working Directory:
  
  Developers constantly spend time in command line and sometime it is useful to start up the file explorer from the comand line environment. It will be very cool and save us a little bit time if the file explorer opened will point to the same working directory. You can do this easily with this command:
  C:\Program Files\Microsoft BizTalk Server 2004> explorer %cd%
  This command will open up a file explorer and take you to directory:
  C:\Program Files\Microsoft BizTalk Server 2004
  

The property 'TargetSite' on type 'System.Exception' cannot be serialized because it is decorated with declarative security permission attributes.

Detailed error:
The property 'TargetSite' on type 'System.Exception' cannot be serialized because it is decorated with declarative security permission attributes. Consider using imperative asserts or demands in the property accessors.

Solution: System.Exception object can not be serialized to transfer over the HTTP channel. Obviously, we need to provide some mechanism to serialize its state to some transferable medium like string. And on the other end, typically web service, we need to deserialize it back to the exception object.

I have a BaseException class that derives from System.Exception class. It has
a public property called "ExceptionState" that serializes it to Base64String representation. It also has a static method "Reconstruct" that reconstructs it from the Base64String back to the BaseException object.

public class BaseException : Exception, ISerializable

{



//...



string state; 

static BinaryFormatter binaryFormatter = new BinaryFormatter(); 



/// <summary>

/// Persiste BaseException object to the base 64 string. This property returns

/// a string representation of the exception state which could be used to 

/// reconstruct this exception if desired. <see cref="Reconstruct"/> method.

/// This property is introduced to fix the following issue: 

/// The property 'TargetSite' on type 'System.Exception' cannot be serialized 

/// because it is decorated with declarative security permission attributes. 

/// Consider using imperative asserts or demands in the property accessors.

/// </summary>

public string ExceptionState

{

    get

    {

	if (state == null)

	{

	    MemoryStream stream = new MemoryStream();

	    binaryFormatter.Serialize(stream, this); 

	    stream.Seek(0, SeekOrigin.Begin);

	    state = Convert.ToBase64String(stream.ToArray()); 

	}

	return this.state; 

    }

}



/// <summary>

/// Reconstructs a <c>BaseException</c> from the supplied exceptionState 

/// string. <see cref="ExceptionProperty"/> property comments. 

/// </summary>

/// <param name="exceptionState">

/// Base 64 string representation of the xception</param>

/// <returns>

/// A reconstructed <c>BaseException</c> object; null if reconstruction failed. 

/// </returns>

public static BaseException Reconstruct(string exceptionState)

{

   byte [] buffer = Convert.FromBase64String(exceptionState); 

   Stream stream = new MemoryStream(buffer, 0, buffer.Length, false); 

   stream.Seek(0, SeekOrigin.Begin); 

   object obj = binaryFormatter.Deserialize(stream); 

   return obj as BaseException; 

}

}

Scritping Functoid Catch

I experienced a problem when I was using the Inline XSLT inside the scripting functoid. I entered the XSLT first, then I scrolled the "Script type" dropdown to check out the template of "Inline C#". Then I clicked on the "OK" button without noticing that "Configure Functoid Scripts" dialog actually overwrites the the script type of my choice "Inline XSLT" with "Inline C#", even though your intention is to use XSLT. As a matter of fact, when you scroll the "Script type" dropdown to any other script types in front of the "Inline XSLT" inside the "Script type" dropdown, BizTalk will automatically uses the first available in the list even somtime it only has script in comments. When you compile your project, it will not signal error since all of the commented code, i.e. empty script, is considered valid by compiler. But when you run your orchestration, it will bomb. The solution is you need to rearrange the precedence of the inline scripts. To do this, right click inside of the map area; then go to the property window and bring up the "Script Type Precedence" dialog.

I would test any BizTalk mapper before I compile my projects. To do so, simply right click on your map file and select "Test map" from the context menu.

BizTalk Xml Links ...

• Import, Include or Redefine
  
  

  
  Even though you could use <xs:import> or <xs:include> to reuse existing schemas, I found that BizTalk having some proprietary processing for <xs:include>. It will copy the included schema verbatim whenever you place your <xs:include> node. Moreover, the schemas will also be included whenever they are referenced. Thus, you will have multi-rooted master schema if you use <xs:include>. I prefer to use the <xs:import> because it will maintain the single root in the master schema even you reference multiple existing external schemas.
  

  
  



• Assign messages



• Xml Namespace and XPATH



• Elements vs. Attributes



• IBM's When to use elements versus attributes

Yet another BizTalk Naming Guideline Recommendations

For all BizTalk orchestration shapes, I would recommend to call a shape with its name (or its shorthand) and suffix it with a succint description. This is only a recommendation. You don't have to follow this convention. The recommendation strives to promote a common set of guidelines.

...................................................................

              Shape  Short       Example

...................................................................

 Call Orchestration  CallOdx     CallOdx_AssembleReply

         Call Rules  CallRule    CallRule_LoanDecisioning

         Compensate  Compensate  Compensate_BadTransactions

  Construct Message  Mkmsg       Mkmsg_GetEntityParams

             Decide  Decide      Decide_ProcessBorrower

              Delay  Delay       Delay_OneHour

              Group  Grp         Grp_GetFirstEntity

             Listen  Listen      Listen_IncomingReq

               Loop  Loop        Loop_ProcessAllApplications

 Message Assignment  Assign      Assign_EntityMatchResultToReplyMsg

   Parallel Actions  Para        Para_GetMatchAndMkReply

              Port*  Port        Port_GetEntities

            Receive  Recv        Recv_AppReq

               Send  Send        Send_AppRep

Start Orchestration  Init        Init_PlaceOrder

            Suspend  Susp        Susp_CreditEvaluationOdx

          Terminate  Stop        Stop_CreditEvaluationOdx

    Throw Exception  Throw       Throw_UnknownReqException

          Transform  Xform       Xform_GetEntityParams

* Since orchestration's port name has nothing to do with the transfer protocol, the name should not contain the word like Soap, Http, File, etc.

This Assembler cannot retrieve document specification by using this type: "http://tempuri#request"

Event Type:	Error

Event Source:	BizTalk Server 2004

Event Category:	BizTalk Server 2004 

Event ID:	5720

Date:		14/10/2004

Time:		18:19:46

User:		N/A

Computer:	yourhost

Description:

There was a failure executing the send pipeline: 

"Microsoft.BizTalk.DefaultPipelines.XMLTransmit" 

Source: "XML assembler" 

Send Port: "SQL://server/db/" Reason: This Assembler cannot retrieve 

document specification by using this type: "http://tempuri#request".  

SOLUTIONS: This is noramlly caused by the failure of BizTalk's message engine to derive the unique type from the deployed Xml Schema. Type generated by the schema will have the format of "namespace#typename". For example, if you have defined your xmlns=http://myproject and you have an root element called item. The fully qualified element type derived by the BizTalk will be: http://myproject#item. So your responsibility is to make sure:

• Indeed you have this schema and desired root element defined


• You don't have two or more elements with the exact same name and same namespace deployed. This includes all schemas previously deployed to the BizTalkMgmtDb. You could find the Xml namespaces are saved in the bt_XmlShare and bt_XmlShareReference tables in the BizTalkMgmtDb

BizTalk: 'ActiveView.ColumnAxis' is null or not an object

HAT failed to run properly, it complains about the snap in. You need download Office 2000 Web Components:
download from here

A Microsoft Distributed Transaction Coordinator problem prevented connection to the Configuration database. Exception from HRESULT: 0x8004D00E

Follow these steps:

1. Make sure host and server can ping each other


2. Make sure DTC service is up and running


3. Check out kbid 839187
   SET HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\TurnOffRpcSecurity = 1


4. If your DEV BizTalk server is on a Windows XP box with SP2 installed, take a look at this article by Florin Lazar: XP SP2 and Transactions
   

BizTalk: Type "http://www.w3.org/2001/XMLSchema:char" is not declared or not a simple type

If you use the datatype char(1) in the stored procedure, it will bomb when you try to generate XML schema in the "add SQL adapter wizard".

It turns out to be a BizTalk bug. You can still use char(1) and it will just work fine after applying the following fix. By default, the schema returned by SQL XML is XDR (XML data Reduced). You can observe this from the Query Analyzer. This reduced schema is not used by BizTalk; BizTalk uses the xsd. BizTalk relies on the XDRToXSD.xslt to transfrom the xdr generated by SQL Server to the desired xsd format. There's a problem in the XDRToXSD.xslt (this file locates in "C:\Program Files\Microsoft BizTalk Server 2004\"). To fix this problem change the following line:

<xsl:template match="@dt:type[.='char']" mode="convert-datatype">xs:char</xsl:template>

to:

<xsl:template match="@dt:type[.='char']" mode="convert-datatype">xs:string</xsl:template>

Thus, char(1) or char will be mapped to a xs:string. Actually, the default http://www.w3.org/2001/XMLSchema namespace has no xs:char build-in type. If you look at the following picture of the build in XMLSchema type hierachy you will find there's no xs:char.

For details about the XMLSchema build in data type click here.