More stuff on WCF / IIS7 - IIS7 has got some funky new tracing features built in to diagnose failed requests. Again, this is not enabled by default; you need to go into "Turn Windows Features on or off" and select "Interet Information Services\World Wide Web Services\Health and Diagnostics\Tracing". Once done, you'll see a new entry in the IIS admin tool - select your web site and on the Actions pane you can now configure the failed request tracing. Enjoy!

Just been starting to play with WCF again, and was experimenting with the IIS activation. With IIS7 on Vista, I was getting a 404 error on my .svc file. Since I knew the file existed, I guessed this was probably down to the appropriate handlers not being installed, and since it's not one of the few types that get served as static pages, IIS returned a 404.

I quick poke around the new IIS admin screen showed this to be the case - no handlers were setup to serve .svc files. Turns out that in Vista, this is an optional component that is not installed by default. To get .svc files running, you need to go to Control Panel \ Programs, open the "Turn Windows features on or off" applet and drill into the Microsoft .NET Framework 3.0 node. In there, select the WCF HTTP Activation entry and you should be good to go.

Not much more to report on the Spec# investigations. The overall approach holds a lot of promise, but I would say that currently it's a little early to consider its use for anything more than experimentation. I'm hoping that some of the features quickly migrate over to C#, although I doubt this will be happening in the 3.0 timeframe.

An update on the empty solution problem that I was experiencing with Spec# - if I run up VS2005 and try to create a new Spec# project (any type, console app, windows app or class library) I was getting the project created, but the solution pane within VS was blank.

I'm running Vista (build 5744), and wondered if that had caused an issue somewhere, so I've just tried an install of Spec# on a VM running XP - and it works just fine. So I'm guessing that somewhere during either the VS2005 install or the Spec# install on Vista, something somewhere doesn't register properly. If / when I get (very!) bored, I may try comparing the registry entries etc to see if I can locate the problem.

In a quest to improve code quality, I've been looking at a number of code analysis tools lately. FxCop was the lowest hanging fruit, since it ships with VS2005 - it's pretty good, and I tend to agree with the bulk of the warnings that it issued. I ran it against a fairly big project (~30 seperate assemblies), and it generated a good number of warnings, which took a few days to trawl through and get fixed. Most of them were trivial in nature, but there were a few good ones, including about 4 clear-cut bugs (this being code that has been live for over 2 years!). There's no doubt that the code is cleaner now than before the FxCop runs, so it's now turned on by default.

I'm now having a play with Spec# (SpecSharp), which at first glance looks to be extremely powerful. A few teething problems so far (mainly the VS2005 integration - the Spec# project templates just don't seem to work for me), but nothing too serious. I'm going to spend the next couple of days running it against some subsets of some existing projects and adding in the appropriate annotations to the code - it'll be interesting to see how much effort it entails with existing code, and what value it adds.