Determining exactly what .Net is may be the hardest part of measuring its success. The confusion goes way back to June 2000, when Bill Gates framed the .Net initiative in consumerish terms as an Internet "platform" to support all sorts of devices. As it turned out, .Net mainly manifested itself as a collection of technologies for developers, and that's how we have chosen to evaluate it.
Microsoft's real goals were many and ambitious. At the core of .Net, the CLR (Common Language Runtime) and its associated Framework (class library) would usher Microsoft developers into the world of managed code, of which the benefits were already well-known to their Java counterparts. In parallel, Web services would become the pivotal integration technology, and XML the lingua franca of data representation.
These were, and still are, the central themes. Don Box, architect of Longhorn's Indigo communication subsystem, put it plainly on his Weblog: "We're betting that the future is managed code and XML."
Of course there were grander promises, too. In the new .Net era, software was to be delivered as a service, and a set of Microsoft-operated services known as HailStorm would pave the way for a new style of network-centric computing. But the retreat from HailStorm, in the face of widespread resistance to the notion of Microsoft as an infrastructure and identity provider, set the movement back. Yet .Net succeeded in providing key pieces of the foundation for delivering software as a service.
Another setback was self-inflicted. When Microsoft removed the .Net label from its enterprise servers in 2003 and reasserted the Windows brand over that of .Net, the move raised questions about .Net's near-term longevity. Nobody should have expected that a sweeping transition to .Net could be achieved in just a few years, nor should it be surprising that much of the consolidation around managed code promised for 2003 is now scheduled for Longhorn in 2006 or later.
But developers want to exploit .Net's benefits today in their existing Windows operating systems and applications. In some ways, that remains harder than it should be. In others, .Net has exceeded expectations.
The devil's in the details. For the past few years developers have been digging in and evaluating specific .Net promises to simplify application deployment, beef up security, support a range of programming languages, streamline the programmable surface area of Windows, and enrich the user experience. We'll drill down into these topics to see what developers have concluded so far. Here's the rundown and what it means to you.
The State of the Windows Programming Art
Windows programmers who use .Net tend to like it a lot. They say they're more productive than before and for many of the same reasons cited by their Java counterparts. These include modern object-oriented languages (C#, Visual Basic .Net); a virtual machine with automatic memory management; and a robust class library that embodies best practices and simplifies use of the operating system's services.
Developers who write .Net code are more likely than their Java analogs to cite quality of tooling as a key factor. Many are using Microsoft's VS (Visual Studio) .Net -- the Herculean effort required to make it respond to programmers' needs has clearly paid off. Steve Forte, CTO of economic data aggregator Corzen, is one of many enthusiastic fans. "Once you've used IntelliSense, you just can't go back," says Forte, referring to VS .Net's new language reference search functionality.
There are, however, many more programmers who would like to use .Net than can. The CLR and Framework ship only with Server 2003; everyone else must install this substrate. Although for some, including Forte, that hasn't been an issue, for many others it has prevented their use of .Net.
Paul Beavers is senior product line manager at BMC Software. His product, Patrol for Windows, monitors corporate fleets of Windows NT and 2000 servers numbering in the thousands. And it runs close to the metal. "For an agent product to impact a server with a big run-time footprint," Beavers says, "is a big concern for customers."
Most software isn't written on a clean slate, of course, so the ability to use .Net in combination with legacy Win32 and COM software is significant. Here too, results have been mixed. According to Alessandro Forghieri, a partner at Nouvelle who has invested heavily in creating COM interfaces to his software, "Wrapping COM in .Net works quite well -- at least where the ActiveX zoo is not present."
But Jim Culbert, CTO of MetraTech, a billing-services provider, says the reverse scenario hasn't panned out as well. MetraTech's billing engine is made of COM objects that won't be ported to managed code anytime soon. Culbert hoped to enable his customers, who write plug-ins for the billing engine's COM interfaces, to enjoy the benefits of .Net. "But the tax we paid at interop boundary was too high," he says. "It was prohibitive to allow our developers and customers to write plug-ins in managed code."
Prominent among the COM interfaces that developers would like to control from .Net are those of Microsoft's own Office apps. The latest Office apps -- with the notable exception of InfoPath -- do offer primary interop assemblies for this purpose. But earlier versions don't, says Phil Stanhope, CTO of Adesso Systems. "It's a real shame that so many folks are re-creating the wheel [that is, writing their own interop assemblies] when Microsoft should just provide these from the get-go."
Despite spotty Framework support for Microsoft's legacy applications, developers say that the .Net Framework has done a good job of encapsulating core system APIs and best programming practices in a number of fundamental areas.
For BMC's Paul Beavers, simpler access to low-level file-system and event APIs is an example of why he's eager to move his products to .Net. To do in five lines of code what formerly took 100 is not only more productive, it's inherently more reliable. "All those native Win32 calls I make today are part of my problem," he notes.
For Adesso's Phil Stanhope, the Framework's support for threading has been a godsend. "Unless you were a hard-core C++ wonk," he says, "taking advantage of the threading services was difficult at best." Using the Framework, he's now able to pull off tricky coordination between threading and Windows UI controls.
Other aspects of the Framework lauded by developers include networking, XML, ASP .Net, and WinForms. Developers happily using ASP .Net to target the browser clearly outnumber those using WinForms to target the rich client, but there are plenty of the latter. Patrick Hynds, CTO of CriticalSites, points to the example of a company with an Ingres database and no Web development legacy that wanted to use .Net on its servers and clients. The result is a modern client/server application that uses WinForms to create a Web-services-aware GUI and the .Net Framework to provide common infrastructure to both tiers.
Simple, More Robust Software Deployment
Over the years, installing and uninstalling Windows software had become a mess of registry entanglements and DLL conflicts. The .Net architecture attacked the problem with metadata. Because managed libraries and executables are richly self-describing, they can be deployed by simple copying, and different versions of same-named programs can peacefully coexist.
As a result, many developers report that the promised end of "DLL hell" is, indeed, now a reality. For servers running ASP .Net, there's an extra bonus. Redeploying a server-based component once required an IIS restart, says Steve Forte. "Now we just copy the changed DLL up to the Web server," he says, "and users see the change on the next browser refresh."
But there are still rough edges. For example, a .Net assembly can be copied to a directory for local use, or it can be installed in the .Net GAC (Global Assembly Cache) for systemwide use. Developers are still sorting out the interactions between these two modes. In the case of MetraTech's Culbert, the goal was to support branded ASP .Net subsites, with assemblies that could be customized for each customer. Rather than installing a shared assembly into the GAC and versioning it for each tweaked subsite, Culbert opted for a dispersed deployment, and wound up "hip-deep in DLL hell again." Of course software versioning is, he admits, "a fundamentally hard problem."
That problem is compounded by the fact that there are now two versions of the .Net Framework: 1.0 and 1.1. Gustavo Eydelsteyn, managing director at ComponentOne, a vendor of third-party ActiveX and .Net components, notes that .Net components are specific to versions of the framework. Rather than build per-framework versions of components, he has so far chosen to support only the lowest common denominator, namely the 1.0 framework. "I think that they have solved DLL hell and now they need to work on 'versioning hell'," he says. "But this is a small price to pay compared with the huge productivity benefits of .Net."
Greg Reinacker, author of the NewsGator RSS reader, reports a similar issue. NewsGator is written in managed code but runs as an Outlook COM add-in. "As a managed add-in you don't get a vote," he says. "If another .Net-based COM add-in loads first, it gets to pick the framework version." So, like Eydelsteyn, Reinacker is currently developing for 1.0 and then testing against 1.1. Both, however, report that Microsoft is aware of these issues, and both expect forthcoming solutions.
Security Still a Sticking Point
The .Net architecture complements traditional security mechanisms based on user identity with a parallel scheme based on code identity. After the CLR performs low-level verification of each class that it loads like JVM (Java Virtual Machine), it gathers evidence -- point of origin, cryptographic credentials -- used to identify the code. Based on that evidence, an assembly's access to system resources is subject to a permission-granting policy. When an assembly demands access to a resource, the CLR checks not only that the calling assembly has the required permission, but also that its callers do. In a purely managed environment, this code access security means that a hostile invader impersonating a user can't wield system resources available to that user.
There are, however, few purely managed environments. Since a chain is only as strong as its weakest link, many developers regard .Net's code access security as a promising architecture, but it's hard to find developers who are realizing tangible benefits today. According to Patrick Hynds, we're still early in the adoption cycle.
"It's not until the second version, typically, until a community understands how to use a technology tool," Hynds says, "and we're still in the first version." During this preparatory phase, he adds, developers and administrators are working jointly to explore how the default .Net security policies interact with traditional mechanisms and to learn how to use the new management tools to fine-tune those policies.
Enriching the User Experience
At the .Net rollout in 2000, Bill Gates spoke at length about a new user experience for knowledge workers. The network would provide a distributed and replicated "XML Store;" users would interact with this data by way of a "universal canvas" then conceived as a next-generation browser infused with XML and Web services goodness.
The reality today is not much different than it was then. For .Net developers who want to combine richness with reach, there is little choice but to write two versions of an application: one for the browser, one for the rich WinForms client. On the Web side of the fence, ASP .Net earns high marks for its browser-agnostic implementation of server-side controls. Because they rely on standard HTML and JavaScript features, these controls play as well in IE for Windows as they do in Mozilla for Linux.
However, ASP .Net's original ambition to detect and adapt to alternate devices -- such as phones or PDAs -- will not come to fruition until Whidbey, the next generation of the .Net infrastructure and toolkit expected to beta later this year.
On the rich-client side of the fence, .Net 1.0 and 1.1 provide a feature called No-Touch Deployment, which, like Java Web Start, launches an application straight from the Web, pulling in referenced assemblies on demand. One former Java developer who has migrated from Java to .Net worked out an ingenious solution that shares .Net assemblies between a Web application that feeds data to a browser, and a rich-client application that downloads the same assemblies and uses them locally.
Although feasible, the developer admits the technique is tricky, underdocumented, and "basically rocket science." For most developers, the hopes once pinned on No-Touch Deployment are now being transferred to a Whidbey feature called ClickOnce. It's the same idea with, Microsoft says, a more refined and more practical implementation.
The Triumph of Web Services
.Net's support for Web services wins universal acclaim. Some of the developers we interviewed for this report told us back in 2002 that Microsoft's SOAP stack didn't always work smoothly with other vendors' stacks. But nobody complains about that today. The promise of cross-platform XML messaging has become a reality.
Equally important to developers is the power of the tools used to produce and consume Web services. "There's nothing new here," says MetraTech's Jim Culbert. "But having it all packaged so easily, with the human interfaces thouht through, really makes things flow."
As a result, we're starting to see the kinds of network effects that justify all the early excitement about Web services. If you're going to build a Web-services-based billing engine, as MetraTech has done, it had better be a minor task for your customers to be able to consume your services. Visual Studio .Net makes it so and thereby helps deliver on one of .Net's key promises. HailStorm has faded from the scene for now, and the smart client is still in flux, but the idea of a network of business services is coming into sharp focus.