Visual Studio 2005 Premieres

Visual Studio 2005 includes new language features and development tools, but do you need it? Delve into this analysis of Microsoft's much-anticipated release, plus a look at what's ahead in Orcas.

Technology Toolbox: Visual Studio 2005

The question of whether to upgrade to Visual Studio 2005 is a no-brainer for many of us. When MSDN releases the new version, we will exercise our subscriptions and install the new IDE. You can import existing Visual Studio 2003 projects and have them ready for use within minutes (but don't try going back to your old IDE at that point).

For others the decision is not as easy. It's not so much a question of whether to upgrade, but when. Most software development groups are unwilling to change IDEs in the middle of a major project. Others believe that if their current tools of the trade are not broken, there is no reason to upgrade them. And the rest are looking for reasons to move to .NET to begin with.

Does Visual Studio 2005 provide these reasons? Further, does Visual Studio 2005 better support the development of high-quality software and the ability to work as a team, out of the box? To answer these questions, I put Visual Studio 2005 to the test, importing projects, creating others from scratch, coding, testing, and prepping for deployment. I also took a look at the various flavors of VS 2005 that Microsoft will offer, with an eye toward which audience the specific versions will serve (see the sidebar, "A Word About Versions"). Microsoft serves a lot of audiences with Visual Studio, and VS 2005 pushes the reach of the tool both farther up into the enterprise with its Team editions, and simultaneously down into areas typically occupied by hobbyist, departmental, and education-centered developers and would-be developers. In the latter case, Microsoft isn't so much charting new territory as much as it is reestablishing relationships with a group of programmers it by and large left behind with the introduction of .NET.

I confined my exploration of Visual Studio 2005 to C# (see Figure 1) and Visual Basic (see Figure 2). I'm a strong believer in managed code as a quality and productivity enhancer, and a primary reason Visual Studio is what it is today is because it supports development with managed code. That is not to say that C++, managed or unmanaged, doesn't have a role in application development today, but it continues to be a diminishing role.

Visual Studio 2005 will be readily recognizable and easily adopted by veteran developers today. One of the true gifts of the development environment across versions is that developers can pick it up and use it immediately, while learning the new features over time. If you open an existing Visual Studio 2003 project, a conversion wizard opens automatically to bring it into the new version and ready it for use (see Figure 3). There are some small differences in the menus, but any Visual Studio developer will be productive within minutes.

However, new features abound, and it will take developers a while to find and use many of them. Visual Studio now features the ability to refactor classes and types. While refactoring is an environment rather than a language feature, some of the capability is available only for C#. The refactorings available include renaming, moving, and overriding type members; reordering parameters; implementing an interface and extracting from a type to an interface; and implementing an abstract class. You accomplish these activities and much more with the Class Designer (see Figure 4), a new and unique modeling tool that enables you to view the class structure of an existing application or create an application by defining its classes visually. You right-click on the class diagrams in the Class Designer to select the type of refactoring you want to implement. The Class Designer makes the appropriate changes in the diagram, and reflects those changes automatically in the code. It is worthwhile to note that refactoring is done only through the diagram and not through the code itself.

The Class Designer can also serve as a starting point for application development, minimizing manual coding while making the most from a visual design process. Build a new application by placing classes from the toolbox onto the Designer form, where you can visually add methods, establish class relationships, define interfaces, and create structures and delegates. The Class Designer makes switching back and forth between visual modeling and coding seamless, with the code and model complementing each other.

It is unfortunate that Microsoft has chosen to support a modeling approach different than the widely accepted Unified Modeling Language (UML). Microsoft's class-only approach is an easy and highly usable method of creating class diagrams that would complement any UML implementation. However, the Class Designer requires you to have a much deeper understanding of your application before beginning. In other words, you might as well use UML as your starting point anyway, and simply implement your UML class diagrams using the Class Designer.

Using the Class Designer is not the only way you can view a Visual Studio application. The document outline view, available in ASP.NET applications, provides a treeview of HTML documents that makes it easier to navigate complex Web applications. The Design view shows the elements in the body of the HTML file, and the Source view shows the body elements as well as elements in the head, the page directive, the script, and code elements.

Visual Studio 2005's Object Browser lets you examine and expand system objects in a treeview (see Figure 5). In addition to understanding and working with the class structure and methods within each class, it displays the description for all Framework classes and where they reside within the class hierarchy. And it now lets you filter and sort data by namespace, object type, alphabetically, and other characteristics.

Framework Enhancements
While the .NET Framework is not a formal part of Visual Studio, the IDE provides easy access to its features. The Framework 2.0 has a number of incremental features, including new controls, new databinding, support for generics (implemented in both languages), improved FTP and HTTP support, ClickOnce deployment, a variety of improvements to ASP.NET, and many more.

In fact, there are too many additions and improvements to detail at any length. Instead, I'll pull out a few for specific mention (see Figure 6). The BindingSource class improves the manipulation of data. It simplifies the process of databinding between control and data, sitting in between the bound control and the target data source. It helps in managing many databinding issues such as currency, data-related events, and target data source changes.

The DataGridView control provides a useful and flexible way to display data in a tabular format. ToolStrip controls are toolbars that can host menus, controls, and user controls in WinForms applications. And the WinForms SplitContainer is two panels separated by a movable bar, useful for displaying and browsing information.

For anyone who has to take their application out of Visual Studio and deploy it independently, ClickOnce deployment tries to address issues with versioning of common files, updating of specific files within applications, and permissions issues during application installation. ClickOnce is based on an application manifest and a deployment manifest, both of which are implemented as XML files. As the names imply, the application manifest describes the characteristics of the application itself, and the deployment manifest describes the location and versioning of files.

Developers often wonder about application compatibility across versions of the Framework. Microsoft claims to try to maintain both forward and backward compatibility across Framework versions, but it occasionally makes changes or deprecates APIs in the name of security, function, or simply because it didn't work right the first time.

For Framework 2.0, Microsoft has made some APIs obsolete, and makes available a reference for those interfaces. However, to be on the safe side, it makes sense to install the Framework version with which your application was built. I've run both the Framework 2.0 and 1.0 for almost a year with no difficulty in compatibility between applications using different versions.

Of course, the Framework and the languages work together, as the Framework implements classes and other features the languages are able to call upon (see the sidebars, "A Taste of Language" and "Back to the Future With Visual Basic," for a broader discussion of Visual Studio languages in general).

Of course, Visual Studio 2005 goes hand in hand with Visual Studio Team System (VSTS), the application development lifecycle platform that complements and integrates with Visual Studio in a team development environment. VSTS adds source-code control (not Visual SourceSafe), static code analysis (FxCop), performance analysis, load testing, and other features to smooth the development process and improve quality.

One innovation is the use of the rules engine in conjunction with the source-code control system. This makes it possible to enforce best practices as a part of the development process. For example, you can require team members to perform a static code review with FxCop prior to checking in a file.

While the client portion of VSTS will be available at the same time as Visual Studio, the all-important Team Foundation Server won't ship until next spring. Those seeking to integrate their existing development processes with VSTS will have to wait for the arrival of the server.

Looking Ahead to Orcas and Beyond
Microsoft could conceivably take future versions of Visual Studio in many directions. Support for new operating system features is almost a given. And based on some presentations given at Microsoft Professional Developers Conference 2005, it appears that the company has chosen working with data as the next mountain to climb.

Orcas (the code name for an upcoming version of Visual Studio that will provide support for Windows Vista) will have a pretty quick cycle as far as enterprise development tool sets go. In order to take advantage of some of the new features available in Windows Vista, Orcas must come out at around the same time, now projected for the second half of 2006. This means that there is perhaps as little as a 12-month turnaround time for Orcas (although there is no doubt that it is already under development), so don't expect too much.

Windows Vista (or Longhorn, for those of us who identify more readily with its sobriquet) will introduce a declarative programming model called Extensible Application Markup Language (XAML) that will complement existing programming languages and Windows Forms by enabling developers to use the Avalon presentation layer to build the sophisticated mix of Web-like rich-client user interfaces available with the new operating system. Avalon user interfaces written with XAML employ some stunning visual effects, including three-dimensional objects, subtle shading, and transparent and overlapping objects.

Orcas will also deliver more support for Indigo, Microsoft's new programming model for building Web services. Indigo introduces a unified model for developing connected applications on the Windows platform that makes it easier to build service components employing remote procedure calls, messaging, and remote object invocation. Indigo has few fundamentally new Web service capabilities, but Orcas will provide a far easier way to implement some capabilities, such as security and reliable transactions. Demonstrations of Indigo technology indicate that using Orcas with Indigo can reduce many complex tasks requiring tens of thousands of lines of code to just a few.

From the standpoint of language, the use of data in applications appears to be some low-hanging fruit Microsoft can exploit in that limited amount of time. Many developers write data-driven applications, yet there is little in Visual Studio beyond ADO.NET to make such development easy. In particular, while it is possible to build a state-of-the-art graphical user interface visually by selecting from a vast set of user interface components, and write processing logic in VB.NET or C# using conventional programming skills supplemented by a comprehensive help system, database access requires intimate knowledge of the database structure, plus the ability to work in SQL.

Orcas seeks to improve on that experience by adding language features to C# that make data handling more seamless. If C# were a data-aware language, for example, you could easily and seamlessly transfer data between the user interface and the database entirely in C#, without necessarily knowing the details of the database tables and fields you are accessing. Consider the improvement in developer productivity and application reliability if you could take a data item directly from a screen object and write it to the database without any intermediary structures.

This goal, in fact, might have been one of the fundamental reasons that Visual Studio and SQL Server have been made available at the same time. The first step in achieving such transparency is to provide the same managed execution environment for both the database and the language.

Other projected features for C# include extension methods, lambda expressions, type inference, and anonymous type for expressing queries and interacting with objects, XML, and databases in a strongly typed, natural way. For example, the next version of C# ties in with the .NET Language Integrated Query (LINQ) framework, which will allow you to build queryable APIs.

Much of these projections are speculation at this time, although C# architect Anders Hejlsberg and others at Microsoft have done some speaking on the subject. It is also likely that Visual Basic will continue to return to its roots as a rapid application development language for business-oriented developers. And because software development as a whole is moving in this direction, expect a greater ability to build application models graphically in both languages.

Despite the focus of Windows Vista on rich-client user-interface facilities, pure Web applications are not forgotten. Future directions for ASP.NET include the Atlas technology, which will make it easier to build Web applications that deliver rich, interactive experiences in a browser. Atlas features a JScript cross-browser client script framework for building browser-based applications with a rich user interface and straightforward connectivity to Web services.

Of course, Orcas is not the end of the road as far as Visual Studio goes. The release after Orcas is code-named Hawaii. The name of an island in the middle of the Pacific, far from the usual code names of islands in the Pacific Northwest, suggests to some that compared to its predecessors, it is quite far out (and out where the weather is much nicer). Early word claims that Hawaii will offer radical improvements in its ability to work with data in all its forms as objects, as XML, and as relational data. An abstract states that Hawaii will feature query comprehensions, object initializers, and anonymous types for querying data in a more flexible way.

Hawaii's release date is not set yet, but don't expect it soon after Orcas. Microsoft has said it wants to release two additional versions of Visual Studio by 2010. Given a late 2006 or early 2007 release of Orcas, that could leave an additional two years or more before Hawaii becomes available.

Both Orcas and Hawaii will bring forth the Microsoft vision for modeling in the design phase, not with UML, but rather with so-called domain-specific languages, or DSLs. DSLs are languages, both textual and visual, that are built on the foundation of Visual Studio languages and tools for a specific industry or purpose. The financial services industry, for example, may have a DSL focused specifically on computations of risk and return. Think of the concept as a more modern 4GL that makes developers of applications in those domains highly productive.

Before You Rush to the Store
Microsoft has long provided developers with the most comprehensive and productive general-purpose development environment available for any language and platform, and Visual Studio 2005 does nothing to hurt that image. One must ask, however, whether it breaks new ground and advances the state of the art.

This is a more complicated question. Visual Studio continues to add useful features in both language and IDE, but few seem to count as truly innovative. Some features, such as the Class Designer, are well-refined implementations of existing and established concepts. Others are language enhancements that might or might not be useful enough to go through the effort of upgrading, depending on the needs of your applications.

The ability to model the deployment environment and compose a design that matches defined constraints is a significant advance, but it is only available in conjunction with Visual Studio Team System. And some of the other VSTS features, such as the ability to define and enforce best practices in software engineering, might require that you change both your source-control software and your fundamental development practices, both of which are not done lightly.

And that might be the real problem with Visual Studio: Microsoft has taken some of the most significant innovations and segregated them into this new and more expensive product addition. To be a clear winner, you need to adopt and use Visual Studio Team System as an inseparable companion to the IDE. There is some justification for the practice of separating coding from process, because ISVs charge for lifecycle tools dependent on Visual Studio, but we are now in an era where developer tools are in a race to the bottom of the price list. Not even Microsoft has the ability to charge top dollar any more.

Getting back to where we started, if you have MSDN subscriptions across all developers on your team, upgrading is a no-brainer, and you'll get some pretty significant benefits by employing both Visual Studio 2005 and Visual Studio Team System. However, if an MSDN subscription is not in the cards, or if VSTS isn't a direction you wish to go, you are left with a largely incremental upgrade with some nice new features. In that case, you should look at the features to determine if they add to your productivity or development experience, based on how you use Visual Studio today. While there is no question that you will like much of what you see, the answer won't always be yes.

comments powered by Disqus
Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.