If you're making a SOAP request (in this case with the SOAP toolkit), and you get: 

"WSDLReader:Loading of the WSDL file failed HRESULT=0x80070057: The parameter is incorrect."

during the MSSoapInit() call, check that you haven't added a cache-control:no-cache custom header to IIS, or that HttpExpires isn't set to zero days.
 

So I'm sat here watching the Mix07 keynote, 45 minutes after Ray Ozzie first got to the stage. I download the Silverlight Beta for Mac and install it.

Firefox has crashed 4 times while trying to view the Silverlight demos on microsoft.com/silverlight. This is getting really frustrating trying to review the new features.
 

Javascript is a dynamic language. And that's a problem. On the one hand it allows you virtually unlimited ability to play with data structures and mold them to your own design. On the other, it presents the virtually insurmountable problem of testability.

You see, a dynamic language delays the checks which are performed by a static language during compilation until runtime. So you have no idea whether your code is correct until it is executed. The usual answer to this is to write unit tests. But the people who say this tend to gloss over the difficulty of getting 100% unit test coverage. 70% coverage is usually considered a very high test rate. And then there's the difficulty of getting the coverage metrics themselves. At the time of writing, there is only one Javascript/browser code coverage tool around. Hopefully all the hype surrounding AJAX will encourage more of these tools to be written.

One tool that is available now is JavascriptLint. Lint was the tool you may have used many years ago to statically analyze your C source code for common programming errors not picked up by the compiler. So JavascriptLint does the same but for Javascript. It's based on SpiderMonkey, the C-based Javascript engine in Firefox. So you can be sure it's rock solid with zero false positives. It's a fantastic tool to help AJAX programming as it seamlessly integrates into your favorite IDE as an external tool. Some of the errors it picks up on are:

• Missing semicolons.
• Unintended use of octal where decimal was intended
• Automatic type coercion
• Undeclared variables
• Redeclared variables

Some of these are only available with the tool in Option Explicit mode. Even if it doesn't spot outright bugs in your code, the checks for type coercion and missing semicolons are performance bugs in your code.

The benefits of JavascriptLint are so conclusive it gets run over my code several times per day.

Recently, I was faced with a problem whereby client-side validation of controls failed to work in Firefox. Only server-side validation was working. Client side validation was working fine in IE.

This was puzzling as everything I read said that ASP.Net v2 supported client-side validation in Firefox. No amount of Googling helped to identify the problem, so I had to track it down from scratch - and the results were quite interesting. If you have

<xhtmlConformance mode="Legacy"/>

set in your web.config, then client-side validation is disabled in firefox.

To see why, we have to jump down into the validation framework that ASP.Net sends to the web browser. The actual Javascript validation function looks like:

function ValidatorValidate(val) {

      val.isvalid = true;

      if (val.enabled != false) {

            if (typeof(val.evaluationfunction) == "function") {

                  val.isvalid = val.evaluationfunction(val);

            }

      }

      ValidatorUpdateDisplay(val);

}

Using Venkman, I was able to see that val.evaluationfunction wasn't a function at all, therefore the page wasn't getting validated because of this. A bit more searching found that this evaluationfunction is an expando attribute. In ASP.Net v1, this expando is an IE-only HTML expando, defined directly in the HTML markup. In ASP.Net v2, this is a Javascript expando attribute, defined on the DOM via Javascript, and therefore compatible with both IE and Firefox.

For example, the RequiredFieldValidator calls RegisterExpandoAttribute. You can call this method yourself like:

Page.ClientScript.RegisterExpandoAttribute(TextBox1.ClientID, "value", TextBox1.Text);

 This produces a block of Javascript just before the closing </form> tag like:

<script type="text/javascript">

<!--

var TextBox1 = document.all ? document.all["TextBox1"] : document.getElementById("TextBox1");

TextBox1.value = "";

// -->

</script>

where "value" has become the new expando attribute. In the case of the RequiredFieldValidator, the expando name is" evaluationfunction" and it is added to the <span> representing the control at runtime.

It turned out that this block of Javascript wasn't being sent to Firefox in my situation, and I didn't know why. Instead, the evaluationfunction expando attribute was being rendered directly on the <span> element in HTML.

So after good deal of decompilation using Reflector, and debugging using Reflection Invokeing of private methods, I discovered the problem was that RegisterExpandoAttribute checks the XHTML Rendering Mode prior to generating the Javascript and if that rendering mode is set to Legacy, then the expando is rendered directly onto the <span> element and no Javascript code is rendered. The result of this is to prevent Firefox from performing client-side validation when Legacy XHTML mode is set.

I have no idea why the ASP.Net team chose to do this for validation. Perhaps the Legacy XHTML setting should have been called "ASPNetv1Conformance" because that's actually what it does. The docs for Legacy mode state:

"Reverts a number of rendering changes made for conformance to the v1.1 rendering behavior."

Can anyone tell me why the commented out line fails to compile, whereas the next line succeeds? Sure, it's a runtime vs compiletime thing, but why does C# prevent me from casting from a string to (T), whereas the very next line it lets me cast from an object to (T).

using System;

class X {

      static void Main() {

            Console.WriteLine(Foo<string>());

      }

      static T Foo<T>() {

            if (typeof(T) == typeof(string)) {

//                return (T)"Hello World";

                  return (T)Convert.ChangeType("Hello World", typeof(T));

            } else {

                  return default(T);

            }

      }

}

test.cs(10,11): error CS0030: Cannot convert type 'string' to 'T'