.Net Framework Joel Pereira

.Net Framework Joel Pereira (joelcdp@microsoft.com)
Software Design Engineer WinFS API Team Microsoft Corporation

Agenda Part I - Fundamentals Part II – Visual Studio 2005
Programming Models Design Goals and Architecture CLR Services Part II – Visual Studio 2005 Extending the Platform Improving the Platform Innovation in the Platform

Unify Programming Models
.NET Framework Consistent API availability regardless of language and programming model VB Forms RAD, Composition, Delegation MFC/ATL Subclassing, Power, Expressiveness ASP Stateless, Code embedded in HTML pages 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. Windows API

Make It Simple To Use Organization Unified type system
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 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.

How Much Simpler? Windows API .NET Framework
HWND hwndMain = CreateWindowEx( 0, "MainWClass", "Main Window", WS_OVERLAPPEDWINDOW | WS_HSCROLL | WS_VSCROLL, CW_USEDEFAULT, CW_USEDEFAULT, (HWND)NULL, (HMENU)NULL, hInstance, NULL); ShowWindow(hwndMain, SW_SHOWDEFAULT); UpdateWindow(hwndMain); .NET Framework Form form = new Form(); form.Text = "Main Window"; form.Show();

Hello World Demo What you need

Common Language Runtime Design Goals
Dramatically simplifies development and deployment Unifies programming models Provides robust and secure execution environment Supports multiple programming languages 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.

Architectural Overview
Framework Base Classes Common Language Runtime IL to native code compilers Security Execution Support GC, stack walk, code manager Class loader and layout

Compilation And Execution
Assembly Code (IL) Source Code Language Compiler Metadata Execution JIT Compiler Native Code 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. At installation or the first time each method is called

Languages The CLR is Language Neutral Common Language Specification
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… 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.

Hello World Demo What you need MSIL

Component-Based Programming
3 core technologies make building and using components easy Type safety Automatic memory management Metadata This greatly simplifies application development

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

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

Managed Data Lifetime Managed by Runtime (GC)
Compacting GC eliminates fragmentation and reduces working set Data may be moved during collection Object references are updated automatically No more intrusive than a page fault Layout Provided by Runtime Usually automatic Metadata can specify Order Packing Explicit layout

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

Metadata: Creation And Use
Serialization Reflection Source Code TLB Exporter Designers Compiler Compilers Debugger Metadata (and code) Type Browser Profiler Proxy Generator Schema Generator XML encoding (SDL or SUDS)

Runtime Execution Model
Assembly Class Loader First reference to type IL to native conversion Assembly Resolver First reference to Assembly Managed Native Code First call to method CPU

Assemblies Collections of types and binding information
Unit of deployment One or more files, independent of packaging Self-describing via metadata (“manifest”) Unit of Versioning Captured by compiler Policy per-application as well as per-machine Security boundary Assemblies are granted permissions Methods can demand proof that a permission has been granted to entire call chain Mediate type import and export Types always referenced relative to assembly

Assembly Identity Assemblies can be Private or Shared
Private – used only by a single application Shared – used by any installed application Shared assemblies are identified by Name – such as System.Drawing Publisher – such as Microsoft Identified with publishers key Version – 4 part version number Not associated with product version Culture Easier localization

Assembly Storage Private Assemblies Shared Assemblies
Installed in application directory Xcopy deployment, Not registration Zero impact install, copy and run Shared Assemblies Installed in Global Assembly Cache (GAC) Extensive binding policy support Use specific version, Publisher policy Policy control per machine or per application

Assembly Binding Applications are configurable units
Made up of one or more assemblies Application-specific files or data Assemblies are located based on… Assembly Identity and The binding policy of the application Applications can have private versions of assemblies Version policy can be per-application

Compiling IL To Native Econo JIT (not a v1 deliverable) Standard JIT
Generates un-optimized native code Code can be discarded and regenerated Most portable JIT compiler Standard JIT Generates optimized native code Includes verification of IL code Install time code generation (Pre-JIT) Done at install time Reduces start-up time Native code has version checks and reverts to runtime JIT if they fail PreJIT not available in Beta 1, on-demand may not ship in V1

