In the. NET camp, Microsoft technical experts are very disappointed with. net.

Mr. grimes 'farewell Richard is stepping down from his post of commenting on all things. net. in his farewell address, he looks back at some missteps in the development. net and offers words of warning about the future of the platform

It is now almost three years since I started writing this newsletter and now I 've decided to finish. I thought I wocould provide a concluding article to give my view on the current state. net.

I started using.. net when it was in technical preview at the beginning of 2000; at that time it was called COM + 2 and the main language was something called cool. the framework briefly became next generation Windows Services (ngws) before some marketing wonk came up with a term that really wocould confuse Internet search engines :. net. how many times have you been asked what. net means and what relati Onship it has to. com and. org? Of course, cool faired no better. some bright spark decided to call it C #, which initially confused search engines and users alike. the search engines did not like the # character and the users did not know how to pronounce it (c-pound? Or for those of us on the eastern side of the Atlantic, C-Hash ?). Almost the first thing I posted on the technical preview newsgroups was a simple console application in cool, and its equivalent in Java with the rhetoric question to spot the difference. that solicited a robust response from the Visual Studio product manager who didn't really see the point that I was making.

Unlike other versions of Visual Studio, the first beta of Visual Studio. net was open. anyone cocould download the beta and post bugs or questions in the beta newsgroups. to be honest, I wasn' t comfortable with that. I will only post a repeatable bug in a public group, and as a reserved Englishman, I am unlikely to post bugs that are not repeatable or post suggestions on improvements. I have not seen any published results as to whether such a wide and open beta was beneficial in terms of the number of bugs that were identified; however, I suspect that finding bugs was not the intention-it was more likely that the beta was open to get as wide acceptance as possible.

Like everyone, I was initially overwhelmed with the size of the framework. There was so much there! In the last few years I have come to the conclusion that its size is a hindrance. there are too classes and although I think that there are classes that are well-designed, I think that there are some that haven't been given more than a cursory thought. there are classes that are mere wrappers around Win32, but there are other classes that appear to be ported from other frameworks. before it released. net, Microsoft had its own Java Framework library called WFC, and it also had a managed library as part of the Visual Basic (Classic) runtime. it wocould be nice to know how many classes from WFC and VB were ported. net. I can identify one such class, because it works just as badly in. net as it did in VB, And that class isEventLog. This class behaves just like the VB equivalent, and no one even bothered to think through the design before rubber stamping it for the 1.0 version of the framework. for the record, I did complain about this class during the Beta, but the developer responsible just gave me some lame excuse. finally, this class has been "fixed" in 2.0, but the errant methods have not been deprecated, so I don't regard it as a fix at all.

In general, I think the library was released too early, and I think it was too large. the framework redistributable is 25 MB, which is usually times larger than the Java redistributable. one of the lessons of the early versions of Visual Basic was that the specified ware and freeware market created the popularity of the language. while there are some firmware ware apps written in. net, I often hear people complain about the huge redistributable. in this column, I have written about the size issue, and I still think that it wowould benefit the framework if Microsoft provided a cut down version of the Framework with perhaps just mscorlib and system assemblies.

While I am on the subject of Visual Basic, I may as well give my opinion about that language. it has to be said that visual basic (Classic) was getting rather tired. the language was inherently single threaded and had serious problems with COM (certainly as far as creating com servers ). in fact, when I had finished writing my book on MTS (published in 1999 ), I came to the conclusion that MTS had been designed to allow Visual Basic developers to write objects that cocould benefit from threading and security, and COM + took this a step further. visual Basic cocould call Win32 functions, but it often had to use dirty hacks to use them extends tively. but with COM, and COM security, it had gone as far as it cocould and cocould not provide what C ++ cocould do in a few lines of code. any situation where c ++ can provide a facility in a few lines and VB cannot is embarrassing to VB. however, most of the problems are so inherent in the language and the runtime that the solution had to be radical. and that lead to VB. net.

