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.