Exception Handling Language neutral exception model
Supports both typed and filtered exceptions Compilers emit EH tables Handlers located based on EH Tables 2 pass algorithm, Find handler, handle exception Very little overhead in the non-exceptional case Tightly integrated with Structured Exception Handling PreJIT not available in Beta 1, on-demand may not ship in V1

JIT Compiler - Inline

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 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

Rotor (SSCLI) Shared-Source version of the CLR+BCL+C# compiler
Ports available: Windows, FreeBSD, OSX, etc Real product code offers real world learning

Calling Unmanaged Code
Common Language Runtime Managed Object Unmanaged Object Managed Object Unmanaged Code

COM Interop Provides a bridge between the runtime and COM and vice versa Maintains programming model consistency on both sides Abstracts the inconsistencies between the two models Different data types Method signatures Exception/Hresults Activation models Object discovery

Platform Invoke (P/Invoke)
Provides access to static entry points in unmanaged DLLs Similar to: VB Declare statement Load library / GetProcAddress Requires method definition with custom attribute Uses same underlying marshaling service as COM Interop

Visual Studio Orcas “Longhorn”
Developer Roadmap Visual Studio Orcas “Longhorn” Visual Studio 2005 “Yukon” “Orcas” release Windows “Longhorn” integration New UI tools and designers Extensive managed interfaces Visual Studio .NET 2003 “Whidbey” release SQL Server integration Improved IDE productivity and community support Extended support for XML Web services Office programmability “Everett Release” Windows Server 2003 integration Support for .NET Compact Framework and device development Improved performance

Agenda Part I - Fundamentals Part II – Visual Studio 2005 Design Goals
Architecture CLR Services Part II – Visual Studio 2005 Extending the Platform Improving the Platform Innovation in the Platform

SQL Server Integration Design Goal
Bring framework programming model into the database tier Allow business logic to easily migrate to the most appropriate tier Enable safe database extensions Result: Stored Procedures, Triggers, data types defined in managed code This slide is trying to set up a problem, which WE fixed. In other words, programming in the DB had these problems: here’s how managed code helps We are NOT saying that all stored-procs should be brought into managed code: we are saying that some of it is best in the DB, and some is best in the middle tier: If something is data intensive, its best in the DB (say, some operation that adds 0.5 to everyone’s GPA) Any kind of display, or rich-editing of the data should be middle-tier Anything which is complex manipulation, or editing of the data would be good for middle-tier I am not a DB programming guru: I don’t know, or even like T-SQL. What this feature allows you to do is program in managed code, at the database level Enable safe db extensions: Today, you can only do a certain number of things in the DB (its basically limited to what you can do in the internet zone). This allows you to write an extended stored procedure, but in a SAFE way. That is, it allows you to do potentially unsafe things, but it gives you a safe infrastructure. The safe infrastructure is basically the same as the experience in IE. If you try doing an unsafe thing, you’ll get a warning, or be disallowed from doing it. There’s a broad objective here of course: allow other environments to host the CLR, allowing truly integrated managed code. SQL Server is the first example, but there will be many others.

Define Location.Distance() CLR hosted by SQL (in-proc)
SQL CLR Functionality VB, C#, … Build Assembly: geom.dll VS .NET Project SQL Data Definition: create assembly … create function … create procedure … create trigger … create type … Define Location.Distance() SQL Server CLR hosted by SQL (in-proc) How it works… Bill, just bangs out code in VS to access ADO, and he writes a method could Distance (on Location class). He builds it, and he gets an assembly. This is how it works today. Now what he does is, he opens up SQL Server, and he creates the assembly, by pointing it at the assembly he already made: this sucks his assembly into the database. Then, he creates a function, which he says ‘map this function in the db, to this function exposed in the assembly he has’ HUGE thing to point out: everything is IN PROCESS: this is one of the biggest advantages, and improvements resulting from this work. This is great for performance. Note, there is a problem here, which is if the clr crashes, so does sql server. However, we have spent a LOT of time ensuring that the clr is reliable enough, to NOT crash. For most people, what they can do is achieve this all from VS. You can apply an attribute (get name from Scott) to functions, and then simply select your assembly, and ‘deploy’ it to the database, which then sucks in the appropriate functions, based on the existence of the attribute. SQL Queries: SELECT name FROM Supplier WHERE Location.Distance ) < 3

