In my previous entry on Solving a WS-Oops with ASMX 2.0, I hinted at a code smell. One of the things that I started thinking about was how to leverage a SchemaImporterExtension to control the proxy generation. I was thinking about controlling the serialization of the custom token and making it simpler on the consumer when the token is expressed in a header, which is explicitly specified as part of the contract in the WSDL. I started down that road, and thought “why am I doing this?”
Honestly, now that I have the WSE 3.0 implementation is done (and I am working on the blog post to show it off), I lost interest in the ASMX method because the WSE 3.0 custom policy assertion approach is just so much more elegant than mangling the WSDL with a custom header. Here is how far I got with a custom SIE before ditching it… hopefully this little bit of code will help someone out, I just don’t have it in me to code the rest. In fact… if you want to see a pretty cool implementation of a SchemaImporterExtension, see John Bristowe’s ode to SIE.
class SampleSchemaImporterExtension : SchemaImporterExtension
public override string ImportSchemaType(
if (name.Equals("WSSEDraftSecurityHeader") && ns.Equals("http://schemas.xmlsoap.org/ws/2002/07/secext"))
ConsoleColor defaultBackground = Console.BackgroundColor;
ConsoleColor defaultForeground = Console.ForegroundColor;
Console.BackgroundColor = ConsoleColor.Blue;
Console.ForegroundColor = ConsoleColor.White;
Console.WriteLine(name + " ==== " + ns);
CodeNamespace cns = new CodeNamespace("Msdn.Web.Services.Proxies");
Console.BackgroundColor = defaultBackground;
Console.ForegroundColor = defaultForeground;
Almost done with the blog posting for the WSE 3.0 custom policy assertion… very cool to code, hopefully the post will do it justice.