Posted on

FxCop-compliant Exceptions (Code Snippets vs. Item Templates)

Mr Haack posted recently about a topic near and dear to my heart: inheriting from Exception. To keep FxCop quiet, there is a surprising amount of code to write when creating your own exception types, as Phil notes: make it serializable, implement four constructors, etc. It can be tedious to do that every time you create your own exception. So, code generation is definitely the way to go, however, this is where I must respectfully part ways with Phil.

After playing with both code snippets and item templates, I find item templates to be a superior method for class-level code generation. Unfortunately, in all the betas of VS 2005 I’ve tried, there is no easy way to generate an item template easily (File -> Export Template never works, although I’ve not used any of the CTPs). I’ve outlined how to do it for beta 1 in a previous article. There are very few differences with Beta 2 and hopefully RTM (elements became attributes in the vstemplate file). Then creating a new FxCop-compliant Exception class is as easy as adding any class file to a project. On the other hand, a code snippet requires a file to already exist and if you’re abiding by the Microsoft’s guidelines of one public type per file (you are, right?), then you have to do all that work up front.

But the above advice is essentially useless for everyone: VS 2005 isn’t out yet (but it’s close)! Wouldn’t it be great to get this with Visual Studio 2003? Well, you can’t by default: that’s one of the reasons VS2005 is so compelling. However, there are third party tools to help you. Before it became not free, CodeSmith allowed you to generate code at the file level, so I whipped up this template file for all my Exception building needs. Just run it in CodeSmith (v2.x if you’re lucky (and cheap)). Of course, there is the way Phil does it as well. Your mileage may vary.

Download the CodeSmith FxCopException.cst template.

To be really nice to all 3 readers at jasonkemp.ca, I also whipped up an FxCopException item template for VS 2005. Aren’t I sweet? Just drop it in My Documents\Visual Studio 2005\Templates\ItemTemplates\

Download the FxCopException Item Template for VB
Download the FxCopException Item Template for C#

Posted on

Drinking from a Firehose

It looks like another PDC is about to wind down. Just like last time, the amount of information is overwhelming. Nothing revolutionary this time, but some exciting stuff nevertheless.

By far the most exciting is LINQ (Language INtegrated Query): it’s got a catchy name and it’s got unbelievable power and potential. The coolest thing about LINQ for me is all the stuff that had to be done to enable it in the languages, especially C# 3.0: extension methods and lambda expressions being the coolest. This video will show you Anders explain it as only he can. From the demos he shows and his explanations, you get all kinds of features of a dynamically typed language with compile-time type checking: uber awesome. And they have a preview that works with Beta 2 of .NET 2.0.

Database stuff bores me to tears, so, like real database programmers, DLinq ain’t all that hot for me, for different reasons, though; but XLinq looks to be seriously sweet. When .NET first hit my school, the thing they touted most was XML: XML Web Services, XML comments in C#, XML Config files; “We make XML really easy!” But I was pretty disappointed with the verbosity and the amount of typing required to create a document or read a document. The new way, using XLinq to create XML documents right in the language, is just gorgeous. It makes creating documents intuitive and easy. Can’t wait for that.

The other things are worth noting, but nothing I’ll use daily, like the above. I’m curious to see the Office UI in action. It could definitely have a big impact on applications in the future. But making it a developer platform? Boring! Equally boring is WWF and WTF. Those definitely won’t get you laid:

Girl: What programming tools do you use?
Boy #1: Windows Workflow Foundation.
Girl(with disgusted look on her face.):   Later!
Boy #2: Python and Ruby on Rails.
Girl: Ooooh. Hello.

Posted on

The Wealthy Blogger

Our eviction two months ago really made me consider buying a place,my financial situation and my future. I’ve since taken steps to be more responsible with my money: sock some away, put some in an RRSP; stuff I always meant to do, and now finally did.

So, when Darren Barefoot pointed out the Wealthy Blogger, my curiosity was piqued. Here’s a blog from a couple of guys trying to be financially independent before they’re 35. Great advice; I’ve already learned a lot. And he’s Canadian: can’t go wrong there. Subscribed.

Posted on

Question: Where do you put your unit tests?

We recently discussed (think: hotly debated) where to put the unit tests for an assembly at work. My preference is to put them in their own assembly and reference the assembly under test. My colleague, at a bare minimum, wants them in the same assembly as the classes under test, but ideally would put the test fixture for a particular class in the same file as the class, surrounded by a #if UNITTESTS compilation flag and hidden in a region at the bottom of the file.

Each has its benefits. The former keeps the tests logically and physically separated from the library under test so that there are no references missing later on, keeps both the tests and classes under test clean of clutter and it forces one to think about only the public API, which is a large part of TDD in the first place. The latter has the advantage that internal types can be tested more thoroughly; and the presence of the test right there in the file is self-documenting in the sense that the developer responsible for the assembly, not necessarily the assembly’s creator, sees them right away; so doesn’t have to be told that they exist in some other, far-flung assembly.

You know the face you make when you smell something unpleasant? That’s the face I make when I hear of the latter alternative. So I put the question to you, my two faithful readers, where do you put them? And why?

Posted on

FxCop Globalization Rules and Exception Constructors

Update:

Looks like I was wrong again. (You know what they say about assuming?) Reflector is an even greater tool than I first realized: not only does it show the classes in an assembly, it also shows the resources for the assembly; something my eye does not see and brain does not look for, because I just haven’t been in the situation to really use them. Anyway, it shows them and every assembly in the framework that I looked at (um, two of them) have resources that are filled with? Exception messages. Interestingly, I found a way around the FxCop violation, but you shouldn’t use it unless you really, really intend to fix it later. Do you? Ok, here it is:

… = new MyException( String.Format( System.Globalization.CultureInfo.CurrentCulture, “my exception message“ ) );

End Update

I’ve been using FxCop a lot lately to fix up some of the templates in CodeSmith and some of my code at work. I get this violation a lot:

Do not pass literals as localized parameters.

Most of the cases, all if I’m not mistaken, are for messages in Exception constructors. This got me wondering:

If I install the .NET framework in French (or German, or Italian, or Thai, or Chinese,  or Brazilian Portuguese or …) do I get stack traces from thrown exceptions in that language?

If the answer is no (that’s what I think it is; especially after inspecting the framework with Reflector), FxCop should check to see to which method the literal is being passed, shouldn’t it? And if it should, I should just ignore those violations when I pass a string to an Exception constructor.

This is a tough one: 30 jk.ca points to whomever gets it. I’ll update this post once the answer is found. Good luck. 🙂