Visual Studio.Net

vsnetlead.jpg
  • Editors' rating
    8.0 Excellent

Pros

  • Integrated environment for writing, testing and debugging code regardless of programming language
  • numerous code-generating wizards and enterprise templates
  • interactive Web pages keep HTML and executable code separate.

Cons

  • Millions of Visual Basic 6.0 developers may find the move to the object-oriented VB.Net a step too far, or simply decide that C# (or even Java) is just as easy a transition.

The launch of Visual Studio.Net (VS.Net) marks the official debut of Microsoft .Net -- the ambitious, bet-the-company initiative that aspires to weave a fabric of XML-enabled software and services across the Internet. As Microsoft's flagship integrated development environment (IDE), VS.Net contains the first release versions of two major new programming languages -- C# and Visual Basic.Net (VB.Net) -- and signals the end of the old Visual Basic line. Together, VS.Net and its languages provide all the tools necessary to build and deploy applications on Microsoft's bold new platform.

In this review, we evaluate the Enterprise Architect edition of VS.Net, a feature-packed juggernaut with an estimated price of £1,600. It includes everything contained in the £1,200 Enterprise Developer and £650 Professional editions, along with more templates, servers and modelling features. We've focused on the most important aspects of this monster package rather than attempt to cover all its features. More details are available on Microsoft's site.

For Microsoft developers, the best news is that VS.Net is by far the best IDE Microsoft has ever produced. Microsoft has long promised complete integration for Visual Studio, but this time the company has delivered, providing an elegant, seamless coding environment. The hidden gem of VS.Net, however, is Active Server Page.Net (ASP.Net), a vast improvement over previous ASP versions that takes the development, performance and maintenance of interactive Web pages to a new level.

VS.Net also instantly establishes itself as the leading IDE for developing Web services -- a new breed of discrete, XML-enabled software component now hailed as the future of application development throughout the industry. In VS.Net, developers can easily create Web services without having to get their hands dirty with XML code.

Despite these benefits, the fact remains that the relentless rise of Java has forced Microsoft to take a huge risk. With C#, VB.Net, and the .Net framework, Microsoft is clearly trying to retain its developer base by providing much of the same functionality offered by Java and the J2EE framework. This is a dramatic break with the past -- particularly for Visual Basic developers, who will now be forced to graduate to object-oriented programming. Will developers be wowed by the improvements, or -- faced with an unexpected learning curve -- see a definitive opportunity to jump on the Java bandwagon? VS.Net is Microsoft's best shot. Now it's up to developers to decide.

Fixing the problems
Among developers, Microsoft has long been recognised as a leader in creating fully-featured, easy-to-use programming tools. But like most other IDEs, previous versions of Visual Studio have fallen short of delivering a fully integrated environment that maximises programming efficiency. Visual Studio.Net represents a real breakthrough, enabling developers to employ a single, richly appointed environment to write, test and debug code regardless of programming language.

Top ZDNET Reviews

This new level of integration stems from the technology underlying .Net itself. All .Net languages compile to Microsoft Intermediate Language (MSIL), so that C# and VB.Net code written for the same purpose, for example, produce virtually identical lines of compiled MSIL code. Before, working with multiple languages -- typically Visual Basic 6.0, Visual C++, and Visual InterDev -- required that you open multiple development environments within Visual Studio. And of course, you needed a different debugger for each language, so that debugging applications written in multiple languages required you to flip among debugger windows to try and catch errors. Thanks to VS.Net integration and MSIL, a developer can use a single, integrated workspace with a sole debugger that minimises previous stability problems incurred by developing multi-language applications that require simultaneous use of several development tools.

To entice enterprise developers, VS.Net goes further than added stability. Like previous versions, VS.Net contains numerous code-generating wizards to help development projects get off the ground quickly and to automate mundane tasks. However, because enterprise application development demands robust architecture, the Enterprise Architect and Enterprise Developer Editions of VS.Net also include enterprise templates that automate the creation of projects and code that support architectural best practices.

