Microsoft has just released the August 2006 CTP (Community Technology Preview) version of the next version of ADO.NET. The most important new feature of ADO.NET vNext is/will be an Entity Framework which supports Object-Relational Mapping straight from ADO.NET. Does this mean typed DataSets will be a thing of the past soon? It's too early to tell, but they are surely going to be used far less in the architectures of 2007 and later...
What's also cool about it is that this Entity Framework integrates with LINQ, so you can run LINQ queries on Entity collections etc. Whenever you make a modification to an Entity object, it is marked "dirty" so that when changes to lists, collections and graphs are saved, only the dirty ones are actually saved, and then their status is restored to "clean" again. It's great to have that as part of the Framework -- I've been doing stuff like this using ReSharper templates and Visual Studio 2005 snippets, and now it's becoming standard behavior without requiring any custom coding. You can even split Entity objects over multiple tables -- so that certain properties of your entity are saved in one table and other properties in another table. It's reminiscent of Commerce Server's data aggregator.
Get it while it's hot!
Now that Team Foundation Server is finally out, it's time to upgrade Beta/RC installations to this new version. Many teams who have been waiting for TFS and who didn't want to use the Beta versions can now rest assured the final version is among us -- you can download it from MSDN Subscriptions. There's a 5-person trial version available for free.
For TFS to be installed successfully on a server, you'll need:
- Windows Server 2003 (R2 is better)
- Windows SharePoint Services v2 (downloadable for free if you're not running Windows 2003 R2)
- SQL Server (full installation including Analysis & Reporting Services)
- A couple of .NET and SQL Server fixes (delivered with the installer)
- Active Directory (optional, if you're going for a multiserver, TFS-specific environment)
- The TFS installer (obviously).
Of course, to use TFS, you'll need Visual Studio 2005 Team Edition on the client, or at least Team Explorer, which comes as part of the TFS installation.
What's interesting abou the installer is that it verifies for you (since B3 Refresh), before installing, if your server is TFS-ready. This means checking CPU, disk and memory requirements as well as installed software and running services. The installer will simply refuse to continue when there are conditions that will cause Setup to fail -- such as the SQL Server Browser service not running. This is an impressive and useful feature that I hope will make its way into many more installers from now on!
Installing TFS, in other words, is a smooth if not time-consuming procedure. You need to make sure that you have all the necessary software, and that you stick to the procedure outlined in the installation manual. For instance, when installing Windows SharePoint Services, you have to configure it for server farm use, not single server, even if TFS will be running on a single machine. That's just what the TFS installation expects. It will auto-configure all other WSS properties for you, but that one you have to set yourself. So, after all else has failed, read the installation manual...
I love Team System. My team has been using it since December now, and I haven't seen anything on the market yet that can beat it. Source code control is as smooth and fast as it is with SourceGear Vault. Unit testing is super-integrated, including the generation of unit test stubs and code coverage. There's bug tracking, iteration tracking, you name it. If you don't want to use Team System's built-in support for CMMI or MSF Agile, then you can extend it to implement your own methodology. Excellent stuff and I'm sure we'll see many commercially avalable, or freeware, extensions on the market in the years to come.
I understand that many companies or teams are not sure yet about switching to Visual Studio 2005 or Team System, because of training time and liense costs. But this system is so smooth to operate and so useful, that it pays back for itself very quickly. Just think of your team's higher productivity, less time wasted on meetings etc.
Team System rocks!!
More strange and unexpected behavior from Visual Studio Team System (VSTS)... This time I'm experiencing a problem with unit testing. I have a solution although it seems more like a workaround to me, and I haven't been able to find out the exact root of the problem. Here's the story.
I have a custom class, let's call it Customer (name changed to protect the class' privacy). This class is derived from another custom generic container class. I've implemented Equals, GetHashCode, and the == and != operators on it. These are necessary because of the class' heritage: it has to make sure that, when comparing two instances, these two instances have identical elements in their collections. So far, so good.
However, a unit test which creates two identical Customers and then compares them, fails on the following line:
Assert.AreEqual(a, b, "Equality");
(the string being a message to display in case the test fails.)
Close on-location examination of the facts revealed the startling truth that a and b were, in fact identical... But surely something must have gone wrong. After more examination, detective work, interrogations etc. I decided to try something else:
Assert.IsTrue(a == b, "Equality");
Miraculously, this worked. Did this prove that the objects were indeed equal? I added some more tests to make sure.
Assert.IsTrue(b == a, "Equality 2");
Assert.IsTrue(a.Equals(b), "Equality 3");
Assert.IsTrue(b.Equals(a), "Equality 4");
And yes, these tests passed too. So why not Assert.AreEqual()??
My mole at Microsoft was stumped. He asked if I had done an inside examination of Assert.AreEqual() with Reflector. Turns out I hadn't, so I cranked it up.
That revealed that Assert.AreEqual() depends on object.Equals() to determine equality. But then examination of object.Equals() showed that it first tries to use the == operator, and if that fails, it tries to use the object's Equals implementation.
This would seem to suggest that Assert.AreEqual() is off the hook and that the problem should actually never appear. But it also suggests that object.Equals() doesn't always use the objects' own == or Equals implementation. How else can we explain why the other tests, as shown above, all work while the AreEqual test fails? This is corroborated by the fact that code coverage testing in Visual Studio shows that the object's own Equals and == implementations are not executed by AreEqual.
My workaround solution is simple: to not use Assert.AreEqual whenever it poses a problem. After all, the code that is being tested is always going to be used with the Equals and the == and != operators, so replacing AreEqual() with IsTrue(==) etc. seems like a natural thing to do. But I do like the syntactic sugar of AreEqual, and it bugs me that I don't understand why this is a problem.
Do you know what's going on? Hey, guys in the VSTS team (Jonathan! James!), what's the story here?
It's surprising to me that, so far, I haven't been able to find any blog entry or article anywhere about why the Visual Studio 2005 Code Coverage tool doesn't handle C#'s switch statement properly.
I use switch a lot, because it's so much easier to read than lots of if/else ifs, but the fact is any function in my code that contains switch gets marked, after complete and utter unit-testing, as not having been covered 100% -- there's always one block counted as being untested. Yet every line of code in that function is marked nicely in light blue, indicating that it was run. The unit test code makes sure that all cases are covered...
Then when I rewrite the code to use if/else if/... instead of switch, coverage is 100%.
Duh! I want to keep using switch!
I bought a big-ass (42"), kick-ass TV recently, a Samsung. If you're looking for a great plasma panel TV, you can't go wrong with the Samsung line. They feature a 1024 x 896-pixel resolution (great for HDTV and use as a computer monitor), dynamic image enhancement with noise reduction and color adaptation to your taste, simulated surround sound, picture-in-picture, burn-in protection, and much more. The image quality is just amazing! Wonderful, rich colors, sharp image, just great. Far better than any LCD TV I have seen so far, and with a 60,000 hour life, you can watch TV for six hours a day for 27 years before the screen finally gives up.
To top it off, I also purchased a kick-ass multimedia PC (which I haven't installed yet, unfortunately) to turn the TV into a full-scale digital entertainment system, and a Philips home cinema to get to that full cinematic experience. This setup, in combination with Star Wars III, makes the whole house tremble!
And the really amazing thing is, this whole lineup of kick-ass entertainment technology is available at roughly 2/3 the price of a year ago: just € 1800 for the TV, € 1000 for the PC (dual-core Pentium and full multimedia capabilities including a dual TV tuner, hard disk recorder with delayed viewing, a dual-layer DVD burner and a second DVD-ROM drive, yeah!) and € 300 for the home cinema. It's cheaper than a Team Foundation Server license ;-)