Sql Programming Model Splitting a string
T-SQL The old way…. varchar(200) = 'Microsoft Corporation|SQL Server|2003|SQL-CLR| |11:32:00|Document|3.b.3' SELECT + '|', 0 + 1, + '|', 0 + 1) ), + '|', + '|') + 1, + '|', + '|') + 1) - + '|') - 1 ), + '|', + '|', + '|') + 1) + 1, + '|', + '|', + '|') + 1) + 1) - + '|') + 1) - 1 ), + '|') + 1) + 1) + 1, + '|') + 1) + 1) + 1) - + '|') + 1) + 1) - 1 ), + '|') + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) - 1 ), + '|') + 1) + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) + 1) - 1 ), + '|') + 1) + 1) + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) + 1) + 1) - 1 ), + '|', + '|', + '|') + 1) + 1) + 1) + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) + 1) + 1) + 1) - 1 ) varchar(200) = 'Microsoft Corporation|SQL Server|2003|SQL-CLR| |11:32:00|Document|3.b.3' + '|', 0 + 1) ), + '|', 0 + 1, SELECT + '|', + '|') + 1, + '|') + 1) - + '|', + '|') - 1 ), + '|', + '|', + '|') + 1) + 1, + '|', + '|', + '|') + 1) + 1) - + '|') + 1) - 1 ), + '|') + 1) + 1) + 1, + '|') + 1) + 1) + 1) - + '|') + 1) + 1) - 1 ), + '|') + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) - 1 ), + '|') + 1) + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) + 1) - 1 ), + '|') + 1) + 1) + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) + 1) + 1) - 1 ), + '|', + '|', + '|') + 1) + 1) + 1) + 1) + 1) + 1) + 1, + '|') + 1) + 1) + 1) + 1) + 1) + 1) + 1) - + '|') + 1) + 1) + 1) + 1) + 1) + 1) - 1 )

Strongly Typed Resources

Moving to 64 bit 64 bit for Servers and workstations
X64 and IA64 bit support Enable Yukon and ASP.NET Verifiable managed binaries just run! VS: Runs as a 32bit application You can develop, deploy, and debug 32 and 64bit applications X64 is both AMD chips, and the Intel (Stretch) chips also Intel actually terms their stuff as Stretch, or CT ASP and Yukon we have actively tested on 64bit machines through stress, IDW, etc., to ensure they work without a hitch Talking point: we are also actively testing longhorn on 64bit, and its running beautifully Verifiable managed binaries just run! This means that if you’re not interoping, pinvoking it MAY not work. If its completely managed code, then it WILL work If you’re pinvoking, and you include the right calls for a 32 bit machine, it will work If you are pinvoking to unmanaged code which is built JUST for a 32 bit machine, then you will have to run in the Wow Everett apps, will ALWAYS run in the Wow Whidbey apps can make a choice. By default, it will run natively. But if you make a call to an 32bit unmanaged API and you find your app to be broken, you can recompile your application telling us to explicitly run in the Wow Message: the more you can stay in managed code, the better off you are What did the clr have to do to make the clr work on a 64bit machine? Examples include… We had to make a new Jitter (we had to change the codegen to support the two new instruction sets) We had to redesign parts of the GC to handle LARGE amounts of memory Exception handling had to change (we had to redesign the way the exception model works. We do table-based exception handling) We TESTED like crazy What’s the point? To make your application run the same How do we know: devlabs with 40 customers running their apps, this is all true 32 bit only managed apps are, for example: Advanced MC++ apps Dependencies on 32 bit unmanaged APIs Easily made run by: Avoid 32 bit explicit layout Use IntPtr or SafeHandle rather than Int32

Performance Objectives: 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 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 %)

