One very important, non-technical, change is to the name. It may seem innocent enough, but if you take into account the fact that the .NET suffix has been dropped from the latest version of Windows (that is, what was going to be Windows .NET became Windows 2003), you begin to detect a cooling off between Microsoft and the .NET name. There is an argument that Visual Studio.NET might well have been adopted more readily if it was just branded as the next version of Visual Studio, i.e. Visual Studio 7. The "2003" part of the name certainly dilutes the ".NET" and dropping it altogether might well get rid of some of the misconceptions about the new way of doing things – specifically it isn't just about using the Internet.
While it is true that .NET has good facilities for writing Internet-based programs, this isn't its only characteristic, and it can be argued that it isn't its defining characteristic. After all, Web Services and XML are platform and vendor independent standards – I can use XML and SOAP from Visual Basic 6 or Java if I want to – so what has Microsoft to gain from claiming these as its unique property? While it is true that .NET makes using these technologies easier than many alternatives, by including .NET in the name Microsoft is putting the emphasis on the wrong aspect.
Of course Microsoft doesn't think so and the alternative view can be found in the panel (left) where Ivo Salmre, Microsoft's UK Product Manager for .NET and Developer Technologies, responds to points I made in February's editorial.
Goodbye COM
So what is .NET all about if it isn't "the Net"? One explanation is contained at length in Don Box's book Essential .NET: The Common Language Runtime (Addison Wesley, ISBN 0201734117) but the basic idea is very simple. .NET is a replacement for the deeply flawed technology of COM. In a single move .NET makes component creation and use simple. Whereas COM was impossibly difficult, fragile, contradictory, incomplete and so on, the CLR and the Framework are a simple and easy to use component technology. We can all forget COM and do something more productive with our lives!Notice that this doesn't mean that COM is no longer workable. The framework, via interop, supports both existing COM clients and servers. Indeed, wrapping a COM object or a .NET object is the only way to work with many existing Microsoft applications and APIs. However, what is certain is that starting any new project based on classic COM is probably not a good idea.
In .NET a runtime object and a class are one and the same thing, and there is no need to make a great fuss about the distinction between programmatic objects and binary runtime objects. Notice that .NET does still support the basic idea of an Interface, i.e. a specification for the methods and properties that an object of the type has to support. Interface definitions may have been a central part of COM, but they are not specific to binary objects – ask any Java programmer!
Goodbye API
There is another more subtle change that results from relying on a class library to create programs that run under Windows. Previously when you needed to use a service provided by the operating system, you looked up the functions that provided and controlled it, i.e. you looked up the details of an API – Applications Programming Interface. Now, to complete the same task you would find out which class in the class library does the job and find out about its methods and properties. What this means is that a .NET programmer can forget all of the Windows APIs and just concentrate on using the class library. This is both truly object-oriented and nothing new to Java programmers – even under Windows. However, what is true is that the class library under .NET is specifically designed to wrap the Win32 API, and while there is still a long way to go before it encompasses the entire API, the core functionality is already represented within the Framework.This raises a number of interesting questions and possibilities. Currently most of the more elaborate APIs – the Microsoft Speech API for example – have been built to use a COM interface. In addition, many of the more basic APIs have been provided with COM wrappers – CAPICOM for example wrapping the traditional functional CryptoAPI. Presumably we now have to see much of this work as being a bit of a waste of time, as the COM interfaces are replaced by suitable classes, and the COM wrappers are replaced by class wrappers. None of this has to be done in haste, however, because again we are rescued from an either/or situation by COM interop.
Now imagine a universe in the far future when APIs have been forgotten and everything is done by using the appropriate class. Now Microsoft is at last free to release an object-oriented operating system that implements the class structures as part of the internal workings of the operating system. The result is a more efficient, more powerful and less buggy Windows. The whole .NET approach frees the programmer from the underlying details of the operating system, which is exactly what being object-oriented promises us – encapsulation. It also makes it possible to think platform independent thoughts, but this is clearly going beyond anything that Microsoft has planned for the moment. It is, however, worth being aware of the moves by the open source community to make .NET available on other platforms (have a look at Mono).
Goodbye C++ and VB
Perhaps it is too early to say goodbye to C++. After all, what programming language has ever died a death? Languages can linger on for years after their peak, but it does seem that C++'s time to depart has arrived. If you're a C++ programmer, you may disagree vehemently with the next few comments, but you need to consider them carefully. C was a good but admittedly primitive language, and trying to turn it into a sophisticated objected-oriented language might well have seemed like a good idea at the time, but with the benefit of hindsight – it wasn't. C++ is a language with too many ways of doing the same job and this makes it fragile. If I had to nominate the two greatest time wasters of the past decade of programming, number one would be C++, and number two would be COM. Both are baroque pieces of engineering that needed experts and grand wizards to use them properly, and this era is best forgotten as soon as possible.Modern languages such as Java are modelled on C++, but they avoid most of its serious flaws. The replacement for C++ in .NET is C#, but it is clear that C# is also a suitable replacement for VB6/VB.NET on Windows platforms. Microsoft may not want to make much of this point, but when you try to find any good reason for choosing either VB.NET or C++ over C# for a new project, you begin to see that there is no other conclusion. Even if you are committed to C++, using any of its older technologies such as the MFC for a new project would be equally crazy, as these too are not long for this world. Microsoft may still be improving C++ and making it more standards-compliant, but the only reason this makes sense is that there are a lot of C++ users currently in denial.
On the other hand there is no doubt that VB6 – or "VB Classic" – is dead. It is to be discontinued in 2005, unless users protest sufficiently to get a stay of execution. VB.NET isn't just a new release of VB Classic, and switching to it involves learning almost as much as adopting C#. So unless you have an existing VB project to maintain, why not invest in the future and learn C#? It is clear that J# is a transitionary language aimed at Java programmers who want to port or maintain existing Java applications, and there are many who see VB.NET as serving the same purpose for VB Classic developers!
What all this means is that if you are going to start a new project targeted at the Windows platform, there seems little point in choosing anything but C#. Of course there are issues of portability and using the language you already know, and these may well mean you stick with another language for now, but this doesn't seem like a convincing long-term game plan.
ASP.NET
A large chunk of .NET that I haven't considered is the extension of ASP to ASP.NET. This is perhaps the most amazing part of the entire scheme, and it really needs an article of its own to appraise it. The most important point is that the core of .NET can survive without ASP.NET becoming a dominant force in Web application design. Many will select .NET as a desktop programming system because it offers the possibility of creating ASP.NET applications as well, but I doubt many will go the other way! ASP.NET is an interesting experiment, but its success isn't essential to that of .NET on the desktop.Problems with .NET
There are many serious problems with .NET but many of them are of Microsoft's choosing. For example, to develop under .NET you need either Windows 2000, 2003 or XP Professional, i.e. an NT-derived operating system. This is a shame because it locks out many beginners who are still using Windows 98, and after all it was the weekend programmer who made Visual Basic the success it is/was. When VB first came out it was supported on all Microsoft operating systems – including MS-DOS! Microsoft clearly isn't in the same frame of mind when it comes to .NET, because I'm sure it could produce a Windows 98 version if it wanted to. To indicate this lack of will just consider the fact that .NET claims it doesn't work under XP Home edition! The reason is that XP Home doesn't have IIS and so you can't develop Web Services using it. This is taking the .NET name far too seriously!Another key issue is the whole area of scripting languages – VB Script and VBA in particular. Microsoft has a big problem in the future in trying to integrate Office development with .NET. Currently its efforts amount to saying that you should carry on with VBA and perhaps use COM interop to build COM components that can be used as add-ins. There is no hiding the fact the we have a technological incompatibility here, and it could be that VBA turns out to be the last refuge of VB Classic programmers.
Paradigm shifts
Over all I'm enthusiastic about .NET. It's a better way to work but it's not just XML or Web Services. It represents a paradigm shift for Windows programmers, and we all have to learn how to do things properly in the future. The extra effort needed in learning to be object-oriented in practice as well as in theory is repaid many times over in not needing to deal with the technicalities of COM or the programming messes that can easily be created using VB6 or C++. The message is that once you get over the shock of the new, it's all so much easier.
What is .NET, where is C++ going, and what about backwards compatibility?The editorial leader in February's VSJ prompted Ivo Salmre (Microsoft's UK Product Manager for .NET and Developer Technologies) to send us his thoughts on the .NET Framework. If you don't agree, want to ask a question or put your point of view, please email VSJ editor Mike James, and we'll post selected contributions on the VSJ web site. To start off, I would like to say mea culpa; to date we have done a less than stellar job of defining ".NET". Like many popular terms it had grown in meaning to the point of diluting its essence. The time has come to prune and clarify the definition of ".NET", and a broad effort is underway at Microsoft to do just that. .NET should be thought of as two related concepts, the ".NET Connected" vision and the ".NET Framework" for developers. ".NET Connected" is Microsoft's vision for "connecting systems via XML Web Services". XML Web Services allow all vendors (Microsoft, IBM, BEA, and over 150 others have signed up to date) to participate in building systems that interoperate using open standards; this is good for everyone. In brief, a ".NET Connected" application is one that is built on top of the .NET Framework that leverages Web Services. The ".NET Framework" is the runtime that enables developers to build applications to run on servers and desktops. The ".NET Compact Framework" allows the same for smart devices. The frameworks offer a consistent set of APIs that allow developers to build rich web, desktop and server applications. Application choices include: HTML-based applications, Rich Windows clients, Rich mobile devices, and broad reach mobile applications (cHTML, WAP, etc.). All of these can easily take advantage of XML Web Services. This brings us to the next question raised, "What is the role and future of C++ in Microsoft's strategy?". Microsoft remains absolutely dedicated to C++ developers. C++ has been the industry standard for systems programming for many years, and will remain a dynamic and important member of the Visual Studio family. To this point, Visual Studio.NET 2003 features significant enhancements in C++ benefiting native-code and .NET Framework developers, two examples being greatly enhanced C++ standards support and support for the .NET forms designer. Will some C++ developers migrate to C#? Absolutely. C# bears its lineage (as does Java) to the C++ language and offers many refinements that C++ developers will find attractive. Our goal is to give developers the widest set of language options and allow them to pick the best language for their tasks. Finally, Microsoft is dedicated to helping organisations to leverage investments in previous technologies. Extensive support is built into the .NET Framework for inter-operating with COM components; developers can interoperate with existing COM components and .NET Framework developers can also expose their components via COM, allowing existing applications to take advantage of the .NET Framework. Additionally, third party languages running on top of the .NET Framework (COBOL, FORTRAN, RPG, to name a few) offer the opportunity for organisations with legacy code investments to gain the benefits of .NET as well. Through the Common Language Runtime, Web Services and the.NET Framework, Microsoft is dedicated to giving developers the maximum flexibility to craft their applications as they see fit. |
Visual Studio.NET 2003There isn't very much that can be described as major in the new "1.1" release of Visual Studio. The first thing you notice is that the Start Page has been re-designed. The Solution Explorer has also been tinkered with and includes new icons for an active tracking option. Multiple versions of the .NET Framework and Visual Studio are now supported.When you open an existing project you are given the option of converting it to use the new framework – something which cannot be easily undone. Debug and build options have been improved. You can now rebuild or clean a single project and remote debugging is supported over pipes. A migration tool is available to move your options and settings from VS.NET 2002 to 2003. Some new features are available when you try to add a reference to a Web Service. The dialog box now allows you access to external public UDDI servers.
The two main .NET languages are subject to minor enhancements. VB.NET can now upgrade WebClass projects and UserControls. You can also copy and paste VB 6.0 code and convert the result to VB.NET. C# has some minor changes, the most noticeable of which are the improvements to IntelliSense prompting for auto event hook up, Interface implementation and override assistance. There are a number of minor enhancements to VC ++ and one very important one. Although the compliance of VC++ to international standards is the most publicised improvement, the big news is that there is now a forms designer for VC++. Yes, you can now create C++ forms by dragging and dropping, and the code is generated as in C# and VB.NET. This is perhaps the single most important change in the whole of the new release of Visual Studio and puts C++ on a par with the other .NET languages. In addition there are now new project templates for .NET Controls, Form applications and Windows Services. There are many other minor changes – you can no longer export a make file, the Class Wizard and Wizard bar have been split into a number of new Wizards, etc. Other enhancements to .NET are more specialised, so aren't likely to be of interest to every user. The .NET Compact Framework is aimed at developers working with Pocket PC 2002 and Windows CE .NET devices. The Compact Framework allows you to create applications for these devices in any .NET language, e.g. VB.NET or C#. The ASP.NET Mobile designer also makes it easy to create ASP pages that work on mobile phones etc. Visual J# has been available for download for some time, but it was too late to make it into the box and be fully integrated with VS.NET. J# is a Java-like language designed to make it easier to port existing Java applications to .NET. The oddest addition to VS .NET is "dotfuscator". This is a third party tool provided by PreEmptive Solutions that will mangle your code to make it more difficult for users to reverse engineer it. One of the complaints that many developers have of the .NET approach to doing things is that it makes code easier to disassemble because production code isn't in machine language, and the manifest provides lots of information about how the code works. The dotfuscator is an attempt to make code less readable after it has been reverse engineered.
The most important part of the new VS.NET is the improved Framework. Many of the changes are fixes and extensions to existing facilities. New features aren't exactly core classes – they include support for mobile web applications, execution of Windows Forms that originate from the Internet, native support for connecting to ODBC and Oracle databases, and IPv6 support. As well as class library improvements, the Framework now also supports side-by-side execution multiple versions of an application or component, better code access security for ASP.NET, and improvements to scalability, performance and documentation. So overall is the new edition worth the effort? If you are a C++ programmer then the addition of a forms designer is enough on its own to justify the upgrade. If you work in VB.NET, C# or J#, then the improvements are less of an attraction and the main reason to upgrade is to be working with the latest version of the framework and its tools. |
Comments