Scott Hanselman's ComputerZen.com

In this example, Wsdl is a class that's one of our internal convenience wrappers around System.Web.Services.Description.ServiceDescription.  The Schemas property is just the XmlSchema[] that from service.Types.Schemas. 

I wasn't sure if my WSDL file was kosher, and I wanted to "validate" the whole setup.  Most of my XML Schemas were pulled in via xsd:import in my wsdl like:

 <wsdl:types>
  <xsd:schema targetNamespace="http://www.corillian.com/thingie/operations/2199/05" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd1="http://www.corillian.com/thingie/operations/2199/05"> <!-- bogus namespaces for example -->
   <xsd:import namespace="http://www.corillian.com/thingie/banking/domain/2199/05" schemaLocation="..\banking\BankingDomain.xsd"/>
  </xsd:schema>  
 </wsdl:types>

...and as you can see, the schemaLocation was relative.  The way I was going to force a Validation of the XML Schemas (other than physically loading each of them into memory myself) was to call .Compile().  However, it appears that the relative paths were being resolved relative to the Current AppDomain's current directory, NOT the directory the WSDL was located in!  So:

Wsdl w = new Wsdl();
w.Load(file.FullName);
foreach(XmlSchema x in w.Schemas)
{
  foreach(XmlSchemaImport i in x.Includes)
  {
     i.SchemaLocation = Path.Combine(file.DirectoryName,i.SchemaLocation);
  }
  x.Compile(new ValidationEventHandler(OnValidationEvent), new XmlUrlResolver());
}

Before I mess with the WSDL and Schemas, I take the directory that the WSDL file was located in and use it as a base directory for the relative schemaLocation.  Thank goodness the SchemaLocation property was not readonly! :)  Using Path.Combine has the added benefit of collapsing ".." relative paths.