I have heard Don Box speak about the caviats of using the Indigo service model. He states that service classes should not use transport-specific API - notably the use of HttpContext. The logic is obvious.
The problem is that my ASMX web services must often use XSD files that are in the same directory as the ASMX file. HttpContext.Current.Server.MapPath is used to resolve to a local path. What is the recommended API for doing such resolution without HttpContext? Don, your comments would be appreciated.
Have you wondered how the XSD tool and the WSDL tool in the .NET Framework can target numerous managed languages? Internally, it uses a great technology called CodeDOM. CodeDOM is a set of classes in the .NET Framework that facilitate code generation. Here is a sample of CodeDOM in action, generating an Order class.
using System;
using System.CodeDom;
using System.Reflection;
public class CodeGenerator {
public void GenerateOrderType() {
// declare an "Order" type
CodeTypeDeclaration decl = new CodeTypeDeclaration("Order");
// implement ICloneable
decl.BaseTypes.Add(typeof(ICloneable));
// add a field
decl.Members.Add(new CodeMemberField(typeof(int), "OrderID"));
...
}
}
The XSD tool builds up a CodeDOM compile unit describing the classes to be generated, then instantiates a CodeDOM provider to generate source code in a specific language. Providers exist for many .NET Framework languages. The tool supports a command-line switch to specify the desired CodeDOM provider.
By writing a custom CodeDOM provider, we can augment the generated classes with great features - replace fields with properties, replace arrays with strong collections, implement IClonable, generate IComparer instances, and more!
At Point2 I wrote an extensive library to do just that. We recently shared-sourced it here: http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=80258a8c-bb4c-48e6-948b-05f6da568f55
Enjoy!