C#揭密II（大师们在说些什么？）
先声明这篇文章属于收藏性质的,推荐给那些喜欢dotNET技术的爱好者。
这之前我曾转载了O'Reilly的一篇关于C#的访谈录。O'Reilly一向以技术和评论公见长，他们的编辑一般都有着很深的技术背景和功力(所以出的书也比较贵haha)，所以那篇着重整个流行技术，有不少是和Java相关的；而这一篇都是MS内部的几个高手在交谈聊天，涉及的范围比上次的专访要广，里面有一些很新奇的术语和许多问题的观点。另外我认为这篇文章对以前非常熟悉COM+、ASP和Window DNA（N 层结构）的人目前评估和思考向新的dotNET体系迁移都很有帮助。
Anders Hejlsberg是个很奇怪的人，从他身上你感觉不到一个程序语言创始人那种对某种语言偏爱的狂热，却很容易感觉到他所透露出的那种对技术对程序语言的坚定和深厚理解。很喜欢他在上一篇访谈录中说的一句话：“Language is a funny thing: It's a matter of taste. Language is almost a religious thing, and it's a lifestyle choice for programmers。”不过我知道这句话说的不是他自己。这篇文章中还有好些人：Brian Harry，Peter Golde ，Scott Guthrie（ASP老怪），Mark Anders。有了这些人，Microsoft有福啊。
小气的神
2001.09.24
--------------------------------------------------------------------------------
Conversations on .NET
Derived from on-line chats with our early adopters, a series of conversations with Microsoft engineers, designers, and developers look at issues involving C#, ASP.NET, and the Common Language Runtime.
http://msdn.microsoft.com/library/default.asp?URL=/library/techart/dotNETconvers.htm
Summary: What follows is a series of conversations with Microsoft engineers, designers, and developers, looking at issues involving C#, ASP.NET, and the Common Language Runtime. (10 printed pages)
A Conversation with Anders Hejlsberg and Peter Golde on C#
Anders Hejlsberg is a Distinguished Engineer in the Developer Division at Microsoft Corporation. He is the chief designer of the C# programming language and a key participant in the development of the .NET Framework. Previously, Anders was the architect for Visual J++ and the Windows Foundation Classes.
Peter Golde is a Software Design Engineer in the Developer Division at Microsoft Corporation. Peter has worked on development tools at Microsoft for over 10 years, contributing to products such as Microsoft C, OLE Automation, Visual Basic, Visual Basic for Applications, and Visual J++.
Q: Peter, you attended the ECMA meetings in March. Can you disclose anything about what's going on there that is new?
Peter Golde: Sure. As some of you may know, Microsoft, Intel, and HP jointly submitted two specifications to ECMA for standardization via the ECMA process. These two specifications are the C# language and the common language infrastructure (CLI), which is a subset of the .NET Framework. We're meeting with a number of companies every month as part of the standardization process. It's difficult to predict the schedule with absolute certainty, but we hope that ECMA will be able to complete standards for both parts by the end of 2001.
Q: How does the CLI compare to the CLS and the CTS?
Anders Hejlsberg: CLS stands for Common Language Specification, CTS stands for Common Type System. The CLS is a specification of what features any programming language implemented on the .NET platform must support.
Q: OK, the CLS is less than the CTS. Where does the CLI fit?
Anders Hejlsberg: The CTS is basically another word for the type system in .NET, i.e. a specification of what a class, struct, enum, or such is. CLI is really just another word for the large subset of the .NET Framework that we submitted to ECMA.
Peter Golde: The CLI includes the CLS and the CTS.
Q: Anders, after your work on Turbo Pascal, Delphi, Visual J++ and now C#, how do you see programming languages evolving today?
Anders Hejlsberg: Jeeez, had to ask an easy one, eh? I guess I'm becoming less and less of a believer in revolutionary approaches to language design. It really is amazing how much the capabilities of computing have evolved, yet we're basically still using the same kinds of programming languages. It gives me hope that we can go even further with an evolutionary approach where we don't just invalidate all the work that went before.
Q: Have you thought much about moving toward an intentional programming model?
Anders Hejlsberg: Can't say that we have. As I see it, one of the problems of intentional programming is that you're basically creating a new programming language for every domain specific application. I really am more of a believer in having a core set of abstractions (such as classes, methods, properties, and events) and then applying them in each domain—but in a way that preserves familiarity.
Q: Customers looking at the .NET Framework for their application development efforts have asked whether or not the common language runtime (CLR) is a virtual machine (VM), and if so, what limitations or penalties associated with VMs (performance and so forth) will folks need to consider in their efforts?
Peter Golde: Yes, I think that the CLR can be considered in the broad class of things that one might call a VM. As to performance, though, I don't think that this classification says much of anything interesting about performance. You should judge performance by measuring performance on the applications that you are interested in. Don't try to prejudge performance based on your preconceptions about what will and won't be slow—just test it!
Q: Peter, are there any kind of applications that you would explicitly not build on the CLR due to issues with running managed versus unmanaged code?
Peter Golde: In terms of what applications I wouldn't write, I would say that "hard real-time" kinds of programs probably wouldn't be a good fit (at least right now), because we don't make very strong guarantees about the garbage collector, things like robot control and the like. There are real-time friendly garbage collection algorithms, so I don't think this would be a limitation forever.
Q: Can you discuss any advantages C# would have over Visual Basic (VB) in terms of the framework?
Anders Hejlsberg: Regarding C# vs. Visual Basic, it really primarily comes down to what you already know and are comfortable with. It used to be that there was a large perf difference between VB and C++, but since C# and VB.NET use the same execution engine, you really should expect the same perf. C# may have a few more "power" features (such as unsafe code), and VB.NET may be skewed a bit more towards ease of use (e.g. late bound methods calls), but the differences are very small compared to what they were in the past.
Q: Ok, can you contrast C# with VB.NET? Questions usually come in the form of "I know you guys say VB.NET and C# let you do the same thing, but C# was designed for the CLR, so I don't believe you when you say VB.NET is just as good."
Anders Hejlsberg: Regarding C# versus VB.NET, the reality is that programmers typically have experience with either C++ or VB, and that makes either C# or VB.NET a natural choice for them. The already existing experience of a programmer far outweighs the small differences between the two languages.
Q: It has been said a few times that C# is the language designed for the CLR. Considering that all the languages that Microsoft will ship with the VS.NET will be able to target all the features of the CLR, what makes C# more CLR "friendly" than the other?
Peter Golde: I don't think that C# is necessarily any more friendly to the CLR than other languages. The CLR has been designed to be accessible via multiple languages. However, you will probably find that C# is more strongly focused on the CLR than other languages like C++, which have a number of other facilities that are less oriented toward the CLR. By designing C# in conjunction with the CLR, we have the "luxury" of not having backwards compatibility constraints.
Q: Is there any difference between the DEFAULT Equals function (implemented in Object) and the =?
Anders Hejlsberg: For two reference types (classes), the default Equals() method is the same as ==. But for value types (structs), there is no == operator unless you provide an implementation in the value type.
Q: Is Lock (this) similar to the synchronize key word in Java?
Peter Golde: Yes, lock (<expression>) is extremely similar to synchronized (<expression>) in Java. We don't support the notion of a modifier on methods, because our experience is that it leads to deadlock or poor performance in too many cases.
Q: We mostly want the COM+ benefits of memory caching, independent process space, etc.; we don't need to worry about database transactions. Is this a valid reason to place CLR components into COM+, or is it better to just let the CLR handle it?
Anders Hejlsberg: I would look at .NET Application Domains and not use COM+ in that case.
Q: Can you elaborate on .NET Application Domains?
Anders Hejlsberg: Sure. An Application Domain is sort of like a light-weight process. Two application domains will share the same GC heap, but the CLR provides automatic and transparent marshalling between the application domains. It allows you to protect light-weight processes from each other without taking the fairly large overhead of an OS process.
Q: Is the Application Domain a similar concept to the Java Package?
Anders Hejlsberg: No, a Java Package is a different thing. The closest analogy in .NET is an assembly.
Q: What are the plans to allow C# code to run on a PocketPC?
Peter Golde: We've announced that we'll have a ".NET Compact Framework" that will be optimized for portable devices. Obviously there are limitations in terms of the scope of the class library, memory limitations, and so forth compared to the desktop or server. I should add that one of the focuses of the ECMA standardization work is to standardize a library framework that is appropriate in size and scale for portable devices. There is obviously a large amount of interest in this from many companies.
A Conversation with Mark Anders and Scott Guthrie on ASP.NET
Scott Guthrie co-founded the ASP.NET Team and leads the design team responsible for architecting the product. His individual technical contributions include: ASP.NET Web Forms Page Architecture, ASP.NET Web Services Infrastructure, ASP.NET Compilation System, ASP.NET Distributed Session State Infrastructure, ASP+ Deployment Architecture, ASP.NET Reliability System, and the ASP.NET HTTP Runtime Architecture. Prior to ASP.NET, Scott was a member of the IIS and Windows NT teams.
As the Microsoft Product Unit Manager of the .NET Framework, Mark Anders leads the team that designs and develops the .NET Framework, including ASP.NET, Windows Forms, Base Class Libraries, and other class libraries. Prior to this, he co-founded the ASP.NET team and held lead positions in program management as well as development.
Q: Scott, Mark, if you had to pick one thing, what do you think is the single coolest developer feature of ASP.NET?
Mark Anders: Well, I'll tell you the feature that gets the most applause: it's tracing! Seriously, it's almost a spontaneous standing ovation. One guy who I showed it to said that it was "the coolest thing I've ever seen." (Note, I wouldn't go that far!) Actually, my favorite feature is server controls.
Scott Guthrie: I think the partial page output caching feature that we are going to ship in Beta2 is probably the coolest developer feature, because it can dramatically impact the performance of literally any site. The xcopy deployment features (no restart on DLL updates) we have I think also are pretty close.
Q: Tracing is a great feature. One of the questions we get a lot: is there any penalty for having all the tracing code but turning it off when going into production?
Scott Guthrie: There shouldn't be any noticeable performance difference when tracing is turned off (but code left in). One thing to keep in mind, though, is that if you have expensive "trace calculations" that you output as part of tracing, then you should scope it within an "if (Trace.Enabled = True) Then" block. When tracing is turned off, "Trace.Enabled" will return false
Mark Anders: Note that we don't gather all of the statistics if trace==false.
Q: Could you discuss the security of the config files. I have seen a lot of concern that since they are simple XML files, they can be hacked into easily.
Scott Guthrie: We do block all access to the config files from remote users. However, I think the concern people have is whether a rogue user who gets access to the config file can modify and take over things. Note that this problem exists with ASP today as well, in that the metabase APIs can be written to, which would effectively do the same thing. However, there are some things that you can do to reduce this problem. Specifically, with ASP.NET we support the ability to "lock down" settings at a parent directory. For example, you might want to lock down the security identity of the worker process (i.e.: the username it runs under) at the machine level and then restrict sub-applications' abilities to override it.
Q: I see confusion as to whether to mimic the Windows DNA model by creating ASP Presentation interfaces talking to COM+ components, or in the .NET era to just write code behind and stick Dynamic Link Libraries (DLLs) in the \BIN and be done with it.
Mark Anders: I would say that services provided by COM+ are still required if you want transactions. However, the model of using DCOM to put components on another box and scale out that way is not recommended.
Scott Guthrie: In general I would recommend continuing to logically partition your application code (which was one of the things Windows DNA suggested). For example, putting all of your data access logic within modular classes that you then call them from pages—like we do from the IBuySpy applications. ...In general, you shouldn't use COM+ transactions unless you are actually doing distributed transactions across multiple data store machines. If you are just updating a single database, then leverage the transaction capabilities within it.
Q: What if you are planning on using remoting to communicate between our first and middle tiers, and you've only gotten C# working? Are there any known issues today with using remoting to communicate from ASP to Visual Basic (VB)?
Scott Guthrie: There shouldn't be any problems doing remoting from VB (like C#), although you should be a little careful about how to use remoting. In many cases it is best not to do the extra network hop. There is a big performance penalty to going to the other machine, so you shouldn't look to do it for either performance or scalability reasons. It does make sense if you are connecting to a different application or data center, where for org/technical or political reasons you need code to run elsewhere.
Q: What if you want to use it to communicate from Web servers that are hosted at an outsourcer across a firewall back to the network where the databases are? For security reasons, we won't put the database out in the DMZ.
Scott Guthrie: One other possible solution you might also investigate for that would be to leverage ISA (Internet Security and Acceleration) server, where you would put ISA in front of the firewall, and then ASP.NET and the database behind it. We actually just finished doing some benchmarking numbers with that solution and saw really great results. It is also really easy to set up and administer, and might be easier to ultimately deploy and manage going forward. One nice thing about ISA is that it doesn't require any ASP.NET code changes to leverage it, so it is pretty easy to try out and evaluate.
Q: Could you comment on interoperability (via Session Objects, Query Strings, etc.) between ASP and ASP.NET? Any gotchas?
Mark Anders: There are a few. First, we've made the object models as close as possible. However, if for example you store COM objects (not new CLR objects) in sessions, and you want those to be out of proc, they won't work. You need to have new objects that can be serialized. One thing to note is that ASP and ASP.NET will run side by side on a box, because at an application level ASP and ASP.NET do not share sessions.
Q: I've seen a lot of concern that data can be passed page to page (ASP to and from ASP.NET).
Mark Anders: Since we really use standard Web techniques, passing info page to page should not be a problem. However, page to page in ASP and ASP.NET typically assumes services that are provided by each, such as session and application state. These services are not shared, and so you can't rely on them.
Scott Guthrie: I have a list of things you can do to ease migration of ASP code to ASP.NET.
1. Use only a single language within the ASP application. Don't intermix VBScript and JScript together in the same page (in general a bad programming practice with ASP, but also a migration issue for ASP.NET in that we now require only one inline <% %> language.
2. Explicitly declare all of ASP page functions within a <script language="VBScript" runat=server> block as opposed to <% %> blocks. In ASP.NET we no longer support this later function declaration option. It is just a copy/paste change in order to fix I
3. Explicitly use VBScript's "Option Explicit" keyword at the top of every ASP Page (this will become the default with ASP.NET and will also ensure that you write slightly better code today).
4. Use the "Call" keyword anytime they call a subroutine in VBScript today (for example: "Call FooBar (1, 2)"). This will enable/require them to wrap parenthesis around all subroutine arguments (if you don't use the "call" keyword, then VBScript today will raise a compilation error if you have parentheses). In VB.NET, parentheses are now required (note that the "call" keyword is still supported in VB.NET). So if they didn't use the "call" keyword, they'd have to go back and change all subroutines.
5. Avoid relying on "default properties" in VBScript, and instead fully qualify property references: (For example, with an ADO Recordset write: rs("a_name").Value instead of just rs("a_name")). Default properties are no longer supported in VB.NET.
6. Avoid using "render function" tricks (a specific unintended hack/trick that people can use in ASP but which was never intended as a feature). Instead explicitly use Response. Write blocks when constructing render functions.
Q: Scott, are there any estimates on the time needed to migrate a project from ASP to ASP.NET? I've seen a rough number of 5 percent of the development time to migrate a VB 6 project to VB.NET.
Scott Guthrie: I actually don't have any good time estimates. It's going to depend somewhat. In general, if you follow the ASP coding suggestion I posted above, then I think the porting effort should be pretty minimal (a day or two for even complex apps)
A Conversation with Brian Harry on the Common Language Runtime
Brian Harry is the Product Unit Manager for the Common Language Runtime. He has contributed to the design and features of the CLR from its very beginning, serving first as Development Manager and then as Product Unit Manager. Before the Common Language Runtime, Brian worked on SourceSafe and the Microsoft Repository. He joined Microsoft in 1994.
Q: We have heard a lot about possible support for generics in future versions of the runtime. Can you explain your current thinking about generics, and how they might be used i.e. functional languages, templates etc.?
Brian Harry: We have had an effort in Microsoft Research for over a year to design and implement generics in the Runtime. The research team has, in fact, already implemented generics in both the Runtime and the C# compiler. The product team has reviewed the design and implementation and is generally happy with the approach. It is similar to the implementation we have for arrays. You'll note that arrays are a form of generic (or parameterized type).
Q: Is the CLR for NT4 and Windows 2000 a fully self-contained module for deployment purposes? In other words, does it upgrade IIS on NT4 and supply all the elements needed as a fully self-contained entity?
Brian Harry: No, the CLR does not redistribute many other pieces of the operating system. We will have a set of pre-requirements that will specify the OS service pack, version of IE, etc. There will be a .NET Framework redistributable that is pared down from the SDK by quite a bit.
Q: What is the relationship between the CLR and the CLI that's been submitted to the W3C?
Brian Harry: The CLI is a specification for many of the core designs that the CLR implements. In addition to the CLI specification, the CLR implements many Windows specific features like COM interop, Windows Security Policy, Windows Forms, etc.
Q: Where are we in the ECMA process?
Brian Harry: We are working with the technical committees to refine the specifications for submittal. This is a fairly long process and involves a lot of input and consensus building.
Q: Please explain how Long and Short Weak References work and the usage scenarios for both.
Brian Harry: The differences between long and short weak references are when the object reference inside the weak reference gets nulled out.
Q: So if the reference is held after GC then it is considered long?
Brian Harry: For short references, the contained reference gets nulled out as soon as the object is deemed unreachable. This is ultimately more performant because we remove the reference sooner. Long weak references are nulled after the object has been finalized.
Q: What benchmarks have been run comparing the CLR to native code?
Brian Harry: We have run a large set of benchmarks comparing the CLR to native code and are still measuring and tuning performance. We have broken benchmarks down into a variety of categories, including: Web, rich Windows apps, Benchmarks and micro benchmarks. For Web we have compared mostly to ASP and a bit to JSP. ASP.NET proves to be substantially faster than both in almost every scenario. For rich windows apps we have taken a variety of forms-based apps and have focused on tuning working set and startup time. We have also done a variety of benchmarks like Spec 95, Spec 2000, Bytemark, etc.
Q: There have been a lot of questions about running transactions on the .NET platform. Care to comment?
Brian Harry: We fully support transactions on the .NET platform. We fully support the COM+ Services and have worked hard to make sure that writing CLR components is the best way possible to write software that takes advantage of the COM+ services.
Q: Is there a lot of sample code for leveraging transactions from within .NET code?
Brian Harry: Indeed, there are quite a lot of samples of using all of the COM+ services available. Some are in the SDK and some are on gotdotnet.com
Q: If I utilize COM+ on Windows 2000, will the CLR enable COM+ like functionality on NT4 or will some sort of MTS interop have to occur?
Brian Harry: We have not done anything to move COM+ Services to NT4. MTS is on NT4 and there have not been any recent updates to that code.
Q: Tell me about deployment of the CLR and Whistler—will it be native (in the shrink-wrap)?
Brian Harry: We have been looking at the schedules to decide whether the .NET Framework could ship with Whistler. No decision has been made, so I have nothing to announce.
Q: I am interested in your opinion of distributed transactions (two phase commit) over Web Services?
Brian Harry: My opinion is that you should not, in general be doing DTC style 2 phase commit across Web Services. I am not the expert on this, but Web Services were designed for loosely coupled computing and compensating transactions is a better approach to this style of application. That said, it is possible to build a tightly coupled app over web services, it just wasn't the design point.
Q: So if you need to span a transaction across two Web Services calls, use a compensating transaction on failure?
Brian Harry: Yes, that is my opinion, I'd be interested in what the COM+ Services team has to say about that, but I believe they would agree with me.
Q: Idempotent transactions then?
Brian Harry: I'm not sure what you mean by idempotent transaction. What I mean is a transaction that can be reversed.
Q: Can you talk about features of the CLR that help high volume applications run faster and more stable than our existing platforms? For example, memory allocation appears to be rather streamlined now that GC is in the picture.
Brian Harry: There are several aspects to the .NET Framework that help improve reliability and scalability. Starting with things like the built in thread pool, easy asynchronous programming, the general approach of a stateless server programming model that enables scale out, the ASP.NET process model that enables process recycling, auto restart, etc.
Q: I know that was a pretty generic question. Can you talk a little bit more about the built-in thread pool?
Brian Harry: The CLR has a thread pool that has been heavily optimized to cooperate with the GC and the managed environment. It has a very simple and approachable API but is very powerful. Further we are strongly promoting using the thread pool, especially in server apps rather than spinning up application threads to process work loads. Using the thread pool will result in a much more scalable application
Q: What exactly do you mean by "easy asynchronous programming."
Brian Harry: Easy asynchronous programming. I mean, there is a well-established design pattern, our frameworks expose it where appropriate, we enable many modes: callback, polling, subsequent block for completion, etc. Also, you can use asynchronous delegates to easily turn any API into an asynchronous API.
Q: How is interoperability testing going with the CLR being installed onto a system with many other apps already installed—Office, Visio, etc.?
Brian Harry: At a lower level type safe code helps reduce memory leaks, eliminates dangling pointers and deployment issues, all helping contribute to more reliable applications. We are thoroughly testing internally in every configuration we can imagine. Further, we are doing a VERY wide beta program. Recent data I saw showed that the .NET Framework Beta1 had reached almost 1 million people.
Q: What are the definite "no-no's" for developers writing to the CLR?
Brian Harry: Hmmm, most of the no-no's are the same as always—don't allocate too much memory, don't write n^2 algorithms, etc. The main things that are added, are you need to be careful where your managed/unmanaged boundaries are and how many times you cross them. You also need to be aware of security checks. Too many can kill your perf so you need to design for them.
Q: Can you comment on the CLR on other non-Windows platforms?
Brian Harry: We have a product under development called the .NET Compact Framework targeted at devices and designed to be very portable. We also have submitted the core specs to ECMA and expect to get a lot of cross platform implementations as a result of that.
Q: Are there design considerations for those writing applications to the CLR to make it easy to run on Starlite? I'm thinking architecture of the applications to make it easy to have a CLR version and a read-made Starlite version? "Ready-made" type.
Brian Harry: Yes, the .NET Compact Framework will have a subset of the overall .NET class libraries (in order to keep the size down) but it will also include device specific features (like wireless APIs). You can either write an app that targets .NET compact framework, leveraging the device APIs, or you can write one that targets the intersection with the desktop. I believe the docs will help you identify this intersection.
Q: In reference to string manipulation, it appears that we can no longer directly manipulate the buffer in managed code. For example, string[0] = 'a'. Instead we do something like string.Replace(0, 'a') and get a new string back.
Brian Harry: Yes, the reason for this is that strings are immutable. This makes for a simpler programming model and eliminates problems around synchronization and sharing of strings. In some cases, it allows us to give better performance by avoiding copying strings.
StringBuilder allows you to modify the string in place. A string builder can be converted to a string and then it becomes immutable.
Q: Does this mean if I had a member variable that is a StreamReader, I will need to implement it to be able to call the StreamReader's close method?
Brian Harry: StreamReader—It will depend on how your class is used, but if you are exposing it out to arbitrary clients, then yes you might want to.
Q: Under what conditions do I need to implement Idisposable.
Brian Harry: A class should implement IDisposable if it encapsulates "limited" resources. Examples are: window handles, file handles, database connections, etc. Anything where the user of the resource needs to be able to free itpreemptively.
Q: A related question is why do you really care about resurrection, i.e. getting the object back to life once it has died?
Brian Harry: Actually, I don't care about resurrection; it is a terrible thing in my opinion. It is somewhat of a necessary evil of the notion of Finalizers. We had a plan (which we may bring back in a future version) for something called "static finalizers" that would eliminate the possibility of resurrection.
Q: Is it true that deterministic finalization cannot be achieved because of resurrection, or am I mixing them here?
Brian Harry: No, deterministic finalization has nothing to do with resurrection. Resurrection is an issue after we have already run the finalizer. Deterministic finalization (as I have most frequently heard it used) has to do with not calling the finalizer at a well-defined point in time.
Q: Which brings us back to my question about when to use long and short weak references?
Brian Harry: Long/Short—As a general rule, always use short weak references. Only use long ones if you need to access the handle to find the object even during finalization. This is a very rare need. There are some caching schemes where this turns out to be valuable but I don't think I could describe them very well without spending a while to think about it.
……