Performance everywhere
New, Performant APIs APIs for faster resource lookup Lightweight CodeGen: only generates essential code (contrast to Reflect Emit) Existing APIs Improved Cross AppDomain Remoting Between 1.1 and 200x faster. Biggest gains for simpler items (strings, integers, serializable objects) Delegate invoke performance has more than doubled AppDomain Footprints: significantly reduced UTF8Encoding: translation is 2.5x faster General improvements Resource Lookup: Currently, we use serialization to store and retrieve things such as images. We have new APIs however, which allow use to store things as streams, or byte arrays. This is much faster than the existing storage mechanisms Cross AppDomain remoting: between 1.1 and 200x faster. In other words, its pretty much faster across the board. Simple things (for example, strings, ints, or serializable types) are MUCH faster, more complex things are only marginally faster Reduced the memory footprint per appdomain significantly (if asked, say in the range of a factor of 2) Delegates: we have more than doubled the performance of invoking a delegate, < and we’re going to vastly improve the time to create a delegate > Lightweight CodeGen: old reflection emit would basically make an assembly file with types, etc, when all you wanted was a method or two. Lightweight codegen just emits the necessary code (the method body IL) and turns it into a delegate. So you call the delegate, it jits that one method: the REAL cool part is when you’re done, you let go of the delegate, and the code is also recycled. With the old reflection emit code, we had no way to unload the generated code, except to unload the appdomain. You no longer have to do this Stopwatch; great for timing for MEASURING perf (our architect encourages you to use this class to measure your perf) UTF8Encoding: is much improved, it’s 2.5X faster, a big win for ASP.NET (talk to Anthony)

TryParse

RAD Debugging Edit and Continue: Edit Code at runtime
Allowed Edits: Examples Add private fields to a class Add private non-virtual methods to a class Change a function body, even while stepping Disallowed Edits: Examples Removing fields/methods Edits to generic classes Serialization will not recognize new fields Display Attributes for a better debugging experience

Debugger Display Views

CLR Security New cryptography support Enhanced Application Security
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 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

IO and other Improvements

Generics Why generics? VB, C#, MC++ produce & consume generics
Compile-time type checking Performance (no boxing, no downcasts) Reduced code bloat (typed collections) VB, C#, MC++ produce & consume generics Use generics freely in internal APIs Consider using generics in public APIs Generics are not yet in CLS To be CLS compliant, provide a non-generic API alternative Microsoft is actively pursuing standardization of generics in runtime and languages

Generics C# public class List { private object[] elements;
private int count; public void Add(object element) { if (count == elements.Length) Resize(count * 2); elements[count++] = element; } public object this[int index] { get { return elements[index]; } set { elements[index] = value; } public int Count { get { return count; } public class List<ItemType> { private ItemType[] elements; private int count; public void Add(ItemType element) { if (count == elements.Length) Resize(count * 2); elements[count++] = element; } public ItemType this[int index] { get { return elements[index]; } set { elements[index] = value; } public int Count { get { return count; } List<int> intList = new List<int>(); intList.Add(1); // No boxing intList.Add(2); // No boxing intList.Add(“3"); // Compile-time error int i = intList[0]; // No cast required List intList = new List(); intList.Add(1); intList.Add(2); intList.Add(“3"); int i = (int)intList[0]; List intList = new List(); intList.Add(1); // Argument is boxed intList.Add(2); // Argument is boxed intList.Add(“3"); // Should be an error int i = (int)intList[0]; // Cast required

Generics in VB VB Dim intList As New List(Of Integer)
Public Class List(Of ItemType) Private elements() As ItemType Private elementcount As Integer Public Sub Add(ByVal element As ItemType) If elementcount = elements.Length Then Resize(elementcount * 2) elements(elementcount) = element count += 1 End Sub Public Default Property Item(ByVal index As Integer) As ItemType Get Return elements(index) End Get Set (ByVal Value As ItemType) elements(index) = Value End Set End Property Public ReadOnly Property Count As Integer Return elementcount End Get End Class Dim intList As New List(Of Integer) intList.Add(1) ‘ No boxing intList.Add(2) ‘ No boxing intList.Add(“3") ‘ Compile-time error Dim i As Integer = intList(0) ’ No cast required

Generics in C++ C++ generic<typename T> public ref class List {
array<T>^ elements; int count; public: void Add(T element) { if (count == elements->Length) Resize(count * 2); elements[count++] = element; } property T default [int index] { T get() { return elements[index]; } void set(T value) { elements[index] = value; } property int Count { int get() { return count; } }; So of course we have C++ as well… List<int>^ intList = gcnew List<int>(); intList->Add(1); // No boxing intList->Add(2); // No boxing intList->Add(“3"); // Compile-time error int i = intList[0]; // No cast required

Enhancing the Base Library Generic Collections
System.Collections.Generic classes List<ItemType> Dictionary<K, V> Stack<ItemType> Queue<ItemType> System.Collections.Generic interfaces IList<ItemType> IDictionary<K, V> ICollection<ItemType> IEnumerable<ItemType> IEnumerator<ItemType> IComparable<OperandType> IComparer<OperandType>

Enhancing The Base Library Other Generics to look out for
Nullable(Of T) Extremely useful for situations where null is a value, such as database valuetypes EventHandler<T> Saves on making your own EventHandlers Dim intVal as Nullable(Of Integer) = 5 If intVal.HasValue Then ‘ checks for a value delegate void EventHandler<T>(Object sender, T e) where T : EventArgs;

Whidbey Tracing Features
Pluggable Formatters Pre-Whidbey : Formatting of Trace information was predefined, and not controllable Whidbey : Predefined formatters (delimiter, xml) added, and you can make your own MySource;Error;13;Wrong key;;;;;; ; Additional Listeners Pre-Whidbey : No Console listener, ASP had their own tracing mechanism Whidbey : Added Console listener. Integrated ASP tracing into our own, and added ETW listener An example is that now, you can trace to a comma separated list, which can more easily be analyzed in excel, or by automated tools On first subject, include on slide, specify the config setting that achieves this:

Auto-generated Data Pre-Whidbey : Standard information such as timestamp or callstack would have to be explicitly generated Whidbey : An Admin can easily generate this data automatically, via config settings <listeners> <add name="examplelog" type= … Simple Thread Identification Pre-Whidbey : specific threads were difficult to identify, and filter on Whidbey : Correlation ID has been added, which allows quick and easy identification of a thread, and simple subsequent filtering

Listener Filtering Pre-Whidbey : Formatting of Trace information was predefined, and not controllable Whidbey : Assign filtering to listeners, so only certain messages are traced. This allows filtering on any property of a message. E.g., ID, TimeStamp, etc. Switches Pre-Whidbey : Couldn’t determine what tracing a component supported Whidbey : Support the ability to determine what tracing mechanisms a component has

MemoryPressure

Summary Extending the Platform Improving the Platform
SQL Server Integration Moving to 64 bit Improving the Platform Performance work RAD Debugging Security improvements Innovating in the Platform Generics support BCL Enhancements

Attend a free chat or web cast
List of newsgroups communities/newsgroups/en-us/default.aspx MS Community Sites Local User Groups Community sites

Resources BCL Blog BCL Website BCL public mail alias Reference
BCL Website BCL public mail alias Reference .NET Framework Standard Library Annotated Reference Applied Microsoft .Net Framework Programming

Q & A:

Backup

Diagnostics

Enhancing the Base Library System.Diagnostics for Enterprise
PerformanceCounter Integrated with WMI EventLog Custom Message Resources Structured Data Tracing Correlating Trace Events Tracing Integrated with ASP.NET Tracing Integrated with ETW

Pluggable Formatters Pre-Whidbey : Formatting of Trace information was predefined, and not controllable Whidbey : Predefined formatters (delimiter, xml) added, and you can make your own MySource;Error;13;Wrong key;;;;;; ; Additional Listeners Pre-Whidbey : No Console listener, ASP had their own tracing mechanism Whidbey : Added Console listener. Integrated ASP tracing into our own, and added ETW listener An example is that now, you can trace to a comma separated list, which can more easily be analyzed in excel, or by automated tools On first subject, include on slide, specify the config setting that achieves this:

Auto-generated Data Pre-Whidbey : Standard information such as timestamp or callstack would have to be explicitly generated Whidbey : An Admin can easily generate this data automatically, via config settings <listeners> <add name="examplelog" type= … Simple Thread Identification Pre-Whidbey : specific threads were difficult to identify, and filter on Whidbey : Correlation ID has been added, which allows quick and easy identification of a thread, and simple subsequent filtering

Listener Filtering Pre-Whidbey : Formatting of Trace information was predefined, and not controllable Whidbey : Assign filtering to listeners, so only certain messages are traced. This allows filtering on any property of a message. E.g., ID, TimeStamp, etc. Switches Pre-Whidbey : Couldn’t determine what tracing a component supported Whidbey : Support the ability to determine what tracing mechanisms a component has

JIT-Compilation What is it? Disadvantages?
Compiles methods, on-demand, from IL to native code Native code discarded after process terminates Disadvantages? Native code not shared across AppDomains or processes JIT compiler uses memory: ~300 KB for its code, plus more for its working data structures Touches otherwise ‘cold’ metadata, so increasing memory usage

Enhancing the Base Library Improved Networking
FTP protocol support Automatic proxy discovery Integrated with IE HTTP request caching Integrated with the IE cache Improved socket security SSL stream and authentication support over sockets Network tracing Easier to debug network errors

System.Uri Performance enhancements Support for relative URI’s HTTP Listener Receive HTTP requests inside your application Network information Enumerate cards on the machine, get notified when things change

Enhancing the Base Library Handling network change events
public static void AddressChanged(object source, AddressChangedEventArgs e){ Console.WriteLine("Address Changed"); receivedNetworkChange = true; } public static void Main() { NetworkInformation netInfo = new NetworkInformation(); netInfo.AddressChanged += new NetworkInformation.AddressChangedEventHandler(Class1.AddressChanged); netInfo.StartListeningForAddressChanges(); while(true){ if (receivedNetworkChange) netInfo.StopListeningForAddressChanges();

Enhancing the Base Library FTP Protocol Support
VB Sub DownloadFile() Dim filename As String filename = "ftp://ms.com/files/dotnetfx.exe" Dim client As New WebClient client.DownloadFile(filename, "dotnextfx.exe") End Sub

Automatic proxy discovery Integrated with IE HTTP Listener Receive HTTP requests inside your application HTTP request caching Integrated with the IE cache Improved socket security SSL stream and authentication support over sockets Network tracing Easier to debug network errors System.Uri Performance enhancements Support for relative URI’s

Enhancing the Base Library Check network availability
VB Dim netInfo as new NetworkInformation() If (netInfo.GetIsConnected() = True) 'use network resources Else 'use local cache End If

Standardization

Standardization Standard for CLI and C# Several CLI implementations
ECMA approved December 2001 ISO expected October 2002 Several CLI implementations .NET Framework .NET Compact Framework SSCLI (“Rotor”) – Shared source on XP, FreeBSD, OS X “Mono” – Open source on Linux Whidbey maintains a high level of compliance Active engagement continues Generics, parallel processing extensions, etc

Reliability – Managed Code
‘SafeHandle’ Can clean up unmanaged resources in exceptional conditions HostProtectionAttribute Allow hosts to decide what features to support Reliable Managed Code Guidance Upcoming whitepaper & samples If I do talk about reliability, talk about it here: single slide. Mention that we have reliability objectives as a result of requirements from Yukon The GC will run SafeHandle finalizers after any normal finalizers have been run for objects that were collected at the same time. This ensures classes like FileStream can run a normal finalizer to flush out existing buffered data. This is a key; it means adding this class to a class like FileStream does not alter our current semantics with regard to finalization today.

Threading

Threading Semaphore Resource counting for mutex’s
// construct a semaphore with a count of 3 Semaphore sem = new Semaphore(3); private void UseResource { // Wait until a count is available… sem.WaitOne(); //  the sem count is reduced by one // other code … // Release the count: sem.Release(); //  the count is incremented by one Semaphore is basically a resource-awareness solution, which customers asked for, so we’re giving it to them. The basic concept here is that you have a mutex, but the resource represented by the mutex has a multiple ‘count’. Consider for example, that you want to allow multiple objects refer to, and use serial-ports. Serial Ports are pretty scarce resources, you generally only have two or three on a machine. In this situation, you want to avoid collisions with regards to the instances attempted access of the scarce resource, or else, they may simply fail (or interfere with eachother!). Mutex won’t do, because it locks a single resource (note, a mutex is not dis-similar from a semaphore with a count of 1). Therefore, we use a Semaphore. We construct our Semaphore with a count, being the total number of resources represented. When each instance that needs to share the resources represented by the Semaphore needs that resource, it calls WaitOne on the Semaphore (Wait for a count to be available). If a count is available (the sempahores internal count) then it is given to the instance (and the resource is locked, all in atomic fashion), and the count inside the semaphore is reduced by one. If no count is available for a specific request, then the instance is blocked on the ‘WaitOne’ request, until a count is available. And finally, when each resource is done with it’s use of the resource, it must Release on the semaphore, to let the count go up by one. All pretty straightforward, and very useful for constrained resources!

Threading Named Events
V1.0 and V1.1: Events can only signal the same process Whidbey: Named Events allow cross process communication Public Class EventWaitHandle Inherits WaitHandle Public Sub New EventWaitHandle(initialState As Boolean, type As EventType, name As String )

Backup

Namespaces Fundamentals Command Line Tools Client Application Model
Web & Service Application Model Data Systems Application Model Mobile PC & Devices Application Model Compact Framework Avalon Windows Forms ASP.NET / Indigo Win FS Yukon System.Console Mobile PC Optimized System.Windows System.Windows.Forms System.Web System.Storage System.Data.SqlServer System.Windows.Forms System.Windows NT Service System.ServiceProcess Presentation Data Communication System.Windows System.Search System.Data System.Messaging System. Discovery System.Collaboration UI Element Explorer Media Annotations SqlClient DataSet System.DirectoryServices RealTimeEndpoint Documents Controls Animation SqlTypes Mapping Active Directory Monitoring System.Remoting TransientDataSession Text Element Dialogs Controls SqlXML ObjectSpaces SignalingSession Logging System.Runtime.Remoting Uddi Shapes SideBar Control OdbcClient ObjectSpace Media Shape Notification Panel Relevance OleDbClient Query Activities Ink Navigation Design OracleClient Schema System.Web.Services System.MessageBus System.Storage Web.Service Transport Queue System.Windows.Forms System.Web.UI Item Core Description Port PubSub Forms Page WebControls Relationship Contact Discovery Channel Router Control Control Adaptors Service Policy Media Location Protocols Print Dialog HtmlControls Design Peer Group Audio Message Design MobileControls Video Document System.Net Images Event System.Web System.Help System.Speech HttpWebRequest NetworkInformation System.Xml Personalization FtpWebListener Sockets System.Drawing Recognition Synthesis Caching Schema Xpath SslClientStream Cache System.NaturalLanguageServices Serialization Query SessionState WebClient Fundamentals Base & Application Services Security Configuration Deployment/Management System System.Text System.Collections System.Windows. TrustManagement System.Web.Configuration System.Web System.Globalization System.Design System.Security Generic System.MessageBus.Configuration Administration System.Serialization System.IO System.Web. Security Authorization Permissions System.ComponentModel System.Configuration Management System.Threading Ports AccessControl Policy System.CodeDom System.Resources System.Message Bus.Security Credentials Principal System.Management System.Runtime System.Reflection Cryptography Token System.Deployment Serialization InteropServices System.EnterpriseServices System.Diagnostics CompilerServices System.Transactions

.Net Framework Joel Pereira

Similar presentations

Presentation on theme: ".Net Framework Joel Pereira"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

.Net Framework Joel Pereira

Similar presentations

Presentation on theme: ".Net Framework Joel Pereira"— Presentation transcript:

Similar presentations

About project

Feedback