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 () is extremely similar to synchronized () 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
网页模板、字体、软件、资料、资源部分是从国外大小网站收集而来，为朋友们在工作或学习时提高效率、节省时间.
站内所有资源仅供学习与参考，请勿用于商业用途，否则产生的一切后果将由您自己承担！
先声明这篇文章属于收藏性质的,推荐给那些喜欢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 (
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
网页模板、字体、软件、资料、资源部分是从国外大小网站收集而来，为朋友们在工作或学习时提高效率、节省时间.
站内所有资源仅供学习与参考，请勿用于商业用途，否则产生的一切后果将由您自己承担！