Author: Scott

I asked a group of consultants currently working in my office for advice on which FxCop rules were actually applicable to our environment.  One particularly useful piece of advice was to consider whether or not unknown people or applications would be using what I’d written.  It allowed me to disable the following rules:

• Mark assemblies with CLSCompliant.  Since there won’t be any third-party users of the assemblies I ran FxCop on, that rule can go away.
• Mark assemblies with ComVisible.  The same argument as above applies to this rule.
• Assemblies should have valid strong names.  Once we get certificates, we would reactivate this rule.

I’ll revisit the list periodically to make changes as I improve my understanding.

Eric Sink wrote this post in favor of code coverage.  I wasn’t terribly familiar with the concept before two years ago, and my current job is the first one where I’ve seen such tools used seriously.

The best applications our organization puts out (correctness, performance, ease of maintenance) are the ones that have unit tests.  The application I have the most confidence in though, is the one that has code coverage.

I’m trying to develop that habit for the code I write, so I can be a better example to the team I manage.

Eric Sink’s post on requirements is the best and most concise treatment of the subject I’ve read yet.  The document vs. database treatment of requirements and his comparison of traceability to a compiler are inspired.  He even touches briefly on the shortcomings of bug-tracking systems as requirements management systems.

I haven’t read the book he recommends in his post (Software Requirements, by Karl Wiegers), but I have no doubt that it’s good.  The book on requirements that I can vouch for is Exploring Requirements: Quality Before Design.  It has tons of great advice on the process of gathering requirements.
If you analyze, design, build, and/or test software, read Eric Sink’s post.  If you manage technology projects, you should definitely read it.  Highly, highly recommended.

They’re ok if all you want to do is display data in a GridView control (and sort it, page it, etc). They become a pain in the neck the moment you actually want to modify data. The only I could get modifications to work is was by naming the parameters of your class methods exactly the same as the table column names (I’m using strongly-typed datasets in this application). I suppose it’s not so bad if you’ve named the table columns sensibly. But the database I’ve inherited doesn’t have this property.

What’s worse is the error messages you get when you haven’t configured something correctly. You get an entirely unhelpful message like “ObjectDataSource could not find a non-generic method that has parameters”. The number of search results for that phrase should have clued me in that this control was sketchy.

That’s one of the drawbacks of these new controls from Microsoft. They’re supposed to be better than code you’d write yourself–but God help you if they don’t work and you have to figure out what’s wrong. It’s not like you can debug them.

I came across this opinion on software patents via the programming reddit.  It makes a great for why software patents are a problem without even mentioning Microsoft’s foray into patent trolling.

Stallman makes an interesting proposal for a new software-only form of intellectual property (IP) at the end of the piece.  Unfortunately, I don’t think it would survive the gauntlet of legislators (and lobbyists) to become law.

While trying to find information on what exceptions a table adapter could throw, I came across this blog post from Scott Guthrie on how to build a data access layer with XSDs in Visual Studio 2005. It’s a nicely-done set of tutorials with plenty of explanations and screenshots. I’m particularly interested in tutorial 8, which describes how custom code can be added (via subclassing or with partial classes). I’m responsible for one application that could probably make great use of this technique.

One of the concerns this technique raises is tight coupling with the database.  An older article by Brian Noyes provides a comparison between strongly-typed datasets and custom business objects that covers the issue quite well.