I've had several occasions now where someone with Sogeti or someone at a client has had a "truly mysterious" problem where the XmlSerializer was throwing an error which the programmer simply couldn't understand. When situations like this arise, I find myself reaching for a great post written by Scott Hanselman on this issue which I will repeat the meat of which here so that I've got a copy of my own. If you find yourself needing to debug the code generated by the XmlSerializer to serialize or deserialize your type, here is what you need to do: 1. Modify your app.config or web.config to include the following: 1: <?xml version="1.0" encoding="utf-8" ?> 2: <configuration> 3:<system.diagnostics> 4: <switches> 5:<add name="XmlSerialization.Compilation" value="1" /> 6: </switches> 7:</system.diagnostics> 8: </configuration>2. Recompile your application and set a break point just after you create your XmlSerializer.3. Open the directory "C:\Documents and Settings\[username]\Local Settings\Temp"4. Find the .CS file with the most recent timestamp, it will have a random file name.5. Open that file in the same Visual Studio you've got debugging, and set a break point.6. Debug to your hearts content.Important to remember at this point is that this code is generated by the system and is meant to be fast, not friendly. You'll need to be very familiar with the XmlReader object or you won't understand how it is doing what it is doing. Also realize that you can't control that code, you can only control the attributes on the Type you gave it, and from that it will generate the code as it sees fit.Side Note : One of the classic performance mistakes I see people make when they start doing a lot of XML serialization is to create the XmlSerializer object every time they need one. The constructor of the XmlSerializer is the most expensive part of it's operations. It is there that the code is generated which you are debugging above, and so once you've created an XmlSerializer if you've got a reasonable expectation of needing it again then keep it around!
I'm working on a document which will eventually be published here on best practices for BizTalk development. What practices do you insist on in your project? Naming? I generally use Scott Colestock's guidelines for this.Backdoor Receive Locations? Any rules on putting in re-entry points for non-file adapters?Mapping? Any rules about how things will be organized, laid-out, etc?Anything else? Post your comments here, I'd love to hear people's ideas on this subject.
As I've mentioned several times here already, I spent the last week at Microsoft's TechEd 2007 conference. It was great, but this is the story of finding my way home from TechEd. After a very long taxi ride to the airport because of rain on the road, the weather cleared and I found myself finally at the Orlando Airport. It was 5:45pm, and our flight was scheduled to take off at 7:50pm, hence boarding at 7:20pm. Well our flight suffered a 20 minute delay of departure, and then didn't start boarding until 8:05pm which meant at 7:38pm I was in an airport terminal of mostly glass walls, with CNN running the countdown on lots of monitors, as the Space Shuttle Atlantis took off from Cape Canaveral just 60 miles away. It was, and is, an ambition of mine to see the shuttle (or it's replacement) take off from a distance close enough to see the pad, but this was still a special moment to stand around with about 150 other people just in that terminal and watch the orbiter rise on the horizon. To Commander Rick Sturckow, Pilot Lee Archambault and Specialists Patrick Forrester, Steven Swanson, Danny Olivas, James Reilly and Clayton Anderson as well as Specialist Sunita Williams whom they will be collecting from the International Space Station, god speed, good journeys and safe returns. To often we forget these heroes because for some reason, to the American public, the mystique of space has worn-off. But at least this tech geek is continually impressed by the heroism displayed by all those in the Astronaut Corps. (Photo Copyright 2007 by The Associated Press. All Rights Reserved.)