8. .NET c’est quoi ? Composants Sécurité Flux XML Simplicité et puissant Protocoles Standard Services Web Clients Riches Pages Web Mobilité XML Modèle Relationnel Toutes les bases
9.
10. Le cœur du Framework CLI CLR Framework Class Library Données et XML XML Web services Windows Forms Web Forms Common Language Specification VB C++ C# … J# Visual Studio .NET Soumis à l’ ECMA Soumis à l’ECMA Spécification ouvertes Accès aux données basé XML Basé XML, SOAP, GXA
11.
12. CLR : Vue d’ensemble Class Loader Base Class Library Support IL to Native Compilers Code Manager Garbage Collector Security Engine Debug Engine Type Checker Exception Manager Thread Support COM Marshaler
19. Unification du développement Héritage, Contrôle, performance Windows API MFC/ATL ASP Stateless, mélange de code/HTML VB Forms RAD, Composition, Délégation .NET Framework RAD, Héritage, contrôle et performance, WebDynamic et WebServices
32. Assembly,module… Metadata for Types X, Y and Z app1.dll Code for Type X Code for Type Y Code for Type Z Namespace A Metadata for Types P and Q app2.exe Code for Type P Code for Type Q Metadata for Type R app3.dll Code for Type R Manifest Manifest Namespace B
58. La compilation à la volé Fichier ASPX Browser Web Réponse Réponse Classe de la page Instanciation, traitement, affichage Classe générée Génère Instancie Analyse moteur ASPX Requête Requête Classe Code Behind
59.
60.
61.
62.
63. Pour développer des ASP.NET Deux scénarios possibles Visual Studio .NET ASP.NET WebMatrix IDE SQL Server MSDE Données IIS “ Cassini” Serveur Web Développement en entreprise Environnement “light” Windows & .NET Framework Windows & .NET Framework Plate-Forme
64.
65. Un accélérateur de projets Visual Studio .NET ASP.NET WebMatrix IDE SQL Server MSDE Données IIS “ Cassini” Serveur Web ASP.NET Starter Kits Développement en entreprise Environnement “light” Windows & .NET Framework Windows & .NET Framework Plate-Forme
66.
67.
68.
69.
70. Concepts Annuaire UDDI Client Service Web Enregistrement du service Recherche d’un service Interface WSDL Récupération de l’interface du service Utilisation du service SOAP SOAP HTTP SOAP 1 2 3 4 proxy Développement Production
.NET = 16 bits -> 32 bits (Mais sans obligation de réecriture)
Elimine la plomberie Plus d’entrée dans le registre, GUIDs, fichiers IDL, HRESULTs, IUnknown, AddRef/Release, CoCreateInstance, etc. Orientation Objet Classes et héritage complétement supportés Même entre les languages! Compatibilité avec l’existant Les classes .NET peuvent être utilisées comme des classes COM Les classes COM peuvent être utilisées par des classes .NET Gestion automatique du cycle de vie Tous les objets .NET sont garbage collectés Pas de pointeurs ou de références circulaires Multi-generational mark-and-compact GC Self-configuring, dynamically tuning Traitement des erreurs Unification du mode de traitement des erreurs (plus de bool ou HRESULTs) Several compilation models Native (e.g. Managed C++) MSIL (e.g. VB and C#) No interpreter: Install-time or run-time IL to native compilation Code correctness and type-safety IL can be verified to guarantee type-safety No unsafe casts, no uninitialized variables, no out-of-bounds array indexing Evidence-based security Based on origin of code as well as user Extensible permissions Assemblies Unité de déploiement, versioning, et de sécurité Semblables aux DLLs, mais auto descriptives via les manifestes Installation Zero-impact Les Applications et composants peuvent être privés ou partagés Side-by-side execution De multiple versions du même composant peuvent coexister même dans le même process The CLR increases the reliability of applications in the following ways: It reduces conflicts between different versions of components. When the CLR loads an application, it uses the assembly manifest and the metadata to ensure that it loads the correct version of all components. With public or shared assemblies, which have been registered in the Global Assembly Cache (GAC), there should not be any problems with multiple versions of a component coexisting on a machine. This means that if the managed code needs to access a database, then the CLR uses the information in the manifest to find and load the correct version of the data access component. It reduces the number of bugs and security holes due to common programming mistakes. The CLR also uses its knowledge about the managed code to ensure that the managed code doesn't include common programming errors that would cause it to perform incorrect functions, such as trying to use an integer for a function pointer, trying to force numeric data into a location allocated for text, or overwriting code while loading data (causing a buffer overflow). Reducing bugs that result from these common programming errors means that managed code not only runs more reliably but also leaves fewer holes or vulnerabilities for attackers to exploit. Increased security makes it harder to execute hostile code. Because the CLR can understand the identity and origin of the code in each application, it can determine whether the application is allowed to perform certain tasks (such as reading or writing to local storage or sending e-mail). This adds another level to the current security model, where the application runs in the security context of the user account that is running it (for example, all applications on an administrator's machine run with administrator-level permissions). Less memory is lost to "leaks." Memory and components that are allocated and never released ("memory leaks") cause systems to run out of memory, either crashing the system or requiring a reboot to free the memory. The CLR's memory management and garbage collection greatly reduce the likelihood of this problem occurring. "Plumbing" functions reduce bugs and save developer time . Finally, the CLR provides many of the low-level or "plumbing" functions related to memory and object management, data marshalling, and threads. This not only creates better reliability by reducing the potential for bugs but it also enables application programmers to concentrate on the "line of business" code for their specific application rather than (re-)implementing standard Windows plumbing.
NotePad / VS / Dreamwever
On retrouve les 4 grands verteurs de .NET 1. Le cœur = System 2. Acced aux données = ADO.NET 3. Présentation = ASP.NET Windows.Forms 4. Communication = XML
Assembly = Représentation physique. .NETModule = .obj (mais obj de l’IL bien sure)
Quesqu’on appel l’unification dans .NET ???
Depuis les API de l’eau est passé sous les ponts…. (win3.1…) Divergence entre C++/MFC et VB et ASP Runtime VB avec la problématique de version .NET ré unifie en conservant le « meilleurs » des différents mondes
.NET multilangage (30 supportés) - VB à été dénaturé pour être supporté par .NET - C++ c'est le seul qui couvre le développement natif Windows (Win32) et .NET - C# c'est le seul qui donne accés a tout la richesse de .NET C’est la CLS qui va permettre de généré un même IL
.NET multilangage (30 supportés) - VB à été dénaturé pour être supporté par .NET - C++ c'est le seul qui couvre le développement natif Windows (Win32) et .NET - C# c'est le seul qui donne accés a tout la richesse de .NET
Valeur : Type Simple / Structure Référence : Objet et Interface Mais on ne fait jamais ce code il est fait automatiquement par le compilateur quand il a besoin de convertir un variable Valeur en Référence.
1/ Deux boxing car int et Date sont des types valeur. Donc on passe par System.Int32 et System.Date pour allez chercher .ToString(); 2/ Pour 0 et 1 Boxing car entier, pour « zero » et « un » string donc référence donc pas de boxing 3/ Piège !!! Il n’y a pas de boxing car d n’est pas utilisé dans une situation qui nécésite le boxing le compilateur retrouve this sur la pile directement.
4/ array de valeur donc pas de boxing 5/ ArrayList Add prend un objet donc boxing 6/ Les interfaces sont traité en Référence et structure est en valeur donc boxing
Cette unification des concepts Objet rend Windows Orienté Objet comme on ne travaille qu’avec le FrameWork Par un simple abonnement à un événement Windows du Framework on va pourvoir s’abonné à une modification d’un répertoire par exemple. On ne touche pas à l’API Win32 !
Il existe aussi WebMatrix ! Mais uniquement développement Web
Comme je vous le disais, la plus petite entité de déploiement dans .Net est l’assembly Mais que va t’on trouver dans ce machin la !!
PE : Portable Executable On peut voir les clrheader avec DumpBin /clrheader baBAExe.exe
CODE BINAIRE, pas d’interprétation Mécanisme identique et avec cache pour les aspx IE voir test dans une application Windows Ngen permet de mettre un version compilé dans Global Assembly Cache pour évité cette first compilation Ngen baBAExe.exe Ngen baBADll.dll
Assembly Loader = mscoree.dll
Side by Side : Rien dans la base de registre et rien dans Windows/System32 GAC : Pré JIT avec ngen (disponible pour tous les applications) Download : C’est pour les applications exe s’exécutant à travers IE
Point 3 revient a faire des objet COM en .NET
Logiquement un développeur s’y met en une journée. Avec l’ADO du monde unmanaged, nous avions ébauché le mode déconnecté. Aujourd’hui, le mode déconnecté est en natif sur la plate-forme
Que trouve t-on dans l’ADO.Net .Net Provider, SQL, OLEDB Oracle et ODBC disponible sur le Net en Beta DataReader qui permet un accés Foward Only DataAdapter qui permet un accès à la base et on se déconnecte DataSet :Mode déconnecté (Géniale on peut travaillé indifféremment XML / Base) ADO Architecture : 2 modes
Zoom sur les DataSets il servent a transporter les données
Mapping et correspondance entre ADO et XML A tout moment on peut passer de l’un a l’autre…(+ ou – automatique)