Jesse Anderson

We have a simple orchestration. It Receives and inbound XML file ("C:\Input\inbound.xml"), calls an ASMX web service (through a typical "Web reference"), and Sends the response message to disk ("C:\Output\{messageid}.xml"). Very typical.

Problem is, when we look at any given message being returned, either in the location of the Send port or through HAT message tracking, the XML is only partially there... that is, the web service's response type is a "custom .NET class" that includes 5 or 6 layers of "parent object-child collection-child object" hierarchy, and only the first couple layers of parents/children are being returned.

If I call the same service from a simple WinForm test harness, all the data is there, as is evidenced through the Watch window, i.e., it's able to recreate the entire response message as a .NET object instance (of the proxy classes), and it includes all levels of parent/children. So I don't think it's what the service is returning - I think it's what BizTalk is seeing (or not seeing.)

One thing I thought it might have something to do with is the fact that the "custom .NET class", the return type of the service method, does inherit from another class... problem with this theory is that the inherited properties are coming through just fine... it's the properties of the inheriting class that don't come through, of which there is exactly one, and it is a custom Type that inherits from "List<>".


Code Block

[DataContract(Namespace = "http://Xyz.DataContracts/2007/07", Name = "EnrollmentFeedDataContract")]

public partial class EnrollmentFeedDataContract : MemberDataContract


private Bop.DataContracts.FsaEnrollmentListDataContract FsaEnrollmentListField;

[DataMember(IsRequired = true, Name = "FsaEnrollmentList")]

public Bop.DataContracts.FsaEnrollmentListDataContract FsaEnrollmentList


get { return FsaEnrollmentListField; }

set { FsaEnrollmentListField = value; }



(FsaEnrollmentListDataContract is the type that inherits from "List<>", and in the resulting XML response, is the piece that is missing... the properties of MemberDataContract, not shown here, do come through in the XML. I don't actually think it has to do with the fact that it's a collection/list, as there is a simple DateTime property that also doesn't make it to BizTalk.)

(You'll notice the WCF attributes, though I've been talking about it as an ASMX web service. It started off as WCF, but we're using BizTalk without R2 and so I put an ASMX facade over the underlying functionality. Which works pretty well in every other way I've used it - just not in a BizTalk orchestration.)

Another wrinkle... After the "Send" to "C:\Output", which should output the raw XML received, I have another step in the orchestration to do a transform from the response schema to a different schema, and a simple "Send to disk" again. If I look in the Orchestration Debugger, the construct/transform and following steps are never performed. BizTalk never shows any errors for any of it.

It's all very strange to me. I've tried playing with schemas, updating the web reference, using System.Xml.* attributes on the properties (such as XmlElement (nullable=false) and so on, but haven't been able to get missing child elements to ever show up.

If anyone has any idea what I'm talking about and better yet has any idea what's going on here, your help is very much appreciated.


- Jesse

Re: BizTalk R2 General BizTalk message doesn't have all data returned by service

Jesse Anderson

Well, I'm not sure whether I'm an idiot or MS has reached a new level of incompetence.

It turns out that every time one makes a change within their Visual Studio BizTalk project, and deploys the solution (right-click on the solution > Deploy) to a *remote* BizTalk server, I have to manually copy and register (or re-register) the resulting DLL (from bin/Deployment under project) into the GAC on the remote BizTalk server. Apparently the Visual Studio deploy mechanism can do everything except this.

That was the problem above, I had an old DLL in the GAC on the BizTalk server.

If that's truly the case, it means MS expects you to have BizTalk server installed locally, or you have to come up with your own mechanism for updating the GAC on the BizTalk server, every time you do a compile & publish.

So now it's a different question... there must be better ways than doing this than remoting to the server, copying the file, dragging and dropping to the C:\WINDOWS\assembly folder, isn't there


- Jesse

Re: BizTalk R2 General BizTalk message doesn't have all data returned by service

Kent Weare

I have never tried to do this remotely, but it does simplify things when deploying to your local workstation.

How to Auto-GAC your BizTalk Helper Classes on a Successful Build

There is also a /u switch that will remove the old version of the assembly before the new assembly is Gac'd.

Re: BizTalk R2 General BizTalk message doesn't have all data returned by service

Francois Malgreve


The Visual Studio post-build event such installing an assembly in the GAC will only work for local machine. By that I mean install the library in the GAC of the local machine. I am sure that you know that, just want to point it out to avoid confusion Smile


I think that it is understandable that when deploying to a remote server, Visual Studio will not automatically copy any files on your remote server neither GAC it. It could bring all kind of security issues and would be prone to failing if the appropriate rights do not exist for you on the remote server. Honestly I do not really understand why we are even given the opportunity to deploy on remote machines. But I have to agree with you on the point that it should work if we are given the option!
But then you would need a domain controller, domain groups and domain users with sufficient rights and add extra complexity in the installation process of BizTalk Server on a DEV machine and on those remote servers you want to be able to remote deploy...
Well, as you know, MS likes to have all their product installable in a few clicks so that people can start to use it easily and rapidly... even at the cost of some non-sense like this one Stick out tongue

Anyway, to come back to your problem, the best practice is that if you develop from MachineA, it means that BizTalk is installed on MachineA. So really, from VS, you should deploy always and only to MachineA. Once your app is deployed to machineA, you can optionally unit-test it if needed and then export the application into an MSI file which will contains the dll of the BTS application. You then need to copy the MSI file onto the remote server and then import it in the BizTalk Server Admin console, it will also install the library of the BizTalk app in the GAC in the same time.

Francois Malgreve