We recently got bitten by a tricky bug in our web service (asmx.) One of the returned classes had a setter marked as internal, and the serialization failed for an HTTP Post request.

Now you’re thinking, “What’s tricky about that? XML serialization doesn’t work with readonly properties.”

But you would be wrong. The service passed all of our automated tests just fine. These were Visual Studio web tests, set up by default to send SOAP requests. When SOAP headers are sent, the SoapServerProtocol happily uses XMLSerializer to serialize the return value, complete with internal or private properties.

I’ll jump in here with the moral of the story: if you want to ensure that serialization will work regardless of how your service is called, then it should be tested with both SOAP and Post requests – or perhaps just Post, as this is the more restrictive.

Another option, if you aren't doing integration tests, is to add unit tests which simply serialize the service's arguments and return values. These should catch any new or changed properties which break serialization - assuming that they're kept up to date with the method signatures.

The explanation is more complicated. Two different ServerProtocol-derived classes handle these requests: HTTPServerProtocol and SOAPServerProtocol. They both use XMLSerializer.FromMappings() to create the XMLSerializer which handles the return value. This method is “not intended to be used directly from your code,” according to MSDN.

I attempted to use the Microsoft symbol server to step through the creation of the serializers, but it didn’t want to give me the appropriate web service classes. And .NET Reflector got tiring before I tracked down exactly what was going on. But somewhere in there is the capability to construct and use XMLSerializer in such a way as to serialize readonly properties – something that isn’t possible with the methods intended for public consumption.

We’ve been having a little difficulty around the office with code reviews. We want to do them more often. There are all the usual conflicts about finding the time and charging the client for it, but additionally there’s a whole lot of confusion about what constitutes a code review.

So here are a few of my thoughts.

1.) Code reviews are about fixing code.
They can and should help the people involved learn from their errors, adopt better practices, and write better code. But what's the point of examining a piece of code and finding its weak points, and then leaving that bad code in your project? Fix it! Fix it now! Fixing the code while the code review is fresh in you mind will help make the review's lessons more concrete, and teach you how to implement any abstract concepts. It will help you remember what you've learned, for the next time you need it.

2.) Code reviews are not post-mortems.
This follows from point one. If you do a code review near the end of the project, when QA is well into their testing, then you can't go in and fix the code. Though the point is to make it better, you can always introduce new bugs. Thorough Unit tests greatly reduce the risk of refactoring, but it's always there.
Do code reviews early, so code can be refactored before problems propagate, and before QA has tested affected areas. If the code is off-track, finding and fixing the problem early reduces the effort needed to fix it, and greatly increases the likelihood that the fixing will get done. Management is not going to let you refactor the whole data layer when QA is almost done.

3.) A code review is a discussion, not a report.
A code review might find bugs, or clear violations of company coding policies, which are unequivocally wrong. But mostly it's about best practices and design principles. Very often there are pros and cons and underlying reasons, that aren't immediately obvious. And often these are matters of opinion. It's not about imposing rules and telling people what to do. It's about learning the reasoning, the "why," so that we can apply these lessons to new situations.
For this reason, a code review isn't just an enumerated list of things that were done wrong. It's a discussion about how everyone can improve their code.
And the more people in the room, the better, on both sides of the table. If we're going to talk about best practices, let's all benefit from it.

I’m studying for the SQL 2008 Database Development exam, and of course learning all sorts of interesting stuff.

Object ownership and permissions got more complicated with the introduction of schemas in SQL 2005. I stumbled over one of the practice questions dealing with permissions; it set up a scenario with a procedure which selects from a table, and asked which permissions were needed to run the select procedure. The answer: both EXECUTE on the procedure and SELECT on the table.

Say what? How have I never had to grant permissions on the underlying objects? After much searching I found this in MSDN:

Regardless of the execution context that is specified in the module, the following actions always apply:

• When the module is executed, the Database Engine first verifies that the user executing the module has EXECUTE permission on the module.
• Ownership chaining rules continue to apply. This means if the owners of the calling and called objects are the same, no permissions are checked on the underlying objects.

Typically your objects are owned by dbo, so you don’t have to worry about permissions on underlying objects.

The ALTER AUTHORIZATION statement can be used to change ownership. But how do you determine the owner of an object? Interestingly, this isn’t shown in the SQL Management Studio dialogs. You’ll need to query the system tables to find the owner:

select DP.name, DP.type, DP.type_desc from sys.objects SO
join sys.database_principals DP on DP.principal_id = SO.principal_id
where SO.name = 'TestTable'