Tech-Ed Notes

I’m slowly getting through some good sessions from the Tech-Ed (US) DVD set, and making a few notes on the way (appologies to speakers if I’ve butchered their ides):

Ingo Rammer - Scalability/Connected Systems Troubleshooting Talk - CSI 448

  • network profiling - DO THIS FIRST
  • Tools - ethereal (my fave), tcptrace, fiddler, proxytrace
  • Lessons Learned
      - Interactions: too many or too large
      - Latency vs. Bandwidth
       Bandwidth is improving quicker than latency (latency is constrained by speed of light)
       1200 BPS modem to download 2 GB- “it’s quicker to walk”
  •  SQL Profiling - do this second
  • Look for an appropriate number of statements given the “work“ that needs to be done. Be wary of generated SQL and foreaching -> update over items in datasets
  • CLR Proflier - once you’ve done your network profiling and SQL profling
     - tools like the CLR profiler (and Compuware, ANTS Profiler etc) can only show you “in process” optimizations.

 Random Suggestion: Learn and understand NLB in server 2003 - you won’t be able to cluster unless you design and test for this up front.


  • set HTTP Connection limit (to get over the 2 connections to a singler server per client HTTP restriction) 
  • on the web service proxy set proxy.PreAuthenticate = true; for HTTP basic auth (reduces 1 round trip to the server)
  • use “authenticated connection sharing” if using Windows Integrated Security - for windows auth set proxy.UnsafeAuthenticatedConnectionSharing = true; (but you need to cache the connection by a key) so also set proxy.ConnectionGroupName = “key” (or “GroupName” or whatever) so you can connect as the “right” connection.
  • turn off custom errors in IIS if your clients are all going to be web services esp for 401 (save some bandwidth)

Tim Ewald - Web Services Tips & Tricks - CSI353

4 things that ASMX “plumbing” does for you (I liked this overview)

  1. automatic, extensible WSDL generation
  2. serialization/deserialization
  3. dispatch messages to [WebMethod]s
  4. hooks for message interception


  • Design your contract carefully (code first vs. schema first)
  • it is often better to handle messages as a single parameter -> closer to messaging
  • SoapParameterStyle.Bare attribute (in code) = if part name = “parameters” then the plumbing will “rip apart” your message and turn it into a serise of parameters. Otherwise it uses the (better) bare style.
  • XML Serializer and polymorphism - you need to annotate the base class as shown below (employee is the base)
     public class Person {  
      public string Name;  
      public int Age;
     public class Employee {  
      public double Salary;
  • Serialization Problems
      - default values - tweak in the serializer - if you have a field called foo and you want to know if foo was sent (to get around the “missing value” problem) we create a [XmlIgnore] property called fooSpecified (case-sensitive) and the run-time will populate that for us.
      - in whidbey use nullable types
  • Get Access to Raw XML
      - change argument type to “xmlelement” (but can nolonger generate a meaningful contract)
      - bad if you have big incoming messages (the DOM is heavy-weight)
      - you can implement IXmlSerializable (in framework 2.0) to get a stream instead of an element
      - also XML Schema Provider in framework 2.0
  • Run WSDL.exe form the commandline (vs. Add Web Reference, which makes too many choices for you) 
  • WSDL.exe + shared types, schema importer extensions etc in whidbey
  • Use a facade to insulate the client or service proxies from the “real” code.