Some old things still matter
The Visual Studio .Net environment tried to analyze what we were doing and to offer the relevant resources that we were most likely to need next, but it made some odd choices. For example, when we dragged the icon for an existing graphical control from the Class View inspector into the adjacent source code window for the corresponding form, the source editor generated an identifier for that control that was not accepted by a simple Rebuild command. We had to strip off qualifying prefix elements from the beginning of the generated identifier to produce the intuitively reasonable object reference that one might expect in a drag-and-drop tool.
The variety of integrated tools in Visual Studio .Net comes close to the high standard set by competing tool vendors, who have gone through several product cycles in the time since Microsofts last significant update. But the source code editor in Visual Studio .Net cannot drive the visual form designer, as can the source editor in Oracles JDeveloper. If we changed the code that defines a push buttons size and shape in JDeveloper code, the visual form designer took note of that change, but in Visual Studio .Net, the link is one-way between the Form Designer and the code that it generates.
In fact, the code that describes a visual form control in Visual Studio .Net comes marked with a "no trespassing" sign in the form of a comment that reads, in part, "do not modify the contents of this method with the code editor"--an affront to any red-blooded developer.
Overall, we found the new Microsoft environment less dynamically self-aware, for example, than either JDeveloper or Borlands JBuilder, with the different tools in Visual Studio .Net sometimes not noticing each others changes to a project in progress until we took some action that forced them to pay attention.
For example, if we clicked on a graphical control in an active form designer to bring up its information in the Properties inspector and changed the name of the control in the latter tool, the corresponding entry in the Class View inspector did not immediately change. If we then double-clicked on the old (and now invalid) Class View entry, it demurely disappeared, and the controls new name appeared wherever alphabetical ordering would put it--but with none of the entries selected, so it was up to us to figure out what we now wanted to examine.
We dont think were being unfair in throwing such deliberately confusing maneuvers at a product of this complexity: If it cant keep up with us on a project thats small enough to fit on a single screen, and where we can actually see the cues that reveal the resulting inconsistencies, were reluctant to rely on the tool sets ability to keep things straight on projects of more than trivial size.
In fact, projects of more than trivial size quickly expose the weaknesses of tools that demo well in a training seminar, but that may not stand up to enterprise demands. Visual Studio .Net is supposed to be the workbench of the developer whose world is defined in XML, and its visual XML schema editor ought to be one of its highlights. We naturally applied that visual tool to one of the environments own XML schema files, the ie5_0.xsd file that contains editor autocompletion data, with rather disconcerting results.
Our 1GHz Pentium III development system needed almost three minutes to render a visual map of this schemas 4,900-plus lines of XML text; any sustained navigation through the resulting display quickly pegged the CPU utilization measurement at more than 80 percent, while bringing up the complaining whir of the processors temperature-sensitive cooling fan. Its not often that you can actually hear the sound of a machine being brought to its knees.
The XML editors Schema Overview window was completely ineffective in aiding our navigation through this file, since the visual layout was one long horizontal row of hierarchical trees that the overview map condensed to barely more than a single row of pixels. When we moved to the more responsive text view of this file, the environment seemed unwilling to let go: It would revert, spontaneously and unpredictably, to the visual navigation tool without changing the state of the visual control that ought to have been our toggle between the two states (while the fan played on).
Ordinary source code editing will look familiar to Visual Studio users, which is to say that the editor still has not caught up with convenience features that have long been present in other programmers editors such as Mansfield Software Group Inc.s KEdit or SlickEdit Inc.s Visual SlickEdit. We could find no way, for example, to collapse the view of the source file to show only lines containing an arbitrary pattern (or even just a particular string) of text. It was possible to "Mark All" lines that fit a search condition and to move among them with "Next Mark" and "Previous Mark" commands, but this is not nearly as fast as seeing all such lines in a single view.
Were also concerned as to whether Visual Studio .Net can meet the rock-solid reliability requirement of an enterprise development tool. We tried to install the product from a privileged but non-Administrator account on our Windows 2000 workstation and were told that we must grant Administrator privileges. When this was done, however, we still encountered a reproducible Blue Screen of Death during the component update phase of that installation. We were able to avoid this only by logging in as Administrator to complete the job.
On one occasion, an attempt to load a sample code project failed with an error message, only to succeed on our next attempt. We get nervous when these things happen with an application; we get downright jittery when something as vital as a development tool shows such rough edges.
And yet, this bear does dance. In earlier reviews, we discussed in greater detail some of the leading-edge features that Microsoft is offering--namely, mobile client development, visual server-side development, and the integrated modeling aids for applications and database design. (See eWEEK Labs June 25, 2001, review of the Mobile Internet Toolkit beta; and Sept. 10, 2001, Visual Studio .Net Enterprise Architect Beta 2 review.)
Many developers, and every competing maker of application development tools, will want to study Visual Studio .Net to understand the ambitious agenda of Web services development--with the added incentive that Microsoft has clearly left some room for improvement, creating a space that other toolmakers will do well to promptly fill.
eWEEK Technology Editor Peter Coffee can be reached at [email protected]
- Microsoft Tunes Windows
- From the Labs: BizTalk Server 2002 Eases B2B Comm.
- From the Labs: Visual Studio .Net/BizTalk Combo May Tame Web
- Walk-Through: Go Inside Visual Studio .Net with eWEEK Labs
- Picking Up on Web Services Tools