Many IT managers with Microsoft infrastructures are debating whether their development efforts should be moved to .NET. Microsoft promises greater efficiency and programmer productivity with .NET, while allowing VB and C++ developers unprecedented power and rapid application design (RAD) tools. Microsoft has even introduced a new language, C#, designed specifically to work with the .NET Framework.

While there are many purported benefits of .NET, IT managers are understandably wary. The technology is new, which means that finding successful, mission-critical applications written in .NET can be difficult. And the learning curve for the .NET Framework is not trivial; VB developers sometimes find the move to VB.NET to be more complex than any previous version upgrade. Despite these costs, there are some strong arguments in favor of making the move.

1. Standards integration: XML, SOAP, and more
In the past, the Microsoft architecture has been built on COM/DCOM, a binary standard for allowing cross-process communication. There was nothing inherently wrong with it, but this binary standard didn’t have any relevance outside the Microsoft world. In other words, it didn’t allow easy interoperability with other software platforms.

In addition to the lack of interoperability with COM, data was another issue. While ADO allowed easy access to data, passing this data from one place to another could be problematic. The ADO Recordset object was a binary structure that stored the data, and once again, this binary format had no meaning to non-Microsoft platforms.

.NET seeks to remedy these shortcomings by becoming completely standards-based when required. For example, data is passed across process boundaries as XML, and typically this data has a link to an XSD, so any client can properly validate the data.

SOAP is an XML-based protocol that communicates with Web services. The integration of SOAP allows for easy programmatic access by any client, whether or not that client is running a Microsoft operating system.

2. Ease of deployment
One of the major headaches in the COM world has always been deployment. COM makes extensive use of the Windows Registry to locate components on the machine. The concept was good: There would only ever be a single instance of a component registered, and all applications would use the same version. COM promised to have new versions maintain backwards compatibility with old versions, but developers were free to break this compatibility, and sometimes did.

.NET takes a different approach: It doesn’t use the registry at all. Instead, Microsoft recommends that you make the components (called assemblies in .NET) local to each application. That way, changes to Assembly X for Application Foo won’t affect Assembly X’s Application Bar. If this sounds like the old days of having multiple copies of the same DLL spread around the computer, it is. But you don’t have the same issues of applications looking in the Windows\System32 directory.

Because .NET doesn’t use the registry, most deployments can simply be done with a copy command. There’s often no need to develop installation files. Also, Web applications don’t lock assemblies, so you don’t have to shut down an application to update a DLL.

3. Web service support
Microsoft is on the Web service bandwagon in a major way, and it’s never been easier to develop Web services than it is with .NET. You can create simple Web services with Notepad and not even have to run them through a compiler; simply call them and .NET compiles them and even generates a test page so you can verify they are working. .NET has all the plumbing needed and generates all the files you need, such as the WSDL file.

.NET is also a smart consumer of Web services: Once you set a reference to a Web service, you treat it just like a local assembly. You get full Intellisense and function completion help.

Web services are great for sending data. Thanks to ADO.NET, Web services can take simple or complex data and send it to any client in a well-formed XML format, complete with a link back to an XSD describing the data schema.

4. Standard toolset for any .NET language
You finally have an integrated set of tools for all your languages. You have a unified IDE, debugger, and other such tools. This allows other companies to plug their languages into the IDE and get all the support of the .NET tools. For example, Fujitsu has created netCOBOL .NET, which integrates directly into the IDE, so you can write Web services and Windows applications in COBOL and receive the debugging and profiling tools provided by Microsoft.

.NET is open enough that other vendors can provide their own tools as well. Borland, for one, has said that its next version of Delphi will be able to create .NET applications, but it is almost assured that Delphi will have its own IDE and not plug in to Visual Studio .NET.

5. Support for mobile devices
Soon after the release of Visual Studio .NET, Microsoft released the Microsoft Mobile Internet Toolkit (MMIT) for building mobile applications using .NET. This allows you to visually drag and drop controls on forms aimed at mobile devices. The toolkit handles writing the proper markup language (e.g., WML, WAP, etc.).

Coming soon will be the .NET Compact Framework, a scaled-down version of the Framework designed to run on Pocket PC devices. This will enable developers to create rich applications to run on Pocket PC computers. You can write an application and have it run on small devices, such as a Pocket PC device or a Web-enabled phone. In fact, the MMIT includes a number of emulators that use the actual ROM code for the devices, so you can test how your application will work on those devices before you deploy it.

6. Managed code
.NET manages your code, which is important for a variety of reasons, such as reducing bugs and building more scalable applications. .NET handles such tasks as allocating and recovering memory, creating and destroying threads and processes, and handling the access permissions of the running code.

VB developers are used to having such items as memory management and thread and process creation handled for them. For C++ developers moving to C#, having these aspects of their application handled for them greatly reduces the chance for memory leaks and other common bugs. And by having managed code, you get access to all the cross-language capabilities of .NET.

7. Platform independent
While .NET was created for Microsoft operating systems, Microsoft did release a portion of the framework and C# to the ECMA standards committee. The Mono project, an implementation of .NET for Linux, includes the Framework and a C# compiler. This means that many applications, especially Web-based applications, can be written once and then run on multiple platforms.

8. No lack of learning resources
There is a significant learning curve for .NET, and .NET has probably spawned more books than any other programming technology. In addition, a myriad of courses from Microsoft and third parties are available to get developers up to speed quickly. Finally, there are a number of Web sites that provide techniques and tutorials for developers moving to .NET.

9. Modernized languages
VB.NET and C# are both modernized languages. They are completely object-oriented and were designed to remove many of the inconsistencies found in VB and C++. The languages were built with an n-tier, component-based approach in mind.

C#, for example, removes pointers and other constructs that led to a significant number of issues for C++ developers, especially new developers. VB.NET and C# both benefit from having the Framework manage code. The Framework also includes the base objects needed to allow applications to be multithreaded, XML-aware, and so forth.

10. Standard base types across languages
One of the banes of VB developers has been that a string in VB was not the same as a string in C++, so when calling Windows API functions, there could be some problems. .NET specifies a standard definition for all types, so a string in VB.NET is the same as a string in C#, which is the same as a string in netCOBOL .NET. This means that you no longer have to worry about whether or not an integer is 32-bit in language A but only 16-bit in language B. You can be assured that any data type is the same across languages, enabling better cross-language integration.

More pros than cons
.NET provides a number of tremendous benefits that will make developers more productive, reduce the number of bugs, speed application development, and simplify deployment. IT managers are understandably wary, since .NET is a new technology that requires a moderately steep learning curve. For most organizations, however, the benefits will far outweigh the negatives. And with .NET, you’ll see great productivity gains for future development projects.