Tools
Tools
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!
In his blog, Peter Himschoot suggests the creation of a Belgian User Group (BUG, for short :-)) centered around Team System. I think this is a great idea and I'll certainly join and do my part. If you'd like to join too, send an email to peter@u2u.net and let him know!
In the meantime, I've been "playing" with Team Foundation Server Beta 3 and I really love it. My methodology of choice is MSF for Agile Software Development, which is very very close to the pragmatic mix and selection of best practices from other agile methodologies (MSF, XP, Scrum) that I once concocted under the name "Smart Development". Team System is great for every team that wants to keep its eye on project progress and deliver a quality product.
In short, Team Foundation Server is the back-end part of Team System that supports collaboration, project "planning" (work item tracking), bug tracking, daily build processes etc. You can develop software using Visual Studio without using Team Foundation Server, of course. But I really recommend using the tool, even if it's still just a beta, because it's so incredibly valuable. It integrates agile development processes right into the IDE, as they should be. For instance, the tool generates a team website for you, where you can post announcements, downloadable tools, conventions documents etc., and where build and unit test results are automatically posted. You can also keep track of the number of work items that still need to be done, the amount of work already done in the current iteration, etc. The source code control system is really powerful, and checkin policies make it possible, for instance, to disallow checking in code that doesn't build. How great is that??
Incidentally, if you have an MSDN Subscription, then you can download a great virtual PC (VPC) image with Team Foundation Server Beta 3 and the RC version of Team System on it, complete with a sample project (AdventureWorks, of course).
Last week, Microsoft officially launched Visual Studio 2005, SQL Server 2005 and BizTalk Server 2006 (although the latter isn't really out yet -- they are launched together because, once BTS 2006 will be ready, the three systems form a very compelling and well-integrated platform together). I was at the launch event in my native Belgium on Thursday, in the honored presence of none other than S. "Soma" Somasegar, Vice President of Microsoft and responsible for the Development Division ("Dev Div"), and some of his "crew".
Most of us have already worked, or played, with the beta and CTP bits of Visual Studio 2005 and SQL Server 2005, so we already know what great environments these are. Now that the RTM bits are out, I'm sure more companies will feel at ease to ship their .NET 2.0-based products or to start development. So if you're reading this and you're still doubting whether or not to switch to .NET 2.0/SQL Server 2005 already: go ahead and make the jump now! You'll love it. If you're not sure, try it out first -- either by downloading the free Visual C# Express, Visual Basic.NET Express, Visual Web Developer Express, Visual C++ Express, Visual J# Express or SQL Server 2005 Express right now or by visiting the Visual Studio 2005 Hosted Experience, which is a web-based tool for remotely trying out Visual Studio 2005 without any cost, downloading or installation effort on your part. There's no excuse for staying away now!
Of course, the Visual Studio 2005 team is already looking at the future. Until March, they'll be spending time in support mode and will be performing internal reviews so as to improve their development processes even further for the next version, code-named "Orcas". Soma and his team were kind enough to talk to a number of influential architects and consultants during the launch event in Belgium, and stated that Orcas will definitely contain more testing and architecture tools. For instance, the team is currently evaluating what they can include to automate testing of user interfaces. Other areas of focus are improvement of the ease of developing multitier applications, further extending the languages, etc. As Soma and his team are also looking into shortening the release cycle. This may mean that Orcas will become Visual Studio 2007 some day... Looking forward to it already? You bet!
Visual Studio 2005 really is a dream environment for any serious .NET Solution Architect or Developer. The built-in designers, the great new CLR and the language extensions, super new controls etc. make designing and developing complex applications less of a hassle. And as you may have derived from some of my previous posts, I also really dig automation of mundane tasks such as daily builds, build verification tests and of course coding and documentation of Data Access Layers, collections and the like. Enter Microsoft's Software Factories initiative.
A Software Factory, basically, is any automated process that generates software; be it code, a model, a spec, whatever. Software factories make the process of designing and building software less error-prone, faster and easier, freeing us up to focus on the interesting bits. And one of the absolutely coolest new things in this area is Microsoft's GAT.
The Guidance Automation Toolkit (GAT)
This toolkit is a freely-downloadable package from Microsoft's Patterns & Practices Group. Currently still in an early CTP version, GAT makes extending Visual Studio 2005 a lot easier than using the traditional means -- i.e., creating Enterprise Templates or writing plugins that talk to EnvDTE and the like. With GAT, architects and senior developers create guidance packages for their teams, for instance to auto-generate code and documentation, to quickly implement common domain-specific design patterns, etc., all according to company or team standards.
Without GAT, such guidance is hard to create. With the current version of GAT, it still isn't super-easy (some XML handcoding is still required) but it's already a big improvement and we can be sure that the RTM version is going to kick some serious butt.
GAT contains a set of tools which are really layers on top of Visual Studio's extensibility mechanisms -- actually, to be really purist, GAT builds on top of the Guidance Automation eXtensions (GAX), which form another layer of abstraction on top of Visual Studio's APIs.
For instance, using GAT it's easy to create wizards which connect to databases and auto-generate Data Access Layer (DAL) code, Business Layer code, database schema documentation, etc. In fact, one of the samples of GAT demonstrated at Tech-Ed this year did just that.
At the core of GAT are concepts such as "recipes", "templates" etc. A recipe is basically a template for a use case. Recipes consist of actions which create, modify or delete "artifacts" (such as code or XML) in Visual Studio. Recipes can be parameterized and the parameters' input can be fetched from the user (using wizards), XML configuration files, databases etc. You can group related recipes and templates in Guidance Packages and distribute them in your team or on the Internet.
Part of the GAT is T3, the templating engine with the cool name which will sadly be renamed T4 by RTM for reasons that are probably better left obscure. The T3 templating engine is similar to CodeSmith and uses a syntax similar to ASP's HTML/code mixing: embedding code between <# ... #> tags in output such as XML, HTML or code.
Resources:
This morning, Scott Hanselman presented his rather interesting talk on Code Generation (ARC305). I have mixed feelings on the subject -- I love the idea of generating chunks of code but I usually loathe the quality of the code. On top of that, often generated code can't be modified or built upon easily. For instance, I love the fact that you can generate typed DataSets using the xsd.exe utility, but the code it produces is really bad and you can't add stuff to it, such as raising an event when a certain property changes -- which is what I like to do. Anyway, back to Scott's presentation.
The basic idea of straight code generation is to build a specification, or call it a domain model if you will, for instance in XML files. You then have these XML files parsed, maybe along with some code templates (think CodeSmith or RapTier again), producing source code or compiled output (as in the case of xsd.exe). The key to making it successful is to shape it to fit your development processes and the domain you're working in. Obviously, if you're building small smartphone apps your code-generation procedure and the output is going to differ from your missile guidance system project. So you can make the input format (the XML schema for the domain models) as simple or as complex as needed, and provide very complex and flexible or very simple input templates.
Of course, you don't have to limit yourself to generating source code. You can generate documentation and unit tests as well, possibly even Word documents (using WordML) or, why not, Excel sheets with statistics?
Personally, I like to work with automated build systems that generate compiled Help files too, by tweaking Visual Studio.NET's project files before compilation (so that XML generation is turned on) and running NDoc on those XML files after compilation. In addition to code-generating tools such as CodeSmith, I also like to use ReSharper's template functions to automatically generate properties that raise xxChanging and xxChanged events, check for null input and the like. That's code generation too, but not the command-line variety that Scott was talking about. Digressing again...
Scott raised an interesting point when he talked about using WSDL as your specification language. Yes, WSDL was originally created for specifying the public APIs of web services -- it stands for Web Service Description Language, after all -- but that doesn't have to keep you back. Why not just use WSDL's syntax to specify entity classes, data access operations etc.? All you have to do is leave out the binding part and the Web Service discovery part of the WSDL, or replace it with something more meaningful to your code generator.
What's also nice about Visual Studio 2005 and .NET 2.0 is the partial classes feature, which fixes, in a sense, the “I can't edit this generated code” problem. To put in code that can't be generated off your model, you can tweak your code generator to output partial classes and then add code in other files that together make up the final class.
Later this week there's a session planned on NHibernate, the .NET version of Java's Hibernate which claims to be able to generate entity classes and business classes off databases and custom models. A couple of Java guys I'm working with use Hibernate and they're experiencing real pains with it. It'll be interesting to see how far NHibernate goes, and if it really is the holy grail that can generate half of any client/server app's code... Stay tuned, more to come on that subject!
... the week of November 7 :-). This was announced at Tech-Ed Orlando this morning by Mr Paul Flessner himself. Check out the launch website at http://msdn.microsoft.com/launch2005/ to stay up-to-date!