If you look at all OSS projects out there (the good one's anyway), they don't even check in their AssemblyInfo.cs files, as these are auto generated when you run a build and the version # is just an MSBuild or NAnt property.  CC.NET should track the version number in its local project state file and pass that into the build script, or the version should be deduced from source control meta data.  Here are some typical responses from developers why they like keep version numbers in a text file checked into source control:

1. But what if we need to do a local build which needs to be versioned with something besides 0.0.0.0?  Why on earth would you ever need to do that?  Local dev builds should never be official, thus should never be deployed.  The continuous integration server is the integration point, not your local desktop.
2. But I need to use a specific version because my assembly is strong name signed to a specific version and I want to hot swap a DLL for testing purposes (or something more sinister).  If you really, really want a local versioned build, override the script's version property, but really you should be using a binding redirect in your app.config.
3. What happens if the build server dies and we lose the state file?  That's why you label source control with the version # every build, which you can use to build a new state file on the new CC.NET server.
4. We don't label source control, so now what happens if the autobuild server dies? You do output versioned builds somewhere don't you?  Look at your last build and rebuild your state file.
5. But, but, but...  That's how I've always done it.  Why? Sure its nice to keep everything in source control, but in this case there's no need.  Really you should be using the meta data of your source control system to manage build version increments, not some text file in source control.

While your removing your version.txt from your source control system, consider switching to SVN while your at it.