I had the Response Schema defined somewhere around the lines of this:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://BizTalk_Webservice_Publishing_issue.Schema2"
  xmlns:b="http://schemas.microsoft.com/BizTalk/2003"
  targetNamespace="http://BizTalk_Webservice_Publishing_issue.Schema2"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Root">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" name="Record">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="Field1" type="xs:string" />
              <xs:element name="Field2" type="xs:string" />
              <xs:element name="Field3" type="xs:string" />
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Looks sensible right? It compiles okay, I can make an Orchestration with a Request-Response port, everything looks fine, until the Web Service Publishing Wizard gives me:

Failed to create project http://localhost/BizTalk_Webservice_Publishing_issue_Proxy.
[Microsoft.BizTalk.WebServices.PublishingException] Failed to construct code for schema "http://BizTalk_Webservice_Publishing_issue.Schema2".
Method not found: System.String System.Xml.Serialization.XmlMapping.get_ElementName().

I didn’t get it, what was wrong? After searching the internet (in which I obviously found one of Patrick’s blogpost which didn’t help in this case as I had no imported schema’s) I began some experiments. I determined that the cause lies in the multiplicity on the Record element. It didn’t matter what values I used, as soon as the schema allowed more than one Record element to be a part of the message, the Wizard failed on me.

I don’t remember how I got the idea, but the solution is rather simple. It appears that the Wizard doesn’t like the multiplicity on the element. So, let’s put the multiplicity one level higher, around the element, like this:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://BizTalk_Webservice_Publishing_issue.Schema2"
  xmlns:b="http://schemas.microsoft.com/BizTalk/2003"
  targetNamespace="http://BizTalk_Webservice_Publishing_issue.Schema2"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Root">
    <xs:complexType>
      <xs:sequence>
        <xs:sequence minOccurs="0" maxOccurs="unbounded">
          <xs:element name="Record">
            <xs:complexType>
              <xs:sequence>
                <xs:element name="Field1" type="xs:string" />
                <xs:element name="Field2" type="xs:string" />
                <xs:element name="Field3" type="xs:string" />
              </xs:sequence>
            </xs:complexType>
          </xs:element>
        </xs:sequence>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

So after encapsulating the Record element in a Sequence on which I added the multiplicity, all was well. I don’t think I fully understand why the Wizard (or XSD.exe which is running the show in the background) fails on the first version, but now I do know how to solve this.

Update: fixed the formatting of the XML Schema’s for readability.

The TMP environment-variable
On the machine I’m currently using the TMP environment-variable was mapped to %userprofile%\local settings\temp and the UserProfile is redirected to a network-share. I changed the TMP environment-variable to a directory on the local drive. You can change this in a dialog which you can edit after pressing the Environment Variables button on the the Advanced tab of the System Properties which you get when selecting Properties from the context menu of My Computer.

The path to Microsoft.BizTalk.XLangView.dll
The documenter relies on forementioned dll. The path to this dll is configured in the Microsoft.Sdc.BiztalkDocumenter.exe.config file. When you’ve got a default install, the path to this dll is set correctly, but in my case BizTalk 2004 is installed on a non-default location, so I had to change this path. It was there right under my nose the whole time…