Concepts of Asp.Net

Editor's Notes

• #4: I’ve said earlier that the .nf unifies various programming models. Let me first go back a bit in history and describe some of the disparate programming models that have been very popular and that people use today. In the good old days of early Windows, you had the windows api. To write apps you fired up your C compiler, #included windows.h, created a winproc, handled your windows messages – basically the old Petzold style of windows programming. While this worked it was neither particularly productive, nor was it particularly very easy. Over time, various programming models on top of the windows api have emerged. VB: RAD…instantiate a form, drag components onto the form, write event handlers, and through delegation your code executes. MFC/ATL took a different view. The key concept here is sub classing. You subclass from an existing monolithic, object oriented framework. While this gives you more power and expressiveness, it doesn’t really match the ease or productivity of VB’s composition model. ASP: with the web, we’ve seen the emergence of the ASP model, where you write stateless code that’s embedded in html pages. If you look at this picture, one of the problems is that your choice of programming model also necessarily becomes your choice of programming language. This in unfortunate. If you’re a skilled MFC dev and you need to write some code in an ASP page – your skills don’t translate. Likewise, if you know a lot about VB, there’s not much that transfers to MFC. There also not a consistent availability of api. Each of these models has dreamt up there own solutions to a number of problems that are actually core and common to all of the models. For example, how do I deal with File I/O, how do I do string formatting, how do I do security, threading, etc. What the .nf does is unify all of these models. It gives you a consistent API that is available everywhere regardless of what language you use or what programming model you are targeting.
• #5: Hierarchical namespaces make it much easier for you to discover where code is. Contrast this with Windows api – it’s al flat and can be very difficult to find a particular piece of functionality. A hierarchical namespace within the system makes this much easier for you to explore and discover functionality. .NF has a unified type system. Everything is an object. This means the death of variant. Variants are now objects. There is one string type throughout the entire framework. All character data is unicode. The .nf is component oriented. This not only affects how you write code for runtime, but also makes it much easier for tools to provide a rich design time experience.
• #9: Let’s look at what the design goals for the .NET Framework are: Simplified development – make developers lives easier and more productive. allow devs to focus on better algorithms and on solving business problems. not implementation details of idiosyncrasies OO features, consistent api throughout using common design patterns, hierarchical namespaces Simplify Deployment – simply lower TCO to a reasonable level self describing apps, no registry, fix DLL Hell Unified programming models – VB, VC (MFC), Vid (ASP) all have diverging models. These development models needed to come together to in order to deliver on simplicity and productivity, especially amongst teams of developers Robust and Secure – We designed the platform to do everything it can to make your applications more robust and secure. Automatic memory management, Type safety guarantees, and structured exception handling all contribute to your applications being more robust and secure. Mulit-language platform – All programming languages are first class on the .NET Framework. They have the same access to the underlying platforms. None of the languages are in a penalty box. If you have been a closet Cobol (or any other language) user for years, now is the time to come out! Your language is first class on this platform.
• #11: The diagram above illustrates the process used to compile and execute managed code, that is, code that uses the CLR. Source code written in C#, VB.NET, or some other language that targets the CLR is first transformed into MSIL by the appropriate language compiler. Before execution, this MSIL is JIT compiled into native code for whatever processor the code will run on. The default is to JIT compile each method when it is first called, but it’s also possible to “pre-JIT” the MSIL. With this option, all methods are compiled before the application is loaded, so the overhead of JIT compilation on each initial method call is avoided. One point worth noting is that all languages targeting the CLR should exhibit roughly the same performance. While some compilers may produce better MSIL code than others, large variations in execution speed are unlikely.
• #12: Let me again point out that the .Net platform is truly language neutral. All .net languages are first class. All have complete access to the entire platform. It’s simply not the case that one language has more or different capabilities than another. So when you move to the .net platform you can completely leverage all of you existing skills. In order to ensure this, we’ve defined what we call the common language specification. We’ve done this in conjunction with a number of partners. This is a spec of functionality that you can expect to find in any language that has been implemented on top of the .net platform. Because the CLS must be the union of all capabilities of all languages targeting .net, there are certainly some features of individual language that are not part of the CLS definition. For example pointers are not a part of the CLS because they couldn’t be directly consumed by all other .net languages. But this doesn’t mean that C++ doesn’t have pointers – of course C++ has pointers. It just means that you can use pointers internally in a C++ app, or you could even expose pointers in a C++ component you’ve written, but then that component may not be useable by all other .net languages – jscript, for example. We are providing five .Net languages. Third parties are providing a wealth of others. Again, this goes to show the truly multi-lingual nature and design that was implemented with .NET from the bottom up.
• #22: Microsoft is committed to open standards work with the .NET Framework. We have submitted parts of the .NET Frameworks and the C# Programming language to ECMA for Standardization. ECMA is a large industry standards body with a history of producing great standards. Over this last year I severed as member of the technical committees that prepared these specifications for adoptions as a standard. And I am happy to report that all the technical work is on the first version of the standard is complete. The ECMA general assembly will vote in December to approve this work as an industry standard. This work would not have been possible without the broad industry support we had from our co-sponsors HP and Intel and well as contributions from IBM, Fujitsu, and many others. The Common Language Infrastructure i
• #27: SUMMARY Rework the performance characteristics of the CLR, to make code which has performance characteristics that are far more akin to native code Our main investment is to reduce the marginal cost of yet another managed process, because by LH, there will be TONS of them. It’s a long-term goal, with important benefits Reduce startup time and working set: it is currently around 50% better than Everett NGen becomes an incredibly important consideration for systems programming using .NET. It is a large part of our performance focus. Note: When you are running NGened code, we used to have to pull data out of both the NGened image, and the il image. We no longer have to do this, we only load pages from the NGened image. This simply helps with the ‘cleanliness’ of the way this occurs. Its also essential for achieving the reduction of working set. Note: NGen is a technology you use to improve the performance of shared code, and startup time. If you’re not sharing, and you’re not starting up all the time, NGen loses some of its value Note: we’re also simplifying the use of NGen. It used to be that if you had a graph of assemblies, you had to NGen bottom up. That is, you had to NGen assembly a, then b, and finally c, which referenced b, which referenced a. Now, we walk the graph for you, we do the right things for you to help you out. All of the managed code in the OS will NOT be jitted: They are on the ‘no jit’ plan. It wall all be native code that has been NGened ahead of time. We are working heavily on NGen. When we started this exercise, if you had a native NGen image, we would ‘dirty’ some of those pages. For every 100K of the image in your working set, 40% was unshareable. Now, we are at 15-20%. We have therefore reduced significantly the amount of managed memory. Perf is not across the board better: Reason: There are swaggers of new bits and new functionality, which offset perf improvements Example: reliability is a major theme/goal (for Yukon), and reliable code is not necessarily the most efficient code. To take code that used to fail in unknown/crappy ways, and instead, make it either not fail, or fail in well-defined ways, comes with a cost NGEN: What is it? Compiles IL to native code Figures out class layout Saves results permanently on-disk Advantages? IL already compiled to native => no need to do it again! Class layout already done => so faster startup No need to load JIT => saves memory (can reduce WorkingSet by several tens of %)
• #29: PKI/CS7 support This is a signing, and encryption algorithm, which we didn’t support previously, but we do now Anyone who wants to do signing and encryption may want to use this. Note: Authenticode uses this standard (just to give an idea of where it comes up) It’s a binary format, its very fast We probably want to mention XML encryption. It’s a standard for encrypting data. It’s a w3c standard Its in the same namespace as xml digital signatures (System.Security.Cryptography.Xml) Its an implementation of the w3c standard for xml encryption Note we did support xml signing previously, this new stuff is supporting encryption Its basically a syntax for exchanging encrypted data. Its like a schema (+ process rules) for exchanging encr. Data, The data you encrypt can be anything. The package you send, is xml X509 certificates In 1.1 we had x509 certificate class. In V2.0 we have added X509CertificateEx, which: Covers far more of the unmanaged functionality available Look at spec for pointers The new Ex class is integrated with the XML cryptography classes (XML classes take X509 certificates directly) New Tool: Permission Calculator Calculates the permissions required at compile time for a given app (integrated into VS) From this, you can figure out, if your targeting a specific zone (such as internet zone) what permissions your app needs, which aren’t supported in that zone AWESOME! <Beware: at this stage, there are some whacky things you can do to trick the tool. But it is 95% accurate for a standard app> Example: It will tell you if you need ‘FileIOPermission’ . It won’t tell you what kind of permission, or to what file (it will try, but at that point, it becomes a little less specific) In other words: it does as much as it can Continuing in that scenario, this integrates well into ClickOnce (ClickOnce = Web style deployment of client applications) When you compile a ClickOnce app, a manifest is generated, describing what permissions the application needs. If someone tries to access that ClickOnce application, we figure out what permissions the app would have, and determine if this is a difference (based on the manifest). If so, the user is prompted to determine if the app is acceptable to run, based on that difference Enhanced the SecurityException We noticed that some people were not adopting the CAS model as readily as we expected, and it become clear, that the lack of information available on the SecurityException wasn’t helping. Basically, people couldn’t figure out what was wrong when a SecurityException occurred, and therefore, they simply elevated trust or permissions to avoid the exception. This of course, is the wrong approach. The point is to give developers more information about the nature of the exception, so they can debug more easily. Example improvements include: We now include what kind of exception it was: was it a link demand, for example Full assembly information, so developers can figure out what assembly was the cause of the exception PermissionState not populated consistently in V1/V1.1. We’ve fixed that Integrated with VS, so the UI experience is better when you get a SecurityException Debug-In-Zone The ability to run and debug your application in a specific security context, so that you can debug, and get the ACTUAL user experience, so you know precisely how your app will behave, compared to the way you deploy it