.NET Programming

Custom Config Sections and CallbackValidatorAttribute

Sean Carpenter — Fri, 31 Oct 2008 21:01:51 GMT

I was recently working on creating a custom configuration section (deriving from ConfigurationSection) to provide some configuration metadata to an app I’m working on. In creating a ConfigurationElement, I wanted to validate that one of the attributes of the element was a valid value for the application. While looking at the example here I noticed the use of various validation attributes applied to validate the format of configuration values.

The CallbackValidatorAttribute and CallbackValidator seemed like they would fit the bill for doing custom validation. Unfortunately, the documentation on CallbackValidatorAttribute is severely lacking. Here’s what I found out using Reflector:

Both the CallbackMethodName and Type properties of the CallbackValidatorAttribute must be specified. The Type property is the type of object that contains the CallbackMethodName method.
The callback method must be public, static and be a ValidatorCallback delegate.
To fail validation, throw an ArgumentException during execution of the callback. Reflector isn’t actually any help here for the CallbackValidator, but this is what the other validator types do.

I’ve created a small sample demonstrating the use of the CallbackValidatorAttribute. You can get it here. The sample validator itself isn’t very useful, but hopefully it illustrates the concept well enough.

NCover on Vista x64

Sean Carpenter — Wed, 23 Jul 2008 18:48:18 GMT

I've been trying to get NCover to run successfully on Vista Ultimate x64 on and off for the last month. We're still using one of the free versions of NCover available from here, so there is no built-in x64 support. I came across this post today that mentioned using corflags to set the 32BIT flag in both NCover and your testing application (the post is describes using NUnit, but this worked for me with MBUnit as well).

Those changes got me past the

Profiled process terminated. Profiler connection not established.

error, but I was then confronted with a new wrinkle:

Index was outside the bounds of the array.

This error would appear at the end of the profiled MBUnit run. I poked around some and found some old posts on the NCover forums talking about this error and how it didn't occur in NCover 1.5.5. So I downloaded 1.5.5 (I had been using 1.5.8) and now all is good - coverage runs successfully!

We're not doing that much with NCover at this point, so I don't think we're giving up anything going with 1.5.5. Maybe someday we'll be able to purchase a current license that supports x64 out of the box.

Changing the Protocol Version for a Web Service Call

Sean Carpenter — Sat, 27 May 2006 10:28:00 GMT

I've been playing with the National Digitial Forecast Database (NDFD) provided by the National Weather Service. You can retrieve a forecast via a SOAP web service by providing your latitiude and longitude and a few other details. The web service worked fine when I called it from Python, but I was getting an error when calling it from .NET (using the generated proxy classes in VS 2003 and VS 2005). It turns out that the service needs HTTP version 1.0, not 1.1 (the default in .NET). Unfortunately, the generated proxy class doesn't expose the ProtocolVersion property of the underlying HttpWebRequest object. So, I added support for this property.

It's a little easier with VS 2005 because of the support for partial classes:

public partial class ndfd {
    private Version _protocolVersion = System.Net.HttpVersion.Version11;
    public Version ProtocolVersion {
        get { return _protocolVersion; }
        set { _protocolVersion = value; }
    }

    protected override System.Net.WebRequest GetWebRequest(Uri uri) {
        System.Net.WebRequest req = base.GetWebRequest(uri);
        ((System.Net.HttpWebRequest)req).ProtocolVersion = _protocolVersion;
        return req;
    }
}

I just added a new file to my solution and added a partial class definition (ndfd is the proxy class generated for the web service) that adds a ProtocolVersion property. Then in the GetWebRequest method, I set the protocol version of the WebRequest.

For VS 2003, I just derived a new class from the generated proxy class and added my property and override there:

public class ndfd2 : ndfd {
    private Version _protocolVersion = System.Net.HttpVersion.Version11;
    public Version ProtocolVersion {
        get { return _protocolVersion; }
        set { _protocolVersion = value; }
    }

    protected override System.Net.WebRequest GetWebRequest(Uri uri) {
        System.Net.WebRequest req = base.GetWebRequest(uri);
        ((System.Net.HttpWebRequest)req).ProtocolVersion = _protocolVersion;
        return req;
    }
}

Then I can just use the new class in my code. Both of these approaches avoid doing anything to the actual generated class, so the Web Reference can be updated without losing any of the customizations.

Preventing Automatic Generation of Web Service WSDL File

Sean Carpenter — Sat, 19 Nov 2005 17:32:00 GMT

We have a web service that is exposed on the internet but is only used by our client application. The client uses SSL to connect to the server and we are using WS-Security to provide authorization. Even so, I wanted to prevent someone from viewing the interface of the service by going to the default WSDL generated by ASP.Net (http://domain/Service.asmx?WSDL).

It turns out that this is actually pretty easy to do. I found documentation on it related to Visual Studio Team System Application Designer, but that page mentions that it makes a change to a service's web.config file. The answer is to remove the "Documentation" protocol from the <webServices>, <protocols> section of the config file. I chose to do it by using a <remove> directive in the service's web.config file, but you could also do it in the machine.config file to affect the whole server. The nice thing about this solution is that I can leave it enabled on our development server so that Visual Studio can auto-generate the client proxy, but it won't be exposed at all on the production site.

Here's my change:

<webServices>
    <protocols>
        <remove name="Documentation" />
    </protocols>
</webServices>

.NET Framework 2.0 Breaking Changes

Sean Carpenter — Mon, 24 Oct 2005 13:47:00 GMT

Now that the release of VS2005 and the .NET Framework 2.0 is imminent, I'm able to justify more time at work for reviewing its impact. This list of breaking changes for 2.0 is definitely useful in that regard.

I think one of the most important changes is the fact that unhandled exceptions will now always end a process (search for “Unhandled exceptions will always be fatal to a process”on this page). The 1.1 behavior was that unhandled exceptions on threads other than the main thread would not end a process. I ran into this twice while working on Windows Services that used background threads. I know I should have been catching the exceptions, but it was still design/debug time and that error handling wasn't present yet. The symptom I experienced was that the service would run for a while, but then stop polling a message queue for any more messages. The problem was that the polling was done in response to the Elapsed event of a non auto-reset timer - when the processing was complete, the timer was re-enabled. When an exception was raised in the processing (which took place on a background thread as a result of the timer Elapsed event) the processing stopped before getting to the re-enable code. So essentially the service was dead, since it was no longer polling the message queue. This change will prevent this kind of bug from creeping in.

[Via James Manning]

Finding the source of a Microsoft DLL

Sean Carpenter — Mon, 24 Oct 2005 12:08:00 GMT

Geoff Appleby posts a link to a Microsoft support page that can tell you what DLL came from what package. Very cool.

Where'd that DLL come from?