This is a giant step forward: in previous versions of Visual Studio, the examples tended to focus on a single concept, ignoring the importance of architecture. Application deployment gets a boost as well, with special benefits for development teams. Code for deployment is now packaged in assemblies, with each assembly offering built-in version control along with support for multiple versions of a single DLL on a single machine. This allows developers to work on a specific piece of the application and deploy a new version of a single module while lowering the risk of breaking other referenced code. It also minimises the problems that arise from shared libraries -- otherwise known as 'DLL hell'.

In large enterprises, where decentralised development teams have diverse requirements, VS.Net offers a substantial productivity boost. Code reuse can occur not just within a single language, but also among various .Net languages -- a VB.Net shop and a C# shop, for example, can easily integrate and reuse code. Language syntaxes may be different, but when different languages instantiate and manipulate the same base classes, shorter learning curves result. As developers grow comfortable with a single unified IDE and its tools, efficiency goes up and training costs go down.

Big surprise for VB users
The C# language is clearly the star of the whole .Net mega-production, with Visual Basic.Net as its sidekick. C# and its 'Java-like' qualities -- such as garbage collection and hierarchical namespaces -- have received lots of attention. But VB.Net has had far less coverage, making it easy to overlook a simple fact: VB.Net is so similar to C#, it's worth wondering why Microsoft bothered to create two separate languages. True, VB.Net syntax remains verbose, while C# more closely resembles C -- but both languages access the same programming framework and compile to nearly identical MSIL code.

VB.Net's similarity to previous Visual Basic versions can only be called superficial. With VB.Net, Microsoft is trying to position Visual Basic as a viable enterprise application development language, adding such key features as inheritance, namespaces, multi-threading, and so on -- while preserving some semblance of easy syntax. Yet Microsoft can't conceal the difficulty of shifting from a glorified scripting language to a truly object-oriented one. The real question is: will millions of Visual Basic 6.0 developers decide that VB.Net is the way to go based on some syntactic similarities? In fact, most Visual Basic 6.0 developers would find it just as easy or difficult to make the leap to the more powerful C# -- or, for that matter, to Java. VS.Net comes not only with C# and VB.Net, but also with Visual C++ .Net and Visual J# (actually, in the form of a coupon redeemable when Visual J# launches late this year). All of the languages included with VS.Net compile to MSIL code -- as do 20 other languages that currently have MSIL compilers, including COBOL, Perl and Python. But by giving C# the most power, Microsoft has made it absolutely clear that C# is the language of choice for Microsoft .Net development.

Both C# and VB.Net protect developers from themselves through managed code. This means that the code is processed within a run-time environment (or 'sandbox'), in which all calls to the underlying OS and memory addresses are to an API -- and therefore 'safe' -- hiding some of the more powerful, difficult features of C++. In a pinch, however, expert C# developers can mark sections of code as 'unsafe' and gain direct access to memory and underlying OS libraries, trading some of the protection of managed code for added power. For better or worse, Java doesn't offer this option (nor, of course, does VB.Net). The stated purpose of C# is to provide a language suitable for building enterprise applications, yet with the syntax simplicity found in Visual Basic. Cynics argue that C# is just a Java knockoff, but that's tough to prove: both languages claim C as their parent and run in a managed run-time environment, which accounts for most of the similarities, including syntax, garbage collection and hierarchical namespaces. C# also preserves C++'s enums, whereas Java does not.

Where C# more closely resembles Java is in the handling of components, including properties, methods, events and attributes. But the 'Java-has-this, C#-has-that' debate largely misses the point. If a language provides object orientation, a usable syntax and sufficient functions, its value should be measured largely by the services provided in the framework, not relatively minor differences in syntax. After all, C# has only 60 statements but can use thousands of .Net framework classes. And because both .Net and J2EE were designed for building enterprise-class applications, no one should be surprised at the close resemblance between the two -- from a sandbox to run managed code, to a standard method for database access, to a scheme for creating interactive Web pages. When it comes to Java versus C# or J2EE versus .Net, far more similarities than differences emerge.

