Solving the [Microsoft.Biztalk.WebServices.PublishingException] with imported schema’s

May 22, 2007 / Comments Off on Solving the [Microsoft.Biztalk.WebServices.PublishingException] with imported schema’s

Sometimes when you use the “BizTalk Web Publishing Wizard” you can get an exception like the one below.


—————————
Error
—————————
Failed to create project “
http://localhost/SomeProjectName_Proxy“.
[Microsoft.BizTalk.WebServices.PublishingException] Failed to construct code for schema “
http://SomeSchemaName“.
Method not found: System.String System.Xml.Serialization.XmlMapping.get_ElementName().
—————————
OK  
—————————


This means that you have a schema that imports other schema’s. And The “BizTalk Web Publishing Wizard” is not able to resolve all the imported schema’s.


In my current project we have a default ErrorNode and a default Confirmation Node. So most of the schema’s import both or just the ErrorNode. I tried running the Wizard a couple of times and it boils down to the point where XSD.EXE is called with only the Top-Level schema. The includes are not referenced at all. And that is the reason why XSD.EXE fails and that in turn is the reason why the Web Publishing Wizard fails.


Since I use those schema’s a lot and I needt to reference them in almost every project I placed the files in the Public Assemblies folder of Visual Studio. (“C:Program FilesMicrosoft Visual Studio .NET 2003Common7IDEPublicAssemblies”). So they come up in the first screen when you add a refence.


Today I tried to generate a webservice again and see if there was really nothing I could to to solve this problem. So I started the BizTalk Web Publishing Wizard” again and looked for the dreaded publishing exception.


But instead of the expected error, I got success……. I scratched my head a couple of times and wonderd what had changed since the last time I tried it. I thought it could have something to do with placing the DLL in the PublicAssemblies directory. So I renamed the DLL and ran the “BizTalk Web Publishing Wizard”, Bingo got the error. Renamed it back and had success again.


So it seems that placing important DLL’s in the public assemblies folder, not only makes development much easier. (There are no reference path’s in your Visual Studio Solutions), but they also enhance the behaviour of some .Net Tools. Cause they look in the PublicAssemblies folder as well.


And in my case it changed all for the better !.


I really hope this post is usefull to other people.


 


 

Ever wanted to see what the code of the Microsoft ESB is like ?

May 21, 2007 / Comments Off on Ever wanted to see what the code of the Microsoft ESB is like ?

Microsoft has some guidance on an ESB build with BizTalk. The guidance is around for quite a while. There is a document describing everything and there is even a Virtual PC with the ESB installed.


I was pretty curious how the code was looking so I used reflector a lot on the Image. This is no longer needed since they have posted the sources on Codeplex. You can find the sources >>here<<

  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta