Paraesthesia

Came across an issue today where we want to be able to read WCF service and client configuration from a custom location. That's actually more difficult than you'd think.

By default, WCF configuration is stored in your app.config (or web.config) file in the <system.serviceModel> section. When you create a client (like with ChannelFactory<T>) or a service host, the application configuration file gets read, the contents get parsed into the appropriate strong types, and "magic happens" - the appropriate object is created.

In our situation, we wanted to do exactly that, but in a Powershell script... and that's a problem, because the only way we could get WCF to see the configuration was to actually create a Powershell.exe.config file in the Powershell installation directory, run the script, and then remove the configuration. Not so great. We needed the ability to say, "Hey, WCF, use the configuration file that we explicitly specify."

That, as I said, is a little more difficult than you'd think.

A lot of searching led me to two articles:

• For service hosting, "Custom Config File for a WCF Service Hosted in IIS."
• For clients, a forum thread called "Config Hosting Multiple WCF Services in One NT Service."

I agree, the titles don't necessarily sound like they'd help much, but they do. They even include source for how to do this so you can see what I'm talking about. That said, I'll summarize the steps here.

For service hosting, what it boils down to is:

• Create a custom service host class that derives from System.ServiceModel.ServiceHost.
• Override the protected ApplyConfiguration method. In the override, load your custom configuration file, find the System.ServiceModel.Configuration.ServiceElement corresponding to the service you want to host, and call LoadConfigurationSection on it.

For clients, it's slightly more work:

• Create a custom class deriving from ChannelFactory<T>.
• Override the protected CreateDescription method. In the override, you need to...
  • Call base.CreateDescription().
  • Read in your custom configuration.
  • Create a custom ServiceEndpoint based on your configuration. Don't forget the bindings, behaviors, etc. (That's what makes this hard.)
  • Return that custom ServiceEndpoint.

Once you do that, you're set - you can create a standalone XML configuration file with the <system.serviceModel> section and point WCF at that rather than having to store the configuration in the default app.config/web.config. You are limited to using your custom service host and client classes, but then, if you're getting into things this deep you're probably not afraid of getting your hands dirty.

Again, both of those articles contain full source to the solutions so you can see how it works. Check 'em out.

I'm a huge stickler for metadata in my iTunes library and for the most part, I can find incorrect or missing data by using the iTunes smart playlists - I have one, for example, that checks for "Year is 0" so I can find tracks that don't have a year associated with them.

One of the missing features in there is that you can't set up a smart playlist that tells you which tracks don't have artwork. So, to fill that gap, I wrote a script that does it for you. This little JScript, when run, will create a regular playlist called "Missing Artwork" with any tracks that it finds that don't have any artwork items associated (a track can have multiple pieces of artwork, not just one).

Just ran it myself on my library and it works like a champ. Standard disclaimers apply: use at your own risk, YMMV, I'm not responsible for what happens if something goes awry, etc.

var ITTrackKindFile = 1;
var iTunesApp = WScript.CreateObject("iTunes.Application");
var numTracksWithoutArtwork = 0;
var mainLibrary = iTunesApp.LibraryPlaylist;
var tracks = mainLibrary.Tracks;
var numTracks = tracks.Count;
var foundTracks = new Array();

WScript.Echo("Checking " + numTracks + " tracks for missing artwork...");
while (numTracks != 0)
{
  var  currTrack = tracks.Item(numTracks);
  
  if (currTrack.Kind == ITTrackKindFile)
  {
    if(currTrack.Artwork == null || currTrack.Artwork.Count == 0)
    {
      numTracksWithoutArtwork++;
      foundTracks.push(currTrack);
    }
  }
  
  numTracks--;
}

if (numTracksWithoutArtwork > 0)
{
  WScript.Echo("Found " + numTracksWithoutArtwork + " tracks missing artwork. Creating playlist...");
  
  var playList = iTunesApp.CreatePlaylist("Missing Artwork");
  for(var trackIndex in foundTracks)
  {
    var currTrack = foundTracks[trackIndex];
    playList.AddTrack(currTrack);
  }
  WScript.Echo("Playlist created.");
}
else
{
  WScript.Echo("No tracks missing artwork were found.");
}