Well, a search of the Internet will give you most of the details of the furor that the release of VB. net caused. the best site is Karl E. peterson's (http://www.mvps.org/vb/rants/vfred.htm ). VB. net simply isn't VB: as Karl's site shows, there are multiple incompatibilities between the language of VB and VB. net. further, VB is single threaded, does not have exceptions, and was typically used to write non-oop code. VB. net was provided with a "porting" tool, but most people I know who have used it (including me) have found that the tool simply comments out large amounts of the incompatible code. my advice early on was that VB developers shocould not port their code, and instead they shocould convert it to VB classes that cocould be called. net code through COM InterOP. that way, the VB Code remained in the environment where it was designed to work. microsoft, of course, perpetuated the myth that VB. net was VB and promoted the porting tool.

Some people regard VB. net as wonderful. I really don't see the reason for the language. there are a few features that other versions do not have (exception filters and renaming interface methods are two), but these are not good enough reasons for a new language. there is the argument that VB developers wocould be more comfortable with VB. net, but as I 've said, VB. net is not VB, and since a developer Wocould have to learn principles of OOP and. net principles like threading, exceptions, and delegates, the developer may as well learn a new language. C # is the natural language to use. net and there was no need for VB. net. semicolons and braces are not so difficult to get used! Instead, we have a language that's. net, but not quite all there. in my opinion, the common language specification (CLS) was created simply to make sure that other versions ages cocould create code that wowould work specifically with VB. net code, rather than making all ages work with each other. I understand that signed integers are useful, but so are unsigned integers! I do not understand why VB. net cannot have unsigned integers as part of the language. I think that case insensitivity is juvenile, there is no excuse for using option strict off ("late binding" is a synonym for "hard to find run time bugs "), and it's easy to lose track of your variables if you don't explain icitly declare them. VB. net has serious flaws that are not counteracted by the few benefits it gives.

I have written a column on VB. net and I have spoken at VB. net conferences, so I know the language well. however, it's not a language I am comfortable with: I find that whenever I use the language, I tend to swear a lot. it just doesn't work the way I did CT it to, and I am not the only one. this is the most common complaint I have heard from people who moved from VB (Classic) to VB. net and this bac Ks up Karl E. Peterson's statement that VB. NET is just not VB. So why did Microsoft create VB. NET? The answer is that in 2000, the number of VB developers exceeded the number of users of Microsoft's other principle language, C ++, by at least a factor of 10 (these were figures I saw at an internal Microsoft meeting ). microsoft made a big point in announcing that C # was another language "from the C ++ family" and the marketers judged that they cocould not get all of those VB programmers to use a C + +-like language. instead, they judged that they wocould be more likely to get a fair proportion of those VB programmers to move over. net if Microsoft generated a VB-like language. in other words, the reason for VB. net was marketing and not marshical.

It is worth pointing out that. net in general has extends similarities with VB (Classic ). like VB ,. net can use interfaces but the preferred way is to use classes. interfaces are elegant. net's preference for class-based solutions has marked the death of interfaces. look. net remoting: this has been provided to allow an object to run in the context where it was created, and be accessed from another context. this means that the object state is kept local, and it is the behavior that is Remoted. thus, remoting is an interface-based facility. you can use. net remoting with interfaces, but reading through the documentation and all of the "how-tos" on the web, you wouldn't realize this. instead, Microsoft prefers people to use a class-based approach, which often results in the bizarre situation of people deploying their server assembly to the client so that the client has the metadata of the service objects available, or a soapsuds assembly, which basically was a hack to get around the problems of having class-based remoting.

