Choosing which Service Pack of the .Net Framework to build against

I have read many questions (and answers) around here that had similar sounding terms in them as this question, but all of them ended up being about building against different major versions of .Net. I am in much deeper trouble, unfortunately.

Here is the story. Our customers use version 2.0 of the .Net framework. Just 2.0, no service packs at all. Our developers used to use .Net 2.0 SP1, which worked fine. Now, due to other projects we are working on, the developers (myself included) updated to .Net 2.0 SP2. And this is where the trouble began. Apparently, in its infinite wisdom, MS decided to change/add API to the framework without incrementing the major version (to, say, 2.1). So when you build against 2.0, it builds against 2.0 SP2 (if you have it installed) and there doesn't seem to be a way to configure it. So the developer can now write code thinking he is targeting 2.0, but it won't work on the customer machines!

We have noticed that certain builds (done using msbuild) started failing on our test boxes, but work fine on the developers' machines. Obviously, because the test-box is setup the way client machines are, and their older framework is missing some of the APIs. Now the build farm is going to install the newer version of the CLR (including spervice packs and higher major revisons) to test all our projects, so the builds that use the API that are not in original 2.0 will no longer fail... this is terrible news for compatibility testing.

So my question is this. How to build (using msbuild) against a specific CLR revision (of the same major version). Failing that, how to make sure VS2005 throws an error when a particular project uses features incompatible with particular revsion of the CLR (to throw a wrench into the cogs, no FxCop or similar integration, basic VS2005 features only)?

If the above questions do not have a positive answer, I am all for seeking alternatives.

Thank you.

The problem is that developers (especially new ones, or some that are porting code from other projects) tend to introduce incompatible API calls. Right now it is completely transparent to the developer and there is no way of catching yourself without creating a blacklist and have developers constantly check against it whenever they add something.

Alex K 2009-07-15 22:45:57

Surely if you find that you need to update the SP of your framework then it makes sense to get your clients to follow suit, otherwise you are developing for a known flawed platform. That said, isn't every platform flawed? ;)

Lazarus 2009-07-15 22:51:12

After all, the upgrades are free (and yes, I accept that there are costs associated with performing the upgrade (if you don't have a deployment solution for your infrastructure). Also, if the workstations haven't received this update then what else haven't they received and how much additional support time gets wasted supporting known faulty environments. Back to my first comment again ;)

Lazarus 2009-07-15 22:53:34

They actually do a good job of keeping up do date otherwise, but are categorically against updating framework version... it is not possible for us to change their minds (we've been trying for a very long time now).

Alex K 2009-07-15 22:56:20

@Alex K: You've got the perfect technique for catching problems: use Continuous Integration, and deploy the build on a system with your _minimum_ requirements (.NET 2.0 RTM). If it doesn't build, spank the developer who used the new API. Also, I believe that FxCop (Code Analysis) will spot this, at least for some service packs.

John Saunders 2009-07-15 23:12:31

@Alex K: You might remind your customer that bug fixes are a Good Thing. I hope they at least accept security hotfixes to the Framework.

John Saunders 2009-07-15 23:13:33

@John, I wish they would see reason, I really do. As for the clean build machine idea, that is pretty much our current course of action. But the tool that does integration testing is the same tool that developers run locally to setup their environment (check out code for the first time, get dependencies, make first "known good" compile). And management is leaning on us to make that tool not compile invalid code on developer's machine. This appears impossible, since we can't select particular Service Pack to compile against. Most developers don't like this. I'll push for FxCop, I use it myself.

Alex K 2009-07-16 01:12:19

@John, while I consider your second last post in this discussion to be the closes thing I am likely to get to an answer, I can't up-vote a reply, and I don't think your OP is an very answer-like. Sorry if it is going to looks like I don't acknowledge your answer as such.

Alex K 2009-07-16 01:16:10

Checking your link, I find that it was because you were using the AJAX Control Toolkit, which you rebuilt against 3.5 SP1, is that correct? Did you report this as a bug on Connect (http://connect.microsoft.com/visualstudio/). I know it was reported on Codeplex, but Connect goes to the product group, who should be told why not to change inheritance hierarchy in an SP.

John Saunders 2009-07-15 22:51:14

No, it came from another portion of my code; I just posted the resolution of the issue to the AJAX Control Toolkit bug report. As for reporting it to Microsoft... if I report it as a bug maybe they'll pay attention to it for future releases, but the damage is done.

Randolpho 2009-07-16 02:34:26

ansaurus

tags:

views:

answers:

Choosing which Service Pack of the .Net Framework to build against

related questions