This project is read-only.

Getting Started? With BizTalk2006 XSD

Mar 8, 2010 at 4:33 PM
Edited Mar 8, 2010 at 4:36 PM

Is there any documentation, getting started or help file?  Psychic software? What to do after running the .MSI.

Okay, I'm not totally stupid.  I opened VS2008 and see on the Tools menu. 

So I have an .xsd schema created in Visual Studio 2005 because it's a BizTalk 2006/R2 project.   How do I convert it to a C# class using your tool?
Do I have to create a VS2008 C# project and copy in the schema?   I'm interested in an automatic way to regen the C# class each time the XSD changes,

Also BizTalk apparently uses a somewhat unorthodox way of importing/reusing schemas.  So if schema A uses schema B, can you handle that with a BizTalk originated schema?

Neal Walters




Mar 9, 2010 at 11:43 AM

Hi Neal,

This article is probably the best place to start learning about There is a link to it on the project homepage if you are looking for it again.

It sounds like you are interested in data contract code generation so this blog post might also be helpful.

The code generation cannot be automated at the moment, which is something we would like to address in the next release.

I suspect that the psychic component will remain under development for quite some time and will not be available until a much later version.



Mar 9, 2010 at 12:32 PM

Hi Neal,

The MSDN article that Alex pointed out also uses some material from an older walkthrough document found here :

Re: BizTalk. I havent tried it recently but the old ASMX version of WSCF did have problems with BizTalk schemas. We havent put in any code that checks if its a Biztalk schema. Its a good idea and i'll put it down in our list of things to do. I have also been considering generating orchestration stubs etc (beyond what the WCF consuming wizard does in BTS) but thats longer term. Its also worth trying to pick schemas from a compiled DLL and generate from there (again, one for the wishlist).



Mar 11, 2010 at 9:39 PM

Hi Benjy,

I was thinking exactly the same as Neal, but then integrate it into the BizTalk Software Factory.

At first I was thinking about using xsd.exe but if is already installed and can be used I would obvious prefer that. :-)

Kind regards,


Mar 12, 2010 at 1:12 PM

Hi Jean-Paul,

Good to hear from you. (Have sent a separate email as well). Would be awesome to use it with BSF, but not sure how it could be done right now. In the current version we havent paid much attention to the command line in a while and the API version is still being developed. However, if you let us know the scenario (ie) what arguments would be passed and if you want a DLL or an command line API, then we can help spike that and maybe make a preview release or a full release depending on the scope.  As i replied to Neal there is scope for using the WSDL handling abilities in WSCF to do lots of stuff in BTS (such as pick a WSDL and generate an assembly with schemas + publish the schemas as a webservice + orch stubs etc) and the Software Factory approach would fit really well with this. Do let me know how we could work together on this.



Mar 16, 2010 at 4:50 PM

In case it helps anyone, this was my original question on Stackoverflow that got me here:

The answer in my original question is what got me going.  However, just yesterday, in an interview of a candidate, she gave me information aboutthe "XSD data contract importer":

I haven't tried that yet. 

By "Pscyhic Software" is was referring to the apparent fact that there was no documentation, and that I have to be a psychic to figure out how to use it.  My pet peeve with CodePlex projects in general are:

1) The home page doesn't clearly state the benefits and features of a tool.  Even though owners of projects aren't selling them for money, they still need to explain why the tool is useful, what problem it solves.

2) The home page or the install should have at least a one page .doc or .pdf called "Getting Started" with at least a sample of what to do. Seems like you reference some blogs on your home page, but are they specific to how to run your tool?  Or just the general background of why the tool was neeed? 

As to Biztalk schemas, they apparently have a somewhat "unique" or non-standard way of reference one to the other, which I have noticed some utilities don't seem to handle. 

I'm no longer totally blocked (again, see what I did on Stackoverflow link above).  So my research has moved from "must-know" to "nice-to-know".  I hope to look into these issues more later.

Neal Walters








Mar 16, 2010 at 9:37 PM

Hi Neal,

Thanks for the feedback. I  Agree on the points that there isnt a single reference document and that blog posts dont necessarily give the whole picture. Unfortunately, I cant see that being addressed anytime soon because we just havent got the time.Thats why we keep pointing folk to the old walkthrough document and the MSDN article. But another way of looking at it is that if you check the walkthrough and the MSDN article then you dont need anything else at this point as the tool is pretty much the same. A few tweaks here and there but nothing major. We are working on a new version that will be quite an overhaul of the current one and that will probably warrant a walkthrough as well as new API samples, command line reference and so on.

In terms of the .NET Framework class you mention, yes, we use that internally  So does XSD.exe and i think also does Xsd2Code and XsdObjectGen. SImilarly we use ServiceContractGenerator for the service and client interfaces.

The way BizTalk handles schema imports (if you are referring to assembly references where you can pick up common types rather than the default xsd:imports) is indeed unique to Biztalk and i dont think any tool outside BTS can handle them. I stumbled upon that regularly when i used to use XmlSpy to edit BTS schemas a long time ago.  We'll add that to our growing list of TODO's but we really cannot promise any dates. (Wish we could because my regular gigs are all Biztalk and i would love to use WSCF more but unless we get another BTS person on this team who can explore these areas, its going to be very hard).