The folks over at Typemock have done something special to help address the needs of the SharePoint development community and have released a special version of their Isolator mocking framework specifically to help with testing SharePoint solutions: Isolator for SharePoint.

Isolator for SharePoint is the same Isolator we know and love, but will only work on SharePoint-specific classes. (Of course, if you get sucked in, like I know you will, then you can upgrade to the full Isolator with no issue and mock objects outside SharePoint.)

For a limited time, they're even offering a few free licenses to folks in the blogosphere, so if you want one, check out how to get one. (If you don't get one of the free ones, the full retail price of Isolator for SharePoint is $149, and they're offering a discount for a while so you can get it for $99 - a great deal.)

I did quite a bit of SharePoint development in my last job and something like this would have been amazing to have. If you're doing SharePoint work right now, you owe it to yourself to give it a look.

As mentioned in an earlier post, I got my XO laptop up and running on Ubuntu so I can do a little more useful work with it. (Firefox is a far-and-away superior web browser to the built-in browser that comes with Sugar.) Of course, never satisfied, I noticed there were a few simple applications I'd like to have on there (like a calculator), so I went to install them.

I fired up the "Add/Remove" app in XFCE to see what apps were available. It got to a stage where it said, "Building dependency tree..." and disappeared. Tried a few more times and got the same result. I dropped to the command line, ran gnome-app-install (it took a while to figure out that's what the app was called) and saw there was a segmentation fault occurring. Then I tried apt-get and got a message about a "segmentation faulty tree." Very clear.

Doing an additional, oh, hour of searching, I found that this happens when certain cache files get corrupted. The fix?

sudo rm /var/cache/apt/*.bin

Basically, delete a set of cached files that the installation system uses because they've gotten corrupted. Re-running the apt-get commands will then work, as will the "Add/Remove" program.

I had updated the OS and installed packages after getting things working, so I know for a fact apt-get was correctly working. I'm not really sure where/how these files got corrupted, but it's fixed now.

Before I get off on a tiny rant, let me be clear: I started my career on a LAMP stack. I used to be a huge Linux guy, loved me some Perl, and lived life on the FOSS side. I still like Perl, though I haven't written any for a few years. It's been a while since I've been in that world so it's taking a little getting used to getting back in. I've been there, and I appreciate what's available.

That said, this, right here, is precisely why Linux will never overtake Windows or MacOS on consumer desktops. There is precisely zero chance that any member of my family would have had the time, patience, or wherewithal to figure out what the name of the "Add/Remove" app is, run it at the command line, figure out that it's just a wrapper for apt-get, run that from a command line, and then figure out what the cryptic "segmentation faulty tree" error message meant. And my family is chock full of smart folks. They're just not computer geeks, and investing the time to get into it at this level isn't something they're interested in doing. They shouldn't have to be.

Windows and MacOS definitely have their problems. Windows, sure, maybe more so than MacOS. That said, I have never once had an inexplicable failure in Windows on something so critically low-level as the installation system, and any time there is a problem, there's a single, central event log I can go look at to see what happened. Even if it doesn't tell me exactly what happened, it's at least got enough information that if I literally copy and paste the error into Google, I'll come out with a pretty good chance of getting the answer in the first few hits. Blue Screen of Death? Sure, I've had my fill. Weird glitches? Absolutely. Usually, though, it's because I'm installing and uninstalling all nature of things, combined with the fact that I'm a developer, so I'm always tweaking and changing and updating and doing all sorts of unconventional stuff - unlike the standard user.

Anyway, rant over. I'll probably disable comments on this one because I'm really not interested in getting into a religious OS war here; I just needed to vent my frustrations in getting what I feel should be a simple thing up and running. I'm excited to get back into the Linux world and to have the XO as an excuse to mess around with it. We'll see how the journey continues.

About a year ago now, I participated in the "Give One, Get One" program for the One Laptop Per Child foundation. As part of that, I got one of the little XO laptops. They're neat little machines, 433MHz processors with 256MB RAM - not a lot of computing power, but fun to play with.

I messed around with the Sugar OS for a while, but admittedly got a little tired of it since there's not a lot you can do in it - it's an educational item, after all, not a little netbook or something. To that effect, it sat dormant in my office for a few months... until now.

I got the urge to get an alternate OS working on there so I could use Firefox and browse the web - actually use it like a mini notebook for light tasks. I found some instructions on the OLPC wiki that explain how to get Ubuntu installed on the XO, but after trying several times, it just wasn't working for me. I couldn't get past the step where you set up the Ubuntu image using QEMU. The image would always boot poorly or, in some cases, not at all... and, frankly, while I used to be a Linux guy, my skills in that arena are a bit too rusty to adequately troubleshoot those issues. Plus, the way they explain it, you're actually putting Ubuntu right on the system - no going back to the original Sugar OS.

Thankfully, I found another set of instructions - how to install Ubuntu on an SD card and boot the XO from that. While the setup takes some time, it was super simple and worked like a charm. Plus, it's non-destructive: if you mess anything up, you can always just remove the SD card and you're back to Sugar OS.

I have my XO booting Ubuntu now and it's in the process of running system updates. I'm excited to put it back to use! If you have an XO and are interested in getting it running more interesting applications than what's available on Sugar, try booting Ubuntu from an SD card. It's worth it.

UPDATES!

I'm going to post updates to this entry as I get experience with the XO using Ubuntu and include additional things you may want to do, or gotchas you might run into.

• Make sure to read the comments on that blog article that explains the SD card installation of Ubuntu. There are some things in there that you'll need to know or might help you out.
• Check out this wiki entry about customizing Ubuntu on XO. It has a lot of things you might want to do to this base install.
• Change your hostname. The default hostname for the installation is "OLPC" - a little generic, and if you have more than one at home, problematic. In order to do this, edit your /etc/hostname file to have your new hostname. Also, edit the /etc/hosts file, find the line in there for "OLPC," and replace "OLPC" with your new hostname. Yes, you have to do it in both places. Reboot and you're good.
• Some settings you change won't persist across reboots. I think this boils down to my not understanding where various settings get updated. For example, the touch pad speed was super slow for me and no matter how many times I changed the setting in the control panel, it wouldn't persist the setting. Turns out there's a .xfce4_startup file in the OLPC user's home directory that specifies the mouse speed - and it overrides any setting you may have put in the control panel. You can change the mouse setting by modifying the xset m 6/10 15 line to be something more appropriate. According to the wiki entry, this will differ based on your firmware verson. For me, xset m 5 12 seems to work really well. I assume you could just remove the line and have it fall back to use the settings from the control panel... but I didn't try it.

Was messing about on the computer this morning when I noticed that Vista thinks I'm not connected to the Internet, even though I am. The "Network and Sharing Center" says I have "Local Only" access right now... but I can get to sites on the Internet, so obviously that's very wrong.

As it turns out, this is a known issue for Vista and Windows 2008 computer that have more than one network adapter. My computer has a wireless and a wired adapter, so I guess I qualify. I found a little additional discussion (not much) in a forum thread. Not sure why it just started doing this today; it was working fine before. No network changes have happened... except I had to reboot my router yesterday. I wonder if that's what started it. Maybe another router reboot is in order.

I got my Ion Drum Rocker drum set delivered yesterday and set it up last night. It occurred to me after I'd played with it for a while in Rock Band 2 that I'd finally gotten a chance to play with all of the various gaming drum kits - the Ion, the standard Rock Band, and the Guitar Hero World Tour - and I should probably post a decent comparison since I'd not seen such a thing out there.

For reference, and so you know where I'm coming from:

• I was in drama in high school, not band, and I have no musical training.
• I primarily play Xbox 360, though my GHWT experience was on the Wii.
• I like the Rock Band game more than GHWT. The set list is better and I have a lot invested in downloadable content.
• I generally play on the "Hard" difficulty, though I'll fall back to "Medium" if the song's really difficult on drums. I'm not awesome by any means, but I can hold my own.
• The whole reason I started seriously looking at the Ion kit was that I put a hole through the yellow pad in my original Rock Band kit.

Rock Band Drum Kit

I had the Rock Band 1 kit up until a week or so ago. It's decent, though the pads are really loud when you hit them so I have to really crank up the amp to get the music to be louder than the smack-smack-smack of the drum kit. I tried getting some of those rubber silencers they sell, but they didn't work - instead they just absorbed the hits I was making so I would randomly miss more notes. (I've heard that these work better on the new Rock Band 2 kits than the original Rock Band kits. I haven't tried that.)

Portability on the kit is good - you can pick it up with one hand and move it around, and it easily disassembles to go in your car when you need to take it to a friend's house. This is good for putting it in the other room when you're done playing so your living room doesn't look like a studio.

The kick pedal doesn't move around because it's latched to a bar on the bottom of the kit. The downside of this is that if it's not well positioned, you don't get much flexibility on how it gets placed. You eventually get used to it, though. I didn't have any of the problems with the pedal breaking like I heard some other folks having.

I never got 100% on a song - ever, even on easy - because the kit would seem to randomly not register notes. (How can you get 99% on Hard and never get 100% on Easy?) This was the most frustrating bit about this kit - I legitimately couldn't tell, in many cases, if the calibration was off, if the kit was misbehaving, or if I really just sucked as a drummer. (Admittedly, I very well may suck, but come on - never once a 100%? Never?)

Guitar Hero World Tour Drum Kit

I played the GHWT kit over at a friend's house for a couple of hours, so I don't have as much experience with it as I do my Rock Band kit. The pads are significantly quieter than the Rock Band kit and I didn't feel like I was missing any notes due to the kit - I felt a lot more confident that if I was missing a note, it was due to my own incompetence. (That sounds like a bad thing, but it's not - I was able to tell where I needed to practice and improve rather than never quite being sure.)

The pads on the GHWT kit don't have any real moving pieces the way the Rock Band kit does. The Rock Band pads sort of "float" and when you hit them the pad depresses, touches a sensor, and the hit is registered. The GHWT pads seem to be pressure sensitive in-and-of-themselves, so it's a bit more like a real electronic drum kit. There's also a little more rebound to them, which is nice.

The kick pedal on the GHWT kit felt much flimsier than the one on the Rock Band kit. Also, there was really nothing tethering it to the ground so it traveled all over the place while playing and I was very frustrated by having to reach down between songs and constantly reposition it.

The big/obvious addition here is that of the cymbals. Rather than leave the hi-hat as a pad even with the rest of the drums, it's raised up, closer to the way it'd be in a real drum set. It changes the way you play and it takes some getting used to if you're used to the standard Rock Band kit. Once you get the hang of it, it feels pretty natural and it's nice.

I didn't get a chance to play Rock Band with this kit so I don't know how Rock Band handles the fact that this kit has five pads (three drums, two cymbals) instead of the four that Rock Band expects. I assume that you just don't use the cymbal on the right when you're in Rock Band. By all accounts the GHWT kit is compatible with Rock Band (and vice versa) so it deals with it somehow.

At the time of this writing, they don't sell the GHWT kit by itself - you have to buy it with the complete band set for GHWT. I already have four plastic guitars and a mic - I don't need more guitars or another mic, so this was a bit disappointing. However, it did give me an excuse to get the...

Ion Drum Rocker

This thing is, by all accounts, the mother of all gaming drum sets. It's basically a real electronic drum kit that just has a control box that allows it to interface with your system (in my case, Xbox 360). In fact, you have the option to buy a different control box to swap in and allow you to actually play it like electronic drums - outside of the game - so, for all intents and purposes, you're buying a real instrument.

Setup is tricky, as you'll read about on the web, but not difficult, just time consuming. Part of the benefit of the kit is its flexible setup: you can position any of the pads in pretty much any position you want to customize the experience to your needs. That's actually kind of its downside, too, if you're not an experienced drummer because you spend a lot of the first few hours of play fiddling with drum and cymbal positioning in an effort to get it "just right." All of it is hand-tightened, though, so it's easy to pretty quickly get things moved around as you need. I'm trying to get my kit set up as if it were a real kit, which is made that much more difficult because I don't have any background and most stuff on the web just says "make sure it works for you." That doesn't tell me much. That said, there are several YouTube videos from helpful folks that tell you things to consider as you set up real kits that I'll probably take advantage of. For example, I found a good high-level one explaining cymbal placement.

The pads are quiet - a bit quieter than GHWT, even. They also have a nicer bounce to them and, much as it may or may not matter, a nicer surface texture. The drums and cymbals feel far sturdier than either the Rock Band or GHWT kits (as well they should) and definitely seem to be built to take a pounding. I'm not going to be putting a stick through the tops of these any time soon.

Portability is far lower than the other two kits because this thing is so frickin' big. The pads are bigger, the cymbals are bigger, and when you get it all configured, you'll find things are spread out a little more than on the smaller kits. It's also much heavier (somewhere around 30 - 40 pounds) so you won't be one-handing this one into the other room like you did with the other kits. You also probably won't be trucking it to your friend's house unless you want to spend the time disassembling, reassembling, and reconfiguring the kit. They say it "folds up for storage" and you probably could... if you don't mind re-setting it up to your liking every time.

The kick pedal on this set is, by far, the sturdiest of the three sets. All metal workings - not just metal on top of plastic or whatever. The spring on the pedal isn't terribly resistant, though, which (for me) sometimes ends up in double-hits on the kick drum because my foot gets a little out of control. I'm sure it's just a "human calibration" issue. It doesn't anchor to the kit frame, but it doesn't move around, either, because there are these two pointed screws that you can adjust so it anchors the pedal right to the carpet. (If you're on hardwood floors you can adjust it so the screws won't scratch your floor, and there's rubber on the bottom of the pedal so it will still not slide around.)

With this kit, even in the short time I've played with it, I can already tell that when I miss a note, it's my fault. Every time I miss, I instantly already know what I was doing wrong. In the few hours I played, never once did I feel like it ever dropped a note.

Something I'm quickly finding out: I am going to have to re-learn how to play. I've gotten so used to the tight setup of the smaller kits (and the lack of cymbals) that now I've got a better kit I'm actually doing worse because I have to adjust my internal timings - how far it is from one pad to another, stop using the yellow pad for the hi hat and use the actual yellow cymbal, stop using the green pad for the crash and actually use the green cymbal, etc. Not a bad thing, but something to get used to.

Summary

• I like, in order of best kit to worst kit: Ion, GHWT, Rock Band.
• If you have the choice (and the $300 to spend), go for the Ion. It is, without a doubt, the superior drumming experience. Especially if you primarily play the drums in the game.
• If you don't have the choice but can afford to get the whole GHWT band set (again, at the time of this writing, they don't sell the kit by itself), do that. Even the whole band kit is only $180 or something, which will save you some cash and get you yet another plastic guitar.
• If you're really going budget, the Rock Band 2 kit sells standalone for $50. It's not great, but it works.

We saw a huge increase in the trick-or-treat count this year compared to the previous years we've tracked.

Usually in the 7:00 - 7:30 pm time block we see a decrease in trick-or-treaters showing up; this year we saw a huge increase. We again ran from about 6:00p to 8:30p and that seemed to encompass the majority of visitors. There may have been some folks we missed pre-6:00p, but we had quite a lull after about 8:20p so shut it down at 8:30p.

• Lots more little kids this year compared to last year, where we saw average age increase.
• Halloween was on a Friday this year and I think that contributed to the increase in visitors. More parents willing to take their kids out for longer if they don't have to get up early the next day.
• We got the animated Halloween projector running and showing a "Happy Halloween" message on the garage, which I think contributed to the number of visitors. A more festive atmosphere increases interest.
• This is the second year for the new daylight saving time change due to the energy bill that passed, but I don't think it affected the trick-or-treat count.

Around the 7:00p time we ran dreadfully low on candy. With about 15 pieces left, Jenn hopped in the car and headed to the store, at which point a tidal wave of kids showed up and drained me of the last of the candy. I raided the cupboards and subsequent visitors drained me of all of my Indiana Jones fruit snacks and small packets of Swedish Fish that I nabbed from the candy jar at work. By the time Jenn got back (only 15 minutes later) I was into handing out my stash of chewy ginger candy, which is pretty spicy stuff that I'm sure caused some surprised faces on a few youngsters. (Sorry, kids, it's all I had!)

I had a few favorite costumes that came by, but the three most memorable:

• A kid of unknown age had a huge homemade fabric garbage can costume. A great costume by any count, but I had to ask where to put the candy since there were no arms, bags, or other receptacles. The garbage can rotated 90 degrees and a little flap opened with a hand poking out - "Put it in my hand."
• A middle-school aged kid was a Lego brick made of cardboard and paper. Really accurate - six Lego studs hanging out of the front, the whole thing to scale... but no arm holes, so his dad was carrying his candy bag.
• A high school kid with a banana costume, a backpack, and a plastic knife. Normally I don't like handing candy out to older kids, but when a banana shows up and yells, "I'm a banana! Put the candy in the bag!" I was dying laughing. You win - here's your candy.

A banner year for trick-or-treaters this year. Next year I'm considering doing more than just the projector on the garage. I think Halloween falls on a Saturday next year, so I anticipate even more trick-or-treaters.

Since I've set up my Windows Vista Media Center, there are two things I've been working on fixing.

First, there's some weirdness with my display resolution (TV runs 1366x768, computer will only do 1280x768), but I think that's tied to the fact that I'm using DVI/VGA instead of HDMI to connect it. I'll keep you posted on that.

Second, I'm backing up my Media Center PC every night with my Windows Home Server, but for some reason, while the PC will wake up so it can be backed up, it just wouldn't go back to sleep after that. It's not that it would go to sleep and wake up again randomly, it's that once awake, it wouldn't sleep unless I forced it back to sleep. That's the problem I fixed.

While researching, I came across this great tutorial on fixing sleep mode problems in Vista that pointed me down some avenues I would never have thought of.

The solution to my sleep mode problems:

• In power options, I changed the "Multimedia Settings/When sharing media" setting to "Allow Computer to Sleep."
• Reduced the time to turn off the display to 15 minutes.
• Reduced the time to go to sleep to 30 minutes.
• Switched to a different screen saver. This is one of those things I'd never have thought of. According to the tutorial, some screen savers interfere with the ability of the computer to sleep.

I don't know if it was just one of those things that fixed it or the combination of several, but I didn't have to turn off any of the abilities of the devices to wake the computer or mess with any other settings. Since I wasn't sharing media from the computer (though I was reading from a shared media location), I don't think it was that setting, and I can't imagine reducing the times had anything to do with it, so I'm thinking it was the screen saver.

If you're having Vista sleep troubles, check out that tutorial.

I love FxCop and static analysis tools in general. Anything that can help me write better, more standard and usable code that follows best practices is a great thing. I like running FxCop on any of my projects as part of the continuous integration cycle with all of the rules turned on.

Well, all but a select few.

See, while the out-of-the-box rules are great, there are a few that don't seem to jive with almost any of the projects I've ever been on. Here's the list of rules I don't run, and a few I consider not running based on project needs and goals.

Don't run:

• CA2210 - AssembliesShouldHaveValidStrongNames: I like being able to consume third-party components, some of which might be open source. Unfortunately, not all of these will be strongly-named, and you can't have a strong-named assembly that depends on assemblies that aren't strong-named. Strong naming also becomes problematic when you want to provide or consume a plugin framework where people can easily drop assemblies into a folder and have them registered with an app. Versioning nightmare. Strong name where it makes sense, but not everything needs it.
• CA1020 - AvoidNamespacesWithFewTypes: You run into this a lot when you have several assemblies contributing to a single namespace or when you're early in a project and you're still building things up. It might be okay to turn on later, but honestly, I never do.
• CA1014 - MarkAssembliesWithClsCompliant: If I'm working in a very small project or something entirely standalone where I don't depend on anything else, I can get this to work. If it's not just a small project or standalone, I try marking things as CLS-compliant and all hell breaks loose. I start marking individual types as non-CLS-compliant based on compiler recommendations, which causes other types to be marked as non-CLS-compliant, and eventually nearly every type is marked as non-CLS-compliant. The root cause is usually that some central class has a dependency on some third-party component that isn't CLS-compliant. In the end, it doesn't seem worth the trouble. (Of course, I only really have C# clients for my stuff, so this might change if/when I have other languages needing to consume my output.)
• CA1805 - DoNotInitializeUnnecessarily: This is basically, "Don't say 'bool x = false;'" because initializing fields to default values is redundant. I'm a huge fan of being explicit, though, and while it might be redundant, the microperf you get doesn't outweigh the long-term readability and maintainability of the code.
• CA2243 - AttributeStringLiteralsShouldParseCorrectly: This one says that any string literal that you pass to an attribute needs to be parseable into a System.Uri, System.Guid, or System.Version. That's crap. Metadata attributes can be used for so much more than conveying those three types of information and ignoring every instance of where you might want to do that is just a pain.
• CA1016 - MarkAssembliesWithAssemblyVersion: Most of my projects run in continuous integration and it's the responsibility of the build server to properly assign the assembly version... but we run static analysis on developer environments, too, and a developer build is always version 0.0.0.0, which equates to "no version" and fails this rule. I know the assembly will be properly versioned in production so I don't need a rule constantly popping up warnings in a development environment to tell me there's a problem that I don't actually have.

Consider not running:

• CA1044 - PropertiesShouldNotBeWriteOnly: When you use dependency injection, you may legitimately have set-only properties on something. Most of the time, yeah, you'll want an associated "get" for the property, but maybe not, depending on your design.
• CA1303 - DoNotPassLiteralsAsLocalizedParameters: This one makes you localize all of your exception messages... and that's sort of painful if you're not distributing your stuff to folks who need localized exception messages.
• CA1702 - CompoundWordsShouldBeCasedCorrectly: Turning this on, when you have a domain-specific language you're working with, can cause a dictionary-related nightmare. For example, you might have "Doghouse" as a word (a legitimate compound word) and it'll say "it should be DogHouse." Uh, no. So then you get to fight with the dictionary, which is a never-ending battle. Leave this on until you start really running into it and see how much dictionary-battling you'd have to do to comply before just turning it off. One or two words, no big deal. A full grammar, problems.
• CA1724 - TypeNamesShouldNotMatchNamespaces: The description of this rule on MSDN says it'll only get raised if you have a type that is called "Collections," "Forms," "System," or "UI." I have run into this in several other cases - like a type named "MyNamespace.Security" (with security-related utility methods in it" conflicting with "System.Web.Security." Watch and see where you run into this - it may or may not be worth running.
• CA2209 - AssembliesShouldDeclareMinimumSecurity: If you haven't fought code access security before, go ahead and keep this enabled. Good luck with that. Sometimes it can be solved with a one-line assembly attribute. Most times it becomes a gordian knot of horrors.
• CA1006 - DoNotNestGenericTypesInMemberSignatures: This one says you can't, say, declare a parameter or return value of type IList<ICollection<String>> because it's confusing and hard to use. The side effect is that you also can't have things like IList<Guid?> because the nullable Guid? is considered a generic. When you're writing WCF service contracts, you really need that nullable type there because it affects the schema that gets generated and helps with interoperability. If you have a lot of these... well, this rule becomes more of a nuisance than anything. Depending on your design goals, you may or may not want this rule.
• Rules involving URLs as System.Uri instead of System.String: There are several rules that tell you if you have a method or property that has "Url" in it that it needs to be of type System.Uri instead of System.String. Particularly at a web tier, passing System.Uri around is a pain that you really don't need. In other places, maybe it's helpful. Depends on your project. These rules are:
  • CA1054 - UriParametersShouldNotBeStrings
  • CA1055 - UriReturnValuesShouldNotBeStrings
  • CA1056 - UriPropertiesShouldNotBeStrings

Every other rule I leave on, and for the most part I don't exclude warnings - I fix the issue raised. In some cases it seems sort of stupid, but when the end product comes out, it's consistent, maintainable, and consumable by others. Just the way I like it.