Disappearing .Net Brand Invites Assimilation

Developer convenience encourages adoption but ties future projects to platform.

A reader of these letters asked me last week if I had noticed the formal naming of Microsofts next-generation development environment, now designated on a company Web site as "Visual Studio 2005 (formerly referred to as Visual Studio codename Whidbey)."

He asked what I thought about the disappearance of ".Net" from the current "Visual Studio .Net" toolsets name in the next prospective release. "First .NET disappeared from all the server products, and now it disappears from the developer products, too," he observed, going on to ask: "Has MS simply decided that the best answer to the inevitable question Just what **is** .NET, anyway? is now Its Windows. Theyre synonymous?"

In a word, I believe thats exactly correct. I dont believe that theres been any diminution of Microsofts commitment to the .Net ideal of managed code running in a secure, reliable, language-neutral, fully object-based environment. The .Net label, I suggest, has served its purpose of labeling a trial balloon until it was clear that it would fly, and now its actually to Microsofts advantage to downplay the significance of developer adoption of the .Net framework as their foundation for future work.

You can already see the spreading acceptance of the idea that .Net is just one of several frameworks against which to write a complex, line-of-business Web services application. In one recent article on early-adopter advantages and challenges for mission-critical Web services applications, I found this statement: "BigTrumpet uses tools such as Visual Studio.NET to develop Web services that conforms[sic] to standards such as WSDL and SOAP, and Microsoft .NET framework languages, ASP.NET, VB.NET, ADO.NET, Visual Studio.NET and .NET framework." I dont hear any implied requirement that a "standard" must be accessible to competing implementations, and that troubles me.

My inquiring reader, cited above, went on to ask: "Has the brand (and the vision???) of .NET crashed and burned along with Hailstorm and the marketing plans for software-as-a-service?" No, I dont believe that for a moment. True, even Microsoft satirized Hailstorm as perhaps one of the worst code names ever allowed to get into the public domain. Think about it: Is there a single positive association with that word? No, I cant think of any, either.

But Microsoft watcher Mary Jo Foley carefully read between the lines at last autumns Professional Developers Conference, when Group VP Jim Allchin was talking about the "Indigo" messaging services infrastructure component of the Longhorn portfolio: "Indigo is a subsystem that does everything for you," she reported Allchin as saying, and cited its capabilities for reliable message transaction, heterogeneous interoperability, messaging capabilities and a simpler way to build and consume Web services.

Importantly, she then noted, "If you remember Hailstorm, Microsofts personal Web services technologies, a number of them are set to manifest in Indigo." Why position something as a pervasive set of user services that might frighten off privacy-sensitive consumers, when you can position it instead as a developer productivity tool that will be comfortably buried inside end-user applications and tasks?

Personally, Im in a pretty grouchy mood at the moment about end users apparent willingness to live with bad choices that developers make: specifically, choices that favor developer convenience over security and reliability and other boring issues. For example, Ill soon be sharing with eWEEK readers my comments on Greg Hoglunds and Gary McGraws new book, "Exploiting Software: How to Break Code"; one comment from that book seems apropos. The specific subject is PHP, which the book calls "a study in bad security. … The mantra dont make the developer go to any extra work to get stuff done applies in all cases." And yet, PHP is widely used, creating widespread vulnerabilities.

Likewise the developer and user convenience features of Internet Explorer and the Windows platform, which still pave the way for costly attacks.

So heres the situation, perverse as it may seem. Microsofts earlier lack of attention to secure design is now leading to the kinds of widespread incidents that spur end-user demand for something more reliable--and only Microsoft has the resources, it appears, to build an environment and offer the associated development tools that make it easy enough for developers to rise to that demand.

Developers can either make the effort to build secure and reliable applications on a framework of open standards, or they can treat the .Net framework as a convenience-store version of a standard--with Microsofts de-emphasis of the .Net brand encouraging them to do just that.

Tell me where youre looking for your next projects components and tools at peter_coffee@ziffdavis.com.