Everything compiled fine, but when I went to view the ASXM in the browser to manually invoke the methods to test it, the normal automatically generated info page didn’t come up. Trying to grab the WSDL also gave me a blank page.

I then attached the debugger to IIS to observe what was happening when I tried to view the ASMX info page. By breaking on exceptions, I was able to uncover the following error:

The XML element ‘XXX’ from namespace ‘http://tempuri.org/’ references a method and a type. Change the method’s message name using WebMethodAttribute or change the type’s root element using the XmlRootAttribute.

With a little more thinking, I was able uncover what I believe was going on.

I had defined a complex type to return as a response:

public class FooResponse {...}

[WebMethod]
public FooResponse Foo() {...}

Note that here the exact name pairing of Foo/Foo+Response is important. When I changed the method name as follows, the problem went away:

public class FooResponse {...}

[WebMethod]
public FooResponse Fooxxx() {...}

What I believe is happening is .NET is attempting to automatically wrap the response coming from the Foo method with an element named FooResponse. The use of that same name as the object you want to return creates ambiguity. By changing the name of my response object, or the name of my method I was able to avoid this collision.

I have also posted this information in response to a question on StackOverflow.

Recently, I ran into a scenario where I wanted to write an XSLT that would use an extension object to record some additional information about intermediate steps of the transform. The extension object was not required, however, and I wanted to leave it up to the user of the XSLT as to if they wanted to use the extension object.

The question then became how to conditionally execute calls to the extension object. Suppose you have the following extension object defined in C#:

public class FooExtensionObject
{
  private List<string> recordedValues = new List<string>();

  public void RecordValue(string val)
  {
    recordedValues.Add(val);
  }
}

Now suppose this extension object is used in the following XSLT:

<xsl:transform
        version="1.0"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:foo="urn:FooExObj">
  <template match="/">
    ...
    <xsl:value-of select="foo:RecordValue(@bar)"/>
    ...
  </template>
</transform>

The extension object is supplied to the XSLT through the arguments:

XslTransform transform = new XslTransform();
transform.Load("SomeFile.xsl");

XsltArgumentList args = new XsltArgumentList();
FooExtensionObject aFoo = new FooExtensionObject();
args.AddExtensionObject("urn:FooExObj", aFoo);

XmlTextWriter myWriter = new XmlTextWriter("output.xml", null);

transform.Transform(xpathDoc, args, myWriter);

In the case where the extension object is not supplied, however, this XSLT will cause an error. To correct this issue, you can use the function-available function. Change the transform as follows:

...
<xsl:if test="function-available('foo:RecordValue')">
  <xsl:value-of select="foo:RecordValue(@bar)"/>
</xsl:if>
...

The conditional statement blocks out the use of the extension object when it does not exist. Unfortunately, you must do this where ever you wish to use the extension object.

The cref (code reference) tag is prefaced by a single character, then a colon, followed by the reference in question. The character defines what is being referenced, as defined by the table below.

The full reference for the prefixes is available here, with the full XML comment documentation available here. The Code Project also has an article on the topic.

As an extension to the code example to the aforementioned article, I’ve created an example that can a great interview question for understanding the order in which things are initialized. Consider the following set of classes (C#):

public class StringLogger
{
	public static string GetString(string s)
	{
		Console.WriteLine(s);
		return s;
	}
}

public class BaseType
{
	private string baseString
		= StringLogger.GetString("Base string");
	private static string baseStaticString
		= StringLogger.GetString("Base static string");

	static BaseType()
	{
		Console.WriteLine("Base static constructor");
	}

	public BaseType()
	{
		Console.WriteLine("Base instance constructor");
		DoSomething();
	}

	public virtual void DoSomething()
	{
		Console.WriteLine("Base DoSomething");
	}
}

public class DerivedType : BaseType
{
	private string derivedString
		= StringLogger.GetString("Derived string");
	private static string derivedStaticString
		= StringLogger.GetString("Derived static string");

	static DerivedType()
	{
		Console.WriteLine("Derived static constructor");
	}

	public DerivedType()
	{
		Console.WriteLine("Derived instance constructor");
	}

	public override void DoSomething()
	{
		Console.WriteLine("Derived DoSomething");
	}
}

There is a base class and a derived class, and a utility class that is used to log to the console when one of the string members of one of the other classes is initialized. Now consider creating an instance of the derived class:

public class MainClass
{
	public static void Main()
	{
		Console.WriteLine("Starting...");
		DerivedType d = new DerivedType();
		Console.WriteLine("Done.");
		Console.ReadLine();
	}
}

What will be the output to the console as the DerivedType class is instanciated?

Starting...
Derived static string
Derived static constructor
Derived string
Base static string
Base static constructor
Base string
Base instance constructor
Derived DoSomething
Derived instance constructor
Done.

What’s important to know here is the order in which things happen:

1. Static members of a class are initialized (first time a class is accessed)
2. Static constructor of a class is called (first time a class is accessed)
3. Instance members initialized
4. Instance constructor called

What may be surprising in the above output is that the members of the derived class (both static and instance) are initialized before anything in the base class. This is because the base class isn’t accessed until the derived constructor starts to run, which happens late in the above sequence of events.