.NET expert Richard Grimes
Author: Tao Gang build time: 2005-03-22 Source: NEW YORK Editor: Mr. Ark Richard Grimes is gradually leave their posts comments all .NET technology. In his bidding speech, he reviewed some errors in .NET development, and put forward some warnings for the future of the platform.
[Text] I have written .Net technology communication has been about three years, now I decided to stop this work. I think it is necessary to write a summary article, explain my views on .NET's current situation and future development.
At the beginning of 2000, when .Net is still in the beta version, I started using it; at that time, its name is COM 2, the main language is COOL. Its framework assembly is simply referred to as the next generation of Windows service (NGWs) until later, the name of the .NET, but .Net this name has caused the Internet search engine. You have to ask. What does NET mean? Or is it related to .com and .org? Of course, Cool's experience is not there. Later, they had some inspiration, decided to rename COOL C #, but C # seems to have also caused the search engine and user confusion. Search engines don't like to use # characters, and users don't know how this character is read (C pounds or the eavects of pronunciation C "). I published the first article on the technical news group is a simple Cool console application, a Java program with its function, and proposes some problems to point out the difference between the two. This has caused a strong response to the Visual Studio product manager, and they did not really notify the problem I pointed out.
Visual Studio.net is different from the other version of Visual Studio, and its first Beta is open. Anyone can download and submit bugs or problems in the Beta News Group. Honestly, I don't like this way. I just published some repeatable bugs in the public news group, as a silent British, I don't like to express those who are not repeatable, and I don't like to propose improvement suggestions. I also didn't see the result of this wide-range, open beta version of the public published from the public published in a large bug found; but I doubtful to find BUG is not its purpose - more likely to open the beta version It is to be accepted by everyone as possible.
Like other people, I was scared by the size of the framework when I started. It's too big! In the past few years I got a conclusion: the size of the frame assembly is an obstacle. It's too much in it, even though I also think that many of them are well designed, but I still think that there are some grassroots. Some of these classes are only simple packages of Win32, and some classes appear to be imported from other framework components. Microsoft has posted its own Java Frame Component Class library (called WFC) before publishing .NET, and has a traditional Visual Basic runtime part of the control (Managed) library, if I know how much WFC and VB migration It's better to go to .NET. But I can identify one of them because it is as bad as it runs on Net and VB, this class is EventLog. The behavior of this class is like its behavior in VB, even before the regular migration to the framework component version 1.0, even no one cares about its design. I complained this class in the beta version, but this class developer only gave some reluctant reasons. Finally, this class has been "patched" in 2.0, but the error method is still not eliminated, so I think it is not "patch" at all.
Overall, I think this class library is too early, and it is too big. The reable portion of the frame assembly is 25MB, which is much larger than the renewable part of Java. The experience of Visual Basic's early versions is the popularity of the sharing software and the free software market. Although some shared software is written in .NET, I often hear people complaining that huge renewable part. I have written articles about the class' s big problem, and I always think that if Microsoft provides deletion, only the Microsoft's core class library and the system components are beneficial. Speaking of Visual Basic, I also want to ask himself to see it, I have to say that the traditional Visual Basic is too old. The language is born with a single thread, and it will have a serious problem when interacting with COM (and establishing a COM server). In fact, when I wrote a book about MTS (published in 1999), I conclude that MTS is designed to allow Visual Basic developers to write those who can be from multi-threading and security technology (Security) The object of benefit, while COM makes it further. Visual Basic can call the Win32 function, but in order to use these functions for high efficiency, it is often necessary to take advantage of uncommon hacking techniques. But after COM and COM security technology, it moved forward, but it was still unable to provide a few lines of code to provide C enabled features. C can be easily implemented with very little code and VB is not like this, and any function is to make VB very embarrassed. However, most of this language and most of the runtime (Runtime) are neither, and therefore, the solutions for these issues are very radical. This results in the emergence of VB.NET.
If you search for the internet, you can find a lot of information about the release of VB.NET. The best is the website of Karl E. Peterson (http://www.mvps.org/vb/rants/vfred.htm). But VB.Net is not VB: Karl website shows a lot of things between VB and VB.NET two languages are incompatible. In addition, VB is single-threaded, which does not have an abnormal process, and typically use to write non-OOP code. VB.NET has a "migration" tool, but most people who I know this tool have found that this tool is just simply logging out a lot of incompatible code. My early suggestion is that VB developers don't migrate their own code, and the alternative method is to convert the code into a VB class, and these classes can be called by the COM interactive operation (Interope). With this method, the VB code can still be retained in the design environment. Of course, Microsoft continued to say that VB.NET is VB's myth, encourages you to use this migration tool.
Some people think that VB.NET is sighful. But I really didn't know the motivation for designing this language. There is little characteristic that other languages in VB.NET (renamed in the filter and interface method), but this is not sufficient for generating a new language. Some people may say that VB developers use VB.Net more touch, but I have said before, VB.NET is not VB, because developers must learn OOP and .NET principles, such as thread technology, abnormal processing, and commission, developers Almost learned a new language. C # is a natural language that can be used for .NET, it does not require VB.NET at all. It is not so difficult to use the semicolon (;) and parentheses ({})! It can be replaced by VB.NET, but not all languages are like this. My opinion is that General Language Normative (CLS) simply ensures that the code that works with VB.NET code in other languages instead of working all languages. I know that the Signed "integer data is useful, but unsigned (unsigned) integer data is also useful! I don't understand why VB.NET does not use unsigned integer as part of the language. There are also some situations and naive, we have no reason to use Option strict off ("delay binding" is also synonymous with difficulty to find runtime, and if you don't explicitly declare the variable, then it is easy to lose Tracking of these variables. The small amount of advantage brought by VB.Net is not enough to offset these serious defects it has. I have written VB.NET's article, and I have spent the VB.NET discussion, so I know this language very well. However, it didn't make me feel comfortable: I found that I can't curse every time I use this language. The situation of it work is different from me, and I am not the only person who encounters this situation. This is the most common complaint I heard when traditional VB migrate to VB.NET, which also supports the assertion of Karl E. Peterson - VB.NET is not VB. So why Microsoft creates VB.NET? The reason is that in 2000, the number of VB developers exceeded Microsoft's other languages, with at least 10% of the number of users (I saw this chart at Microsoft internal meeting). Microsoft is high-profile announces that C # is another language from the C family, and market people think they can't make all these VB programmers use a language similar to C . The alternative method is that they believe that if Microsoft builds a language similar to VB, it is more likely to migrate to .NET. In other words, the emergence of VB.NET is the reason for the market rather than the reason.
It is necessary to point out that .NET has many similarities to traditional VBs. The .NET is the interface (Interface), the interface is very exquisite, but the .NET recommends using class-based solutions, which marks the demise of the interface.
Let's take a look at .NET Remoting: Microsoft provides .NET Remoting is used to allow the object to be created in its own environment and the object run is called by another environment. This means that the status of the object is local (LOCAL), and its behavior is remote (Remote). Therefore, Remoting is an interface-based tool. You can use the interface to use .NET Remoting, but if you read the document or visit the HOW-TO (Operation Guide) on the Web, you will not see this at all. Instead, Microsoft recommends people using class-based methods, which typically leads to some strange phenomena - people deploy server components to the client, so that the client has metadata (metadata) of the available service objects, or Resulting in a bubble component, which makes which spreads around the class-based Remoting problem. The .NET is very like VB's attitude towards its framework assembly. Microsoft puts .NET as a useful class library expanded its own product, but so far, Microsoft did not show greater confidence in the framework component. There are only very few .NET products to use .NET products throughout the place; one of them is Microsoft's CRM. However, they are not the main source of income of Microsoft. Instead, .NET is updated to existing products and is used to expand these products. Even if Visual Studio .NET is not .NET product. DEVENV.EXE is a unmanaged process written in C (probably MFC). VS.NET hosts .Net running, so it can use the .NET object similar to the property table, and it can be written into code extensions of the .NET component. I think this is a model of Microsoft's future use. They don't want to bear. Net rewritten the cost of the code, and no one who combines them to provide new code in .NET; .NET will be boarded and allowed to expand through the code provided by the user.
Microsoft's current operating system XP and Windows 2003 do not depend on .NET; and XP .NET is an optional component. The next version of Windows (called Longhorn) is pre-released on the 2003 PDC, which looks .NET runs through this operating system. But there will be a lot of changes in the release. In the past year, Microsoft made a lot of statements, showing it more concerned about the original release date 2006, rather than the enthusiasm of new technologies. The first obstacle is WinFS, it is clear that this technique will make Longhorn slower, especially WinFS, make Outlook Express could not be used. But Microsoft's approach is not allowing this technology to work normally, but the choice to delete it. When you read these lines, I am suspected whether this technology can return to the application. Second, Microsoft claims to two other .NET technology in Longhorn, Net Technology, Indigo and Avalon, will be used in other versions of Windows. Indigo is a communication technology, so other versions of Windows use it meaningful. However, I think that Avalon can be used in other versions of Windows indicate that Microsoft is not confident to Longhorn's sales.
My opinion is Avalon - more specifically XAML, which will mark the demise of ASP. The reason is that avalon is a client technology, and the browser is an important part of the distribution model. XAML's function is so rich, so that the XAML application containing the browser does not differ from the process-based Avalon application, and the XAML application will make ASP after coupling web services or Indigo (as a mechanism for accessing remote code). The .NET application looks no value and obsolete. Why do Microsoft want to ruin ASP? When installing asp.net, Microsoft will sell a set of Windows 2003 and may also sell several Visual Studio.net. The client may not be Windows, so Microsoft does not have other sales revenue (whether product or license). This is a big source of income, worse, ASP.NET actually makes the written application easier, and it can also be used by browsers other than IE. However, when using XAML technology, Microsoft has control over the client. Therefore, in addition to the server and development tools, the client must have Avalon technology. If the customer is convincing, upgrade to Longhorn, then it may be a huge source of income of Microsoft. However, Microsoft claims that Avalon will be available for other versions of Windows, indicating that they are not so confident to Longhorn, and if developers can't determine if the client will run a Avalon application, then they will not write applications for Avalon. program. Therefore, from last year's statement, Microsoft believes that Longhorn is not a great .NET change in our trust on PDC 2003. This indicates that Microsoft is gradually losing confidence in .NET. When I saw Longhorn's beta version (should be the end of this year), I will carefully check how much it is implemented in .NET. I suspect that only a small part will be implemented with .NET. We can find some clues: If longhorn does not implement a command interpretation (shell), or not allow you to use the .NET extension command to interpret the program, it is obvious that Microsoft lost confidence. If longhorn does not implement any service in .NET, then it indicates that .NET is not the correct technology running under localsystem account privileges.
When you read this, the impression that I got may be that my view is cynical. Its frame assembly has a lot of commitments, but I think Microsoft's ambition is too big, and too many components are released at a very fast speed. Microsoft provides backward compatibility and cannot simply redesign the entire class library and abandon the old class library. So we have to stick to the class library now. Microsoft allows the market to be preferred in technology: they build and promote VB.NET just to make Windows developers using .NET, not because of this language. Its framework component has become Visual Basic - it is for users to develop applications, rather than for Microsoft to establish an operating system or build products that they rely on income. Http://soft.yesky.com/softchannel/72342389024358400/20050319/1924094.shtml
