Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Concepts of Asp.Net
Similar a Concepts of Asp.Net (20)
Último
Último (20)
Concepts of Asp.Net
- 1. The Global Open University Nagaland ASP.NET Special Tips & Tricks
- 2. Agenda Part I - Fundamentals Programming Models Design Goals and Architecture CLR Services– Visual Studio 2005
- 3. Unify Programming Models Windows APIWindows API .NET Framework.NET Framework Consistent API availability regardless ofConsistent API availability regardless of language and programming modellanguage and programming model ASPASP Stateless,Stateless, Code embeddedCode embedded in HTML pagesin HTML pages MFC/ATLMFC/ATL Subclassing,Subclassing, Power,Power, ExpressivenessExpressiveness VB FormsVB Forms RAD,RAD, Composition,Composition, DelegationDelegation
- 4. Make It Simple To Use Organization Code organized in hierarchical namespaces and classes Unified type system Everything is an object, no variants, one string type, all character data is Unicode Component Oriented Properties, methods, events, and attributes are first class constructs Design-time functionality
- 5. How Much Simpler? HWND hwndMain = CreateWindowEx(HWND hwndMain = CreateWindowEx( 0, "MainWClass", "Main Window",0, "MainWClass", "Main Window", WS_OVERLAPPEDWINDOW | WS_HSCROLL | WS_VSCROLL,WS_OVERLAPPEDWINDOW | WS_HSCROLL | WS_VSCROLL, CW_USEDEFAULT, CW_USEDEFAULT,CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,CW_USEDEFAULT, CW_USEDEFAULT, (HWND)NULL, (HMENU)NULL, hInstance, NULL);(HWND)NULL, (HMENU)NULL, hInstance, NULL); ShowWindow(hwndMain, SW_SHOWDEFAULT);ShowWindow(hwndMain, SW_SHOWDEFAULT); UpdateWindow(hwndMain);UpdateWindow(hwndMain); Form form = new Form();Form form = new Form(); form.Text = "Main Window";form.Text = "Main Window"; form.Show();form.Show(); Windows APIWindows API .NET Framework.NET Framework
- 6. Hello World Demo What you need
- 7. Agenda Part I - Fundamentals Programming ModelsProgramming Models Design Goals and Architecture CLR ServicesCLR Services
- 8. Common Language Runtime Design Goals Dramatically simplifies development and deployment Unifies programming models Provides robust and secure execution environment Supports multiple programming languages
- 9. Architectural Overview ComCom FrameworkFramework Class loader and layoutClass loader and layout GC, stack walk, code managerGC, stack walk, code manager ILtoILto nativecodenativecode compilerscompilers SecuritySecurity ExecutionExecution SupportSupport Base ClassesBase Classes
- 10. AssemblyAssembly Compilation And Execution SourceSource CodeCode LanguageLanguage CompilerCompiler CompilationCompilation At installation or theAt installation or the first time eachfirst time each method is calledmethod is calledExecutionExecution JITJIT CompilerCompiler NativeNative CodeCode Code (IL)Code (IL) MetadataMetadata
- 11. Languages The CLR is Language Neutral All languages are first class players You can leverage your existing skills Common Language Specification Set of features guaranteed to be in all languages We are providing VB, C++, C#, J#, JScript Third-parties are building APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk…
- 12. Hello World Demo What you needWhat you need MSIL
- 13. Agenda Part I - Fundamentals Programming ModelsProgramming Models Design Goals and ArchitectureDesign Goals and Architecture CLR Services
- 14. Component-Based Programming 3 core technologies make building and using components easy Type safety Automatic memory management Metadata This greatly simplifies application development
- 15. Type Safety Type safety ensures that objects are used the way they were intended to be used Prevents an object’s state from being corrupted The CLR enforces type safety Attempting to coerce an object to an incompatible type causes the CLR to throw an exception Type safety means code confidence Common programmer errors will be found immediately Rectangle(hwnd, 0, 0, 10, 10); //hwnd should be an hdc MessageBox(hwnd, “”, “”, IDOK); //IDOK should be MB_OK
- 16. Automatic Memory Management The CLR tracks the code’s use of objects and ensures Objects are not freed while still in use (no memory corruption) Objects are freed when no longer in use (no memory leaks) Code is easier to write because there is no question as to which component is responsible to free an object When passed a buffer, who frees it: caller or callee? Each process has 1 heap used by all components Objects can’t be allocated from different heaps You don’t have to know which heap memory was allocated in or which API to call to free the memory ○ In fact, there is no API to free memory, the GC does it
- 17. Metadata Set of data tables embedded in an EXE/DLL The tables describe what is defined in the file (Type, fields, methods, etc.) Every component’s interface is described by metadata tables A component’s implementation is described by Intermediate Language The existence of metadata tables enables many features No header files Visual Studio’s IntelliSense Components don’t have to be registered in the registry Components don’t need separate IDL or TLB files The GC knows when an object’s fields refer to other objects An object’s fields can be automatically serialized/deserialized At runtime, an application can determine what types are in a file and what members the type defines (also known as late binding) Components can be written/used by different languages
- 18. Metadata: Creation And Use MetadataMetadata (and code)(and code) DebuggerDebugger SchemaSchema GeneratorGenerator ProfilerProfiler CompilersCompilers Proxy GeneratorProxy Generator Type BrowserType Browser CompilerCompiler SourceSource CodeCode XML encodingXML encoding (SDL or SUDS)(SDL or SUDS) SerializationSerialization DesignersDesigners ReflectionReflection TLB ExporterTLB Exporter
- 19. Runtime Execution Model ClassClass LoaderLoader CPUCPU ManagedManaged Native CodeNative Code AssemblyAssembly First callFirst call to methodto method First referenceFirst reference toto typetype AssemblyAssembly ResolverResolver First referenceFirst reference to Assemblyto Assembly IL to nativeIL to native conversionconversion
- 20. JIT Compiler - Inline
- 21. Standardization A subset of the .NET Framework and C# submitted to ECMA ECMA and ISO International Standards Co-sponsored with Intel, Hewlett-Packard Common Language Infrastructure Based on Common Language Runtime and Base Framework Layered into increasing levels of functionality
- 22. Rotor (SSCLI) Shared-Source version of the CLR+BCL+C# compiler Ports available: Windows, FreeBSD, OSX, etc Real product code offers real world learning http://sscli.org
- 23. Developer Roadmap • ““Orcas” releaseOrcas” release •Windows “Longhorn”Windows “Longhorn” integrationintegration •New UI tools andNew UI tools and designersdesigners •Extensive managedExtensive managed interfacesinterfaces Visual Studio OrcasVisual Studio Orcas “Longhorn”“Longhorn” Visual StudioVisual Studio .NET 2003.NET 2003 • ““Everett Release”Everett Release” •Windows Server 2003Windows Server 2003 integrationintegration •Support for .NET CompactSupport for .NET Compact Framework and deviceFramework and device developmentdevelopment •Improved performanceImproved performance Visual Studio 2005Visual Studio 2005 “Yukon”“Yukon” • ““Whidbey” releaseWhidbey” release •SQL Server integrationSQL Server integration •Improved IDE productivityImproved IDE productivity and community supportand community support •Extended support forExtended support for XML Web servicesXML Web services •Office programmabilityOffice programmability
- 24. Agenda Part I - FundamentalsPart I - Fundamentals Design GoalsDesign Goals ArchitectureArchitecture CLR ServicesCLR Services
- 25. Agenda Part I - FundamentalsPart I - Fundamentals Design GoalsDesign Goals ArchitectureArchitecture CLR ServicesCLR Services
- 26. PerformanceObjectives: make .NET an even greater programming platform Long-Term: make the performance characteristics of the CLR similar to native code Reduce marginal cost of additional managed processes Reduce startup time and working set NGen Compiles IL code to native code, saving results to disk Advantages: no need to recompile IL to native code, and class layout already set so better startup time Whidbey: Significant reductions in the amount of private, non-shareable working set OS: ‘no-Jit’ plan, all managed code will be NGened
- 27. TryParseTryParse
- 28. CLR Security New cryptography support PKI and PKCS7 support XML encryption support Enhanced support for X509 certificates Enhanced Application Security Permission Calculator ○ Integration with ClickOnce Better SecurityException Debug-In-Zone Managed ACL Support
- 29. This material has been taken from Online Certificate course on ASP.NET from Global Open University Online certification programme. For complete course material visit: http://tgouwp.eduhttp://tgouwp.edu About Global Open University : The global open university is now offering certification courses in various fields. Even you can study, give exam from comfort of your home. These are short term and totally online courses. For more details you can visit: Email id: info@tgouwp.edu THANKS for being here
Notas del editor
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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 %)
- 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