Another area where. net is very Vb-like is Microsoft's attitude to the framework. microsoft treats. net as a useful library to extend its products, and to date, it has not shown any more conviction to the framework. there have been a few. net products written entirely in. net; one such product is Microsoft CRM. however, these are not the main revenue generators. instead ,. net has been has fitted to the existing products and used to extend them. even Visual Studio. net is not. net product. devenv.exe is an unmanaged process written in C ++ (and presumably MFC ). vs. net hosts. net runtime so that it can use. net objects like the property grid and so that it can be extended through code written. net assemblies. it's my opinion that this is the model that Microsoft will use in the future. they do not want the expense of rewriting their existing code. net, and there is no compulsion to provide all new code in. net; instead ,. net will be hosted as and when it's needed, particle ly to allow extensibility through user-supplied code.

Microsoft's current operating systems, Windows XP and 2003, do not depend on. net; and with XP ,. net is an optional component. the next version of Windows, codenamed Longhorn, was released as a technical preview at the 2003 PDC, and it looked as if the operating system wowould have. net's tendrils throughout. however, a lot has changed since then. over the last year, Microsoft has released a series of announcements that have shown that it is more concerned with an artificial deadline of a release date of 2006 rather than a passion towards new technology. the first casualty was winfs. it's true that this technology made Longhorn slow, and in particle, winfs made Outlook Express totally unusable. but rather than making this technology work, Microsoft chose to remove it. reading between the lines, I doubt if this technology will ever return. next, Microsoft announced that the two other. net Technologies in Longhorn, indigo and aveon, wocould be available for other versions of Windows. indigo is a messaging technology, so it makes sense that other versions of Windows can use it. however, I take the demo-to make aveon available to other versions of Windows as a lack of confidence in the sales of longhorn.

My opinion is that aveon, or more specifically, XAML, will mark the death of ASP. the reason is that aveon is a client-side technology, but the browser is an important part of the distribution model. XAML is so rich that a browser-contained XAML application will look no different to a process-based avlon application, and coupled with Web services or indigo (as the mechanism to access remote code ), An XAML application will make an ASP. NET application look paltry and antiquated. Why wowould Microsoft want to kill asp? Well, with installation of ASP. net Microsoft sells a single copy of Windows 2003 and perhaps a handful of copies of Visual Studio. net. the clients don't have to be windows, so there is no extra sale to Microsoft (whether as a product or licence ). this is hardly a great revenue generator, and worse, Asp. net actually makes it easy to write the application so that it can be used by browsers other than IE. however, with a technology like XAML microsoft gets to control the client. so in addition to the server and the development tools, the client must have aveon. that cocould be a huge revenue generator for Microsoft, assuming that MERs cocould be persuaded to upgrade to longhorn. however, Microsoft's announcement that aveon will be available for other versions of Windows indicates to me that they are not so confident on the uptake of Longhorn, and developers will not write applications for aveon if they are not convinced that there will be the clients that will run it.

So, with the announcements they have made last year, Microsoft has indicated that Longhorn will not be the great. net innovation that we were lead to believe it was from PDC 2003. this indicates to me that Microsoft is losing confidence in. net. when I see the beta of Longhorn (due later this year), I will examine it carefully to see how much of it is implemented. net. I suspect very little will be. here are some clues to look for: If Longhorn does not implement the shell, or will not allow you to extend the shell. net, then Microsoft has clearly lost their confidence. if Longhorn does not implement any services in. net, then they will indicate (as I do) that. net is not the right technology for running under the privileges of the LocalSystem account.

So if you 've reached this far, you will get the impression that I have a very cynical opinion. net. the framework has a lot of promise, but I think Microsoft was far too ambitious releasing far too extends assemblies much too quickly. as a result design suffered, but to provide backward compatibility, Microsoft cocould not simply redesign the whole library and deprecate the old one. so we are stuck with the library we have. microsoft has allowed marketing to take precedence over technology: they created and promoted VB. net simply as an attempt to get the bulk of Windows developers to use. net, and not because there was any need for the language. the framework has become Visual Basic-it's intended for users to develop applications, but not for Microsoft to create operating systems or the revenue generating products that they base their profits on.