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.