The Web wins too
For Microsoft developers who hack code every day, VS.Net's most welcome improvements may be found in the functionality of ASP.Net and Web Forms. Those familiar with ASPs know that creating interactive Web pages has always been something of a kludge, with HTML and (usually) Visual Basic scripts cobbled together in the same unwieldy file. By contrast, with ASP.Net, the HTML and executable code reside in separate files -- a boon for development, performance and maintenance.

The most immediate benefit of this separation is obvious: ASP developers and HTML jockeys simply avoid stepping on each other's code. Instead of writing scripts mixed in with HTML, developers can roll event handlers and business logic into compiled, object-oriented code on the server, increasing performance and -- thanks to object-oriented structure -- reducing the chance that dynamic sites deteriorate into spaghetti code. By the same token, the HTML can be customised independently to support multiple browsers and devices. Finally, the form state is automatically managed during posts back to the server, whereas before this required additional ASP scripting.

As in previous Visual Studio versions, you use a visual development environment called a Designer to create UIs. When you create a Web Form, VS.Net generates two files: one to store the HTML and a second to handle the VB.Net or C# code behind the Form. This is rapid development at its best: you drop widgets onto a blank Form, set widget properties and code the logic to react to user-driven events in the .Net language of your choice. When you're done, you're left with two separate files: an ASPX file to store the HTML (along with ASP tags to represent the widgets) and a second file to handle the code behind the Form. When the user requests an ASP.Net page for the first time, the Web server merges the two files into one on the fly and delivers the HTML to the browser. After the initial request, the page is stored in compiled code on the server, speeding the performance of subsequent loads.

It's worthwhile comparing the new ASP.Net approach with that of Java Server Pages (JSPs). JSPs contain HTML merged with Java code, but they're compiled into servlets when deployed on the server -- which overcomes some of the limitations associated with script code, such as performance and maintenance. But all page elements are still combined into a single file, retaining the problems associated with mixing content and code. For good reason, JSPs have been the favourite for developing interactive Web pages, but for now at least, Microsoft is offering a better solution.

Instant Web services - just add water?
Much of .Net's success rides on whether Microsoft can sell enterprises on the benefits of Web services -- which basically boil down to component reusability and rapid, inexpensive integration across platforms. VS.Net seems intent on proving how easy Web services can be, providing a complete, transparent environment for Web services development. Developers basically just flip a few switches to make component applications available as Web services, with no XML coding required. The .Net framework uses XML for data representation by default and enables you to expose Simple Object Access Protocol (SOAP) interfaces easily. Special .Net Web services classes enable developers to turn ordinary methods into Web services simply by adding the attribute 'WebMethod' before each method declaration. That's it -- method implementation remains exactly the same as it was before the method became a Web service.

In addition, .Net automatically takes care of creating a Web Services Description Language (WSDL) document to describe services. Developers simply modify the XML namespace by changing the namespace attribute prior to making the Web service public. All the plumbing required for the Web service is automatically created by .Net.

To build a Microsoft client that finds and binds to a Web service, a proxy needs to be created. With a proxy, the client can be developed as if it were making a simple object call. The first step involves running the Wsdl.exe utility to retrieve the Web service's WSDL schema, which is then used to create the proxy DLL. When the client is built and ready to call the Web service, it references the compiled proxy DLL, which packages calls to and from the Web service in SOAP. In this fashion, the client can make calls to the Web service without knowing anything about the underlying plumbing that makes Web services work.

On the Java side, tool kits such as Sun's Java Web Services Developer Pack have been released that offer Web services ease of use and functionality similar that of VS.Net. What gives VS.Net an edge is that the J2EE framework for Web services isn't cooked yet. J2EE 1.4 -- the platform specification that will address Web services -- won't emerge from the multi-vendor, quasi-democratic Java Community Process until sometime later this year. Microsoft is in the unique position of controlling its own universe.

All the pieces of its Web services framework are pretty firmly in place -- not only the programming environment, but also .Net MyServices; server applications such as BizTalk and SQL Server, and even a Web services tool kit for Office XP. VS.Net stands at the centre of all this. No matter what you think about the viability of Web services, Microsoft has provided both the tools and a broad-reaching environment to make the creation and consumption of Web services extremely simple.

 

Top ZDNET Reviews