VS 2005 Team System

Software Development

April 2006

Two households, both alike in dignity,
In fair development,
where we lay our scene,
From ancient grudge break to new mutiny,
Where fair types makes
fair objects unclean.
From forth the cubicles of these two foes
A pair of IDEs take their life;
Whole refactored enterprise code
overthrows
Do by their merit prolong
their parents' strife.

—with apologies to Romeo and Juliet

Visual Studio and its rival house, Eclipse, have increasingly drawn developers into their spheres. As a source-code editor, Eclipse has grown into a highly functional and responsive tool, but apart from refactoring (where the Java world has been years ahead) ,Redmond has had little to fear. It's impossible to quantify, but Microsoft has always seemed to have a subliminal performance edge translating between a keystroke and the appearance of the character on the screen.

Beyond editing, though, consider what language support a modern IDE is expected to provide. Paul Vick, one of the lead architects of Visual Basic, recently listed the Visual Studio "tax" that must be paid for each new language feature. Although the details for Eclipse would vary, it must be a similarly daunting amount of code. No wonder Mike Milinkovich, who leads the Eclipse Foundation, speculates that less than 1 percent of the source code in Eclipse comes from unpaid independent developers.

IBM's acquisition of Rational and the integration of software lifecycle tools into the Eclipse platform shook Microsoft out of its complacency. This is the best thing that can happen for users of Microsoft products. Visual Studio Team System (VSTS) is the first Visual Studio release to take a serious stab at delivering lifecycle management tools. In typical fashion, these tools are geared towards those using a suite of Microsoft servers—SQL Server, SharePoint, Exchange, IIS and the like—that, not coincidentally, represent a hefty chunk of revenue for Microsoft. Also typical of Microsoft 1.0 releases, the new tools are unlikely to trigger a stampede of demand and seem to be more of a foundation for future growth.

The major lifecycle management tool in VSTS Team Server is a source-control server and integrated work-item tracking system. The server is built on SQL Server 2005 and thus has gained a robust set of enterprise capabilities such as backup, replication and scalability. Nevertheless, the source database is one of the rare examples of a digital resource whose corruption could truly be a corporate disaster, and great caution is warranted in any consideration of adopting source-control systems. An exception, in my opinion, would be for those using Visual SourceSafe. Visual SourceSafe itself has been updated but the product has a checkered past, at least for this reviewer.

In addition to the presumed robustness of its SQL Server 2005 core, the VSTS Source Control Server has several features that differentiate it from Visual SourceSafe. It works over HTTP, it is time-zone aware and it has the ability to store checked-out items on a "shelf" that's available from multiple locations. This "shelving" feature is a real boon, as it lets you work on source code from multiple computers or locations without requiring you to check-in your in-progress work. A related feature is the ability to assign strict policies to check-in so that, for instance, all check-ins must address an assigned work-item, unit-tests must run cleanly or FxCop code-analysis must be done. Also, you can require check-in approval by those in certain roles (code reviewers, security auditors and the like).

Project management in VSTS rotates around the concept of a "work-item," which Microsoft uses to refer to both bug and feature tasks. Work-items in VSTS flow between Microsoft Project, Team Server, Exchange and Outlook, SharePoint and even tools such as Excel or Word. Such integration is a double-edged sword, with lock-in the price to be paid for coordination. I suspect that the number of development teams that have all these pieces already in place is surprisingly small.

In addition to server-side features and their client-side views, VSTS introduces a number of new tools into the IDE itself. The most dramatic of these are built on top of new infrastructures for testing and for modeling. The most controversial aspect of VSTS is that Microsoft has created separate SKUs to emphasize these different infrastructures. Most people get their Visual Studio installation from MSDN subscriptions and, generally, an MSDN Universal subscription has been standard for professional developers. With VSTS, though, subscribers must choose from one of three SKUs (Architect, Developer or Tester) or pay a high price for the complete suite of functionality.

Architect

The modeling infrastructure is the more controversial of the two. Naturally, at this point, when you say "modeling," people hear "UML." The Unified Modeling Language has been at the center of modeling discussions for more than a decade now, and its specification has been standardized by ISO. Microsoft's position is that the UML has two significant problems: It's centered on describing application behavior and thus comes into conflict with source code, and the way these conflicts have played out over the years have made UML too unwieldy for extension. There's certainly some merit to these points, but the competitive alignment of Rational and IBM is the real issue.

Microsoft argues that it supports UML in a Visio-based tool and says that a third-party could develop a UML modeler using the new modeling infrastructure. This isn't really true. Although I love Visio, Microsoft's UML tool is simply not in the same league with serious UML modelers such as Rational Software Architect, Borland's Together or Visual Paradigm's eponymous product. Third-party modelers are available (notably, Visual Object Modeler's Visual UML), but at this point, Microsoft's tools for building modelers on top of its infrastructure are immature.

UML aside, the visual modelers in VSTS for Software Architects make a compelling case for Microsoft's stance that UML is not the broad umbrella it purports to be. Some of the clearest slam-dunks in the release—the visual designers for logical datacenters, system configuration and deployment—are compelling products for large corporations. These visual designers let you specify the software, hardware and network environment of a service-oriented deployment. Small and medium businesses whose servers fit in a single rack probably won't see these as important tools, but the value will be immediate and obvious to anyone who's worked on (or, like me, studiously avoided being sucked into) a moderate- to large-scale datacenter deployment. I do wonder, though, if such deployment design is really in the realm of an "architect."

One thing I do know is that part of the job description is writing code, and that means writing unit tests. The most important change in the mainstream of software development in the past five years is the integration of unit testing in the development of managed-code solutions. Wrongly, the testing infrastructure isn't surfaced in the VSTS for Architects product. Short of buying the $10,939 Team Suite SKU, you must choose between the visual modelers and the testing tools. At this point, the testing tools are more compelling.

Tester

This isn't to say that the testing tools are perfect. NUnit's "Keep it green, keep it clean" has a Spartan purity that makes it easy to integrate into your development process. VSTS, on the other hand, allows testing to be approached in a variety of ways. Test runs can be run under the debugger or standalone, individual tests can be selected, and so forth. Sadly, for all of the flexibility and variety of test functions, FIT (table-based description of test inputs and outputs) is not supported.

Developer

VSTS for Developers combines the unit-testing infrastructure with the Visio-based modeling infrastructure. It subtracts the deployment-centric modelers of the Architect version and the load and test-case management tools of the Tester version. The trade-off is a poor one: If you can forego the modelers, VSTS for Testers is the superior SKU.

Inside the Box

Microsoft supports four languages in Visual Studio: C#, Visual Basic, C++ and J#. C# and Visual Basic are the .NET heavy hitters. C# is, despite Microsoft's denials to the contrary, first among equals in the .NET world, and the 2.0 evolution of the Common Language Runtime (CLR) was largely foreshadowed by work in C#. Of the CLR changes, the most dramatic is the addition of generic types. Most commonly seen in collection libraries, generics mix a generic set of behavior with the type-safety of a specified class.

The necessity of generics has been debated. Fans of languages with implicit typing (so-called "dynamic languages") aren't interested in type-safe declarations. Others, such as Java pundit Allen Holub, say they don't provide enough value for the complexity they introduce. Personally, I'm a fan of explicit typing, but I do think there's merit to Holub's point. Indeed, in the world of Visual Basic, although generics are supported, they don't seem to be a focus of discussion. (All .NET languages must be able to at least consume generics. All of Microsoft's languages both consume and produce them.)

The implementation of generics in the CLR is interesting. In C++, the instantiation of a generic-type is done at compile-time—the compiler produces a different binary type for each instantiated generic type. In Java 5, the type-safe language syntax is backed by a single runtime generic type that stores Object references. This is far more compact than the C++ model, but requires value types to be boxed and unboxed (converted to and from Object-based reference types). In the CLR, if the type-argument of a generic type is a value type, a distinct generic type is instantiated at load time. This gives CLR generics the flexibility and compactness of Java generics with higher performance for value types.

Listing 1 shows comparable programs in C# and Java. The program is designed to highlight the boxing penalty. Compiled and run on a 2.66 GHz, 32-bit Intel machine running Windows Server 2003 in VMWare with 1-GB RAM allocated (C# v., Java JDK 5.0 Update 6), the C# program ran in 3.01 seconds and the Java in 10.109. While this likely represents a worst-case scenario for Java, it shows that the boxing penalty is real.

Other than generics, C# 2.0 is primarily a stepping-stone to the dramatic capabilities of Language Integrated Query (LINQ). Another capability that will be available across Microsoft languages, but was spearheaded by Anders Hejlsberg, LINQ combines lambda functions, type inference and clever library design to make query—not just of databases but of any collection—a first-class element of mainstream programming languages.

Visual Basic (another product dropping the .NET brand), on the other hand, looks back in this release and attempts to reestablish enthusiasm with a community that resisted the move towards a fully object-oriented language. While I thought that VB.NET was a great advance over previous versions, many in the community felt that they were being asked to rewrite working applications for no immediate benefit. Some went forward with VB.NET, many moved to C#, and some dug in their heels and resisted .NET altogether. Visual Basic introduces the "My" namespace, which is intended to cut through the complexities of the Base Class Library and provide instant access to helpful objects. It also marks the return of Edit-and-Continue, a much-beloved feature.

At last fall's Professional Developer's Conference, Microsoft showed some of the capabilities of "Visual Basic Code-Named Orcas," including LINQ and integration of XML literals directly in the language. As with C#, this version of VB seems like a step towards these momentous changes.

In C++, though, the momentous change has arrived in the form of C++/CLI, an extension to the C++ language that adds "handles" to managed objects as first-class language entities, in a manner that's similar to pointer syntax. Additionally, garbage-collected managed objects can be instantiated with the gcnew keyword and finalized deterministically (a notable improvement over C#). While Visual Studio 2003 provided access to managed objects via double-underscore extension syntax, the handle syntax is much easier to use.

C++ also excels in its flexibility for writing applications that either bridge or mix the managed and unmanaged worlds. You can write DLLs with complete control of the entry point, convert between myriad string representations, exploit Win32 features, and, in the managed realm, Microsoft likes to say that "there is no lower language for the CLR than C++, including the Common Intermediate Language" (an exaggeration, but it shows where their heart is).

C++ also has several new features that are of interest to native programmers, including implementations of the "security enhanced" functions in the standard library (strcpy_s() et al.); an implementation of OpenMP, which allows for shared-memory parallelism for certain types of operations (typically applying an algorithm to every value in an array); and increased device support (finally, native development for Windows-based smartphones can be done in Visual Studio).

Speaking of devices, Visual Studio 2005 increases the range of devices targetable by all languages. The .NET Compact Framework has gained P/Invoke functionality, the lack of which was a significant hindrance to development. The .NET Framework now has both 32- and 64-bit implementations, which will run side-by-side on 64-bit Windows (and likely guaranteeing that the phrase "DLL Hell" will be around for at least a few more years). C++ can, of course, target 64-bits natively.

The IDE

The only form-builders in the same league as those in Visual Studio 2005 are those in Visual Studio 2003. Windows Forms is the best high-product-ivity library for creating forms-based native applications and ASP.NET 2.0 should be at least a finalist, if not the winning choice, across a broad range of dynamic website scenarios. Rather than spend hundreds of words justifying that statement against all the alternatives, just loop these words as many times as appropriate: While this is inherently a subjective statement, the Microsoft design-time experience seems to respond more quickly, the comprehensiveness of the Base Class Library is invaluable and its potentially intimidating size is tamed, in large part, by Intellisense.

One of the items on Paul Vick's "language tax" list was "refactoring," whose integration into the IDE has been long familiar to the Java world. Sadly, the first efforts from Microsoft in this area are unimpressive. C# has a handful of refactorings, but they pale in comparison to those in IDEA or Eclipse. JetBrain's ReSharper or Refactor! Pro (www.jet brains.com) are still well worth their cost as add-ins to Visual Studio.

Microsoft has put more effort into "snippets," which are essentially templatized code blocks to automate common (or difficult) tasks. The idea seems like a good one, but I've yet to find myself incorporating them into my day-to-day development. Perhaps that will emerge over time; there's no good reason to write virtually identical property code a million times.

The biggest problems with Visual Studio 2005, though, seem to relate to refactoring and Intellisense. In this age of blogs, where any complaint can echo loudly, it's difficult to get a good sense of the comparative stability of VS2005, but there are complaints about its stability. I know of three serious defects in the product, all of which seem to be related to Intellisense or refactoring: in C#, passing a derived type as the type-argument to a generic super-class (a legal, but hard-to-imagine scenario) can cause the CPU to spinlock; in VB, combining a bitshift operator with the ToString() method can crash the IDE; and in ASP.NET, the C# refactoring deteriorates exponentially with the number of pages in the site. There are also reports that design-time exceptions propagated from, for instance, databinding components, can crash the IDE.

Microsoft has announced that they plan to release two service packs for Visual Studio 2005. The first is expected by mid-year and will, it is to be hoped, address the stability issues. The second is rumored to be a major service pack that delivers new functionality, presumably including such things now in CTP release as WPF designers, improved tools for domain-specific languages and perhaps even the elevation of IronPython to the pantheon of mainstream languages.

Conclusion

Visual Studio Team Suite is essentially a domain-specific stack of technologies. The 2.0 version of the Common Language Runtime and its languages have been improved in terms of stability and performance (to meet the demands of, among others, the SQL Server team), but with the exception of C++/CLI, are essentially incremental improvements. The IDE has gained two major infrastructure components in the modeling and testing infrastructures. The modeling infrastructure, while it has great potential, is not yet exploited as well as the testing infrastructure, which is immediately attractive. Visual Studio Team Server is an important new server product from Microsoft that has great potential and doesn't seem overly attached to a single development methodology. However, a commitment to brand new Microsoft technologies and a level of faith in these 1.0 releases is required to fully exploit Team Server.

Of course, for most Microsoft shops and developers, moving to a new version of Visual Studio is just a matter of time. For those with MSDN Universal subscriptions and the choice of upgrading to just one SKU in the Visual Studio Team System lineup, I recommend Visual Studio Team Edition for Software Testers, unless the current modelers in the Architect's Edition are immediately compelling to you.

Larry O'Brien is a software engineering consultant and industry analyst. He can be reached at www.knowing.net.