Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

Un éclairage sur les techniques d'accès aux données sous .NET

21. septembre 2008 Olivier Données, Framework .NET, LINQ, SQL Server (0)
Depuis la sortie de .NET Microsoft n'arrête plus sa course folle ! La plupart des technologies publiées faisaient partie d'un plan presque totalement connu à l'avance, comme WPF, WCF etc. Il a fallu du temps pour qu'émerge ses "modules" de .NET car même le plus puissant des éditeurs de logiciels du monde ne peut pas releaser la totalité d'une montagne comme .NET en un seul morceau. S'il était clair que WPF serait la nouvelle gestion des interfaces utilisateurs et que Windows Forms n'était qu'un "os à ronger" en attendant, le foisonnement des technologies tournant autour des données n'était pas forcément visible ni prévisible il y a quelques années. Et même aujourd'hui savoir ce qui existe et comment s'en servir avec l'ensemble des autres technologies n'est pas forcément une mince affaire ! Un petit dessin valant tous les discours, voici un diagramme qui tourne sur les blogs américains de Microsoft et que j'ai en partie traduit pour vous, en espérant que cela vous aidera à y voir plus clair ! Quelques précisions pour certains acronymes ou noms de technologies : EDM : Entity Data Model - Modèles de données de l'Entity Framework (EF) RDBMS : SGBD, une base de données ASP.NET Dynamic Data : nouveau système de .NET 3.5 SP1 simplifiant et améliorant la prise en charge des données dynamiques dans ASP.NET ASP.NET MVC : Nouvelle couche permettant d'appliquer le paradigme Modèle-Vue-Controleur aux développement ASP.NET ADO.NET Data Services : couche de communication transformant un modèle EDM en un service Web [Faite un clic-droit sur l'image et copiez-la pour l'afficher en 100% dans Word ou autre ]

Powershell ou la ligne de commande objet sous .NET de Windows

18. septembre 2008 Olivier Framework .NET (0)
Le shell de Windows nous renvoie aux temps préhistoriques où le PC avait un écran vert non graphique. Même les premières versions de Windows se lançaient aussi en ligne de commande. On ne parlait d'ailleurs pas de logiciels en "mode console" puisque c'était le mode normal... Le fameux DOS. Avec les versions modernes de Windows est venu un autre temps, celui où Windows est devenu le DOS et où la ligne de commande n'est plus qu'une console qu'on appelle parfois et qui, une fois fermée, retourne à Windows, qu'on n'a pas quitté d'ailleurs... Inversion de tendance, mais le côté "rugueux", voire ésotérique de la console est resté. Bien que le shell soit avec le temps devenu capable de faire des choses plus intelligentes il n'a finalement que peu évolué depuis MS-DOS. Mais voici PowerShell ! PowerShell n'est pas un utilitaire freeware mais bien une extension Windows produite par Microsoft. Il s'agit de proposer une console (un shell) totalement objet fonctionnant sous .NET. Les commandes ne retournent plus des réponses textuelles mais des listes d'objets. Certes, quand on tape un "dir" on obtient, grosso-modo, le même type d'affichage qu'avant. Mais cela est fort trompeur ! En réalité le "dir" (comme les autres commandes) retourne une liste d'objets dont on peut obtenir les méthodes, les propriétés. On peut aussi exécuter les méthodes de ces objets, remettre en forme la liste et bien d'autres choses encore ! Un exemple simple en quelques étapes : obtenir la liste des services tournant sur la machine: get-service obtenir cette liste et obtenir la classe des objets retournés ainsi que les membres de cette classe : get-service | get-member obtenir le service de planification des tâches et savoir s'il peut être arrêté : (get-service schedule).CanStop obtenir le service de planification des tâches et l'arrêter : (get-service schedule).stop() etc... Comme on le voit ici le "pipe" fonctionne toujours mais il sait passer les objets d'une commande à l'autre. On voit aussi qu'on peut obtenir un objet en particulier et invoquer ses méthodes ou accéder en lecture et en écriture à ses propriétés. Le PowerShell c'est encore bien d'autres choses, des boucles ForEach par exemple, des Cmdlet (prononcer Command-let) des petites commandes toutes prêtes ou des alias permettant d'écrire moins de code. C'est aussi des scripts bien entendu ou l'accès à tous les drives de la machines même ceux plus abstraits comme Env (l'environnement) ou HKCU (la registry, clé du current user) dans laquelle on peut naviguer comme dans tout drive. Etc. Le mieux c'est de voir par vous-même n'est-ce pas ? ... En téléchargeant cet outil sur la page du PowerShell Microsoft. Bon shell .. et Stay Tuned !

Les différentes versions du framework .NET

2. septembre 2008 Olivier Framework .NET (0)
Depuis sa naissance le framework a bien évolué ! La compatibilité ascendante a toujours été respectée et preuve en est aujourd'hui que le "side-by-side execution" de .NET fonctionne bien puisque toutes les versions peuvent coexister sur la même machine et que de nombreux logiciels les utilisant peuvent tourner ensemble sans aucun mélange, loin du "Dll Hell" de Win32. Le pari est donc tenu et en général on ne se soucie de la version du framework que pour savoir si on désire supporter telle ou telle nouvelle fonctionnalité mais jamais pour éviter des "incompatibilités" (quel vilain mot ! :-) ). Toutefois il est parfois important de respecter une implémentation particulière et donc de savoir où trouver le setup correspondant. Au-delà de ces contingences techniques il est intéressant de connaître les diverses versions qui (co)existent et qu'on peut trouver chez les utilisateurs. Un petit récapitulatif n'est donc pas forcément de trop... Les différentes versions Les différentes versions du Framework .NET à ce jour VersionTypen° versionDate  .NET Framework 1.0 1.0  RTM 1.0.3705.0  02/01/2002 1.0 SP1  Service Pack 1.0.3705.209 19/03/2002  1.0 SP2  Service Pack  1.0.3705.288  07/08/2002  1.0 SP3  Service Pack  1.0.3705.6018  31/08/2004 .NET Framework 1.1 1.1 RTM 1.1.4322.573 01/04/2003 1.1 SP1 Service Pack 1.1.4322.2032 30/08/2004  1.1 incluse avec Win2003 SP1  Win2k3  1.1.4322.2300  30/05/2005  .NET Framework 2.0 2.0  RTM  2.0.50727.42 07/11/2005  2.0 Vista  RTM  2.0.50727.312  30/01/2007  2.0 SP1  Service Pack  2.0.50727.1433   19/11/2007  MS07-040  Security Patch 2.0.50727.832     2.0 SP2  La SP2 n'est pas distribuée seule Elle est incluse dans .NET 3.5 SP1 Service Pack 2.0.50727.2407    .NET Framework 3.0  3.0  RTM 3.0.4506.30 06/11/2006  3.0 Vista  RTM 3.0.4506.26  30/01/2007 3.0 SP1  Service Pack  3.1.21022  19/11/2007 .NET Framework 3.5  3.5  RTM 3.5.21022.08 09/11/2007  3.5 SP1 Service Pack 3.5.30729.1 11/08/2008 Le tableau ci-dessus n'intègre pas toutes les versions beta qui, par essence, ne sont pas installées en production. En revanche, en cliquant sur les liens vous accéderez directement à la page de téléchargement de la version concernée. Savoir quelles versions sont installées Cela est tout bête, mais disposer d'un joli tableau des versions est une chose, mais comment savoir quelles versions sont installées sur une machine ? C'est une bonne question et j'attendais que vous me la posiez ! :-) La version simple : ouvrez une commande (menu démarrer, exécuter puis tapez "cmd"), puis tapez la ligne suivante : cd %systemroot%\Microsoft.NET\Framework Tapez ensuite la commande "dir" et regardez la liste des répertoires... Chaque version est installée dans le sien propre dont le nom est tout simplement le numéro de la version précédé de la lettre "v", "v2.0.50727" par exemple. La version plus complète : utilisez l'explorateur de fichiers, tapez dans la barre d'adresse  %systemroot%\Microsoft.NET\Framework, entrez dans l'un des répertoires en question et localisez le fichier Mscorlib.dll. Clic droit puis Propriétés, et dans l'onglet Version vous obtiendrez le numéro de version complet de l'installation du framework considérée. Il faut préciser que vous obtiendrez peut-être des numéros de version qui ne sont pas dans le tableau de ce billet, comme je l'ai précisé je n'ai pas pris en compte les beta ni les hotfixes éventuels. Par exemple, sur ma machine pour le répetoire "v2.0.50727", le fichier Mscorlib.dll me donne 2.0.50727.3053 qui est vraisemblablement la version du SP2 de .NET 2.0 installée par .NET 3.5 SP1. Pour conclure Bientôt 7 ans, l'âge de raison si on en croit la sagesse populaire... l'âge où l'on perd ses dents. Je ne sais pas si la métaphore peut s'appliquer jusqu'à ce point, j'ai un doute... Il faut au contraire admettre que le framework commence a avoir une machoire bien gardie ! Et quand on sait tout ce qui est à venir, comme les extensions parallèles (PFX) et bien d'autres choses, on se dit qu'on a bien eu raison de s'y prendre dès le départ, car l'ère .NET ne fait que commencer... Bon Dev et .. Stay Tuned !