Framework 2.0 SP X sur VISTA

Aujourd'hui je voulais installer le Service Pack 2 du Framework .NET 2.0 sur un PC équipé de VISTA et là c'est le drame ! Impossible... Un vilain message d'erreur alerte sur le fait que le SP2 du Framework 2.0 ne peut pas fonctionner sur VISTA !!! ARgh

Bon du coup j'essaie l'installation de la SP 1 du Framework .NET 2.0 et là encore impossible...

Mais qu'est-ce que c'est cette histoire ??

Finalement j'ai pu découvrir que pour installer la SP2 du Famework .NET 2.0 sur VISTA, il fallait installer le dernier Service Pack du dernier framework disponible ! Etrange comme logique mais bon :-)

Pour preuve :

Microsoft .NET Framework 3.5 Service Pack 1

Description rapide
Microsoft .NET Framework 3.5 Service Pack 1 est une mise à jour cumulative qui contient de nombreuses nouvelles fonctionnalités qui sont construites par incréments à partir de .NET Framework 2.0 et 3.0, et inclut les mises à jour cumulatives de .NET Framework 2.0 Service Pack 2 et de .NET Framework 3.0 Service Pack 2.

Ajouter le filtrage à l'Explorateur de Fichiers de Windows

 

Je sais pas pour vous, mais pour moi, le fait de ne jamais pouvoir filtrer l'affichage des fichiers dans l'Explorateur de Fichiers Windows est un VRAI problème !

Si vous consultez un répertoire avec 500 fichiers merci !!!... Etre obligé de lancer une RECHERCHE pour ça c'est quand même LAMENTABLE...

Et bien j'ai trouvé LA SOLUTION rapide et EFFICACE ... : QT TOOLBAR

A installer très facilement... (Pas de problème pour les Geek à la recherche d'Open Source et autres pirates ... C'EST GRATUIT)

http://qttabbar.wikidot.com/

Après installation, vous devrez fermer puis réouvrir la Session Windows. (ou redémarrer... au choix)

 

Lancez votre Explorateur de Fichiers Windows.

Cliquez sur AFFICHAGE

puis sur BARRE D'OUTILS

puis cochez les 2 options QT XXXXXX

 

 

Désormais votre explorateur de fichiers affiche un nouveau bouton :

 

EDITION du 07/04/2010

Si vous installez cet add-in sous Windows XP, vous devrez impérativement utiliser les boutons SUIVANT et PRECEDENT qui sont proposés par QT Tab Bar...
En effet, le bouton "classique" PRECEDENT de l'explorateur ne fonctionnera plus et vous raménera sur la Home Page à chaque fois... Donc... Pensez à customizer vos BARRES D'OUTILS en utilisant AFFICHAGE / BARRES D'OUTILS et en veillant à décocher VERROUILLER LES BARRES D'OUTILS

Certifier les projets

L'objectif est de signer officiellement votre code... En clair que Windows vous reconnaisse comme étant un EDITEUR sérieux.
Et ainsi éviter le fameux message : Windows n'a pu identifier l'éditeur de ce programme, voulez-vous quand même l'installer ?

L'utilitaire nécessaire pour signer un fichier est SignTool.exe (anciennement SignCode.exe).
Il se trouve normalement dans \Program Files\Microsoft SDKs\Windows\vXXXX\bin
et aussi dans votre installation de Visual Studio... En fait il est un peu partout...
Faites une recherche de signtool.exe sur votre ordinateur et utilisez le plus récent :-)

Donc le but est de signer notre application avec un certificat.

Quel Certificat ??! Je le trouve où ?
Exclusivement pour des tests on peut utiliser MakeCert.exe pour générer un certificat et une clé publique.
Syntaxe en ligne de commandes :
http://msdn.microsoft.com/fr-fr/library/bfsktky3(VS.80).aspx

exemple :
makecert -r -sv MonCertificat.pvk -n "CN=MonCertificat" -b 01/01/2010 -e 31/12/2010 MonCertificat.cer

-r : pour créer un certificat auto-signé.
-sv : pour spécifier le fichier de clé privée à créer.
-n : pour spécifier le nom du certificat en respectant la norme X500 (les personnes qui connaissent LDAP/ACTIVE DIRECTORY n'auront pas de soucis :) )
-b : date de début de validité
-e : date de fin de validité
et enfin, précédé d'aucun code option, le nom du fichier de Certificat.

Un vrai Certificat comme les pros
Pour faire les choses sérieusement, il faudra demander votre certificat officiel auprès de Thawte ou Verisign ou autre organisme qualifié.
Lorsque vous achetez un certificat vous recevez un fichier PKV + un fichier CER.

J'ai mon Certificat (le vrai ou celui de test), je fais quoi maintenant ?
Il faut convertir le fichier CER en fichier SPC. En fait, convertir le Certificat (.CER) en Software Publisher Certificate (.SPC)
Et pour cela on utilise l'utilitaire : cert2spc.exe

comme ceci :
cert2spc.exe MonCertificat.cer MonCertificat.spc

Le problème c'est que SignTool.exe attend un certificat au format PFX. (c'est pas simple hein...)
Pour cela on utilise l'utilitaire pvk2pfx.exe qui va générer un fichier PFX à partir du CERTIFICAT (fichier .SPC) et de la CLE PRIVEE (fichier .PKV)

comme ceci :
pvk2pfx.exe -pvk MonCertificat.pvk -pi <MotDePasse> -spc MonCertificat.spc -pfx MonCertificat.pfx  -po <MotDePasse>
A partir de la clé publique (.pvk) et du certificat de l'éditeur (.spc), un fichier MonCertificat PFX est généré :)
Le mot de passe, c'est vous qui l'inventez... :)

La signature pour de bon  
Pour signer notre assembly, exe, ou n'importe quoi, il suffit d'utiliser signtool.exe :
signtool.exe sign /f MonCertificat.pfx /p <MotDePasse> /t <URL Horodateur> /v MonAssembly.dll

exemple URL d'horodateurs :
- http://timestamp.verisign.com/scripts/timstamp.dll
...

 

Vous pouvez également utiliser signtool.exe avec l'assistant graphique Windows (plutôt qu'en ligne de commandes).
Pour se faire exécutez le avec le paramètre signwizard (signtool.exe signwizard)

 En résumé :
Pour certifier une projet (Assembly, Exe...)
1) Un certificat est constitué de 2 fichiers. Un fichier de certificat (.CER ou .SPC) + une clé privée (.PVK)
2) Avoir un certificat. On peut générer un certificat de test avec MakeCert.exe, mais il faudra en acheter un chez une autorité qualifié comme Verisign.
3) Convertir le certificat .CER en certificat éditeur : .SPC avec CERT2SPC.EXE
4) Générer un fichier PFX à partir du certificat éditeur et de la clé privée avec l'utilitaire PVK2PFX.EXE
5) Signer le fichier cible avec SIGNTOOL.EXE en lui spécifiant le fichier PFX et une URL d'un horodateur.

Nom Simple, Nom Fort.

Par défaut un assembly (ou assemblage en bon français (merci les Quebequois) - mais jamais utilisé en fait) n'a pas de nom fort... On dit que par défaut "un assembly a un nom simple".

Ah super... Mais c'est quoi un nom fort ?
Le Nom Fort ou Strong Name est constitué de l'identité de l'assembly et d'une clé publique (clé publique = signature).
L'identité de l'assembly étant composée elle même du nom simple, du numéro de version, éventuellement des informations de culture, de ce dernier.

Bon ok... Mais ça sert à quoi de signer un assembly avec un nom fort ?
- Signer un assembly avec un nom fort va permettre de garantir la provenance de ce dernier. En effet, puisque le nom fort est constitué d'une clé publique, si votre clé n'est pas diffusée n'importe où, impossible pour quiconque de reproduire le même nom fort :-)
- Un assembly qui n'a pas de nom fort (strong name) et qui est donc un assembly à nom simple, pourra facilement être confondue avec un autre assembly de même nom.
- Un assembly avec nom fort (strong name) ne pourra pas fonctionner s'il a été altéré.
- Egalement, vous allez pouvoir disposer de plusieurs versions d'un même assembly à nom fort et exécuter telle ou telle version dans votre projet. Cela règle le problème de l'"enfer des DLL" assez classique sous Windows.
- Seuls les assembly à nom fort peuvent être soumis au Global Assembly Cache (G.A.C.)

Super... Du coup je veux mettre ça en oeuvre.
Comme nous l'avons dit, vous devez disposer d'une clé publique mais aussi d'une clé privée. On parle en fait d'une paire de clés publique/privée. 
La clé privée sera contenue dans un fichier qui sera donc intégré à la solution. (mais qui ne devra surtout pas être distribué !)
La clé privée sera décryptée à l'aide d'une deuxième clé qui sera elle publique. Au moment de l'exécution de l'assembly, .NET utilisera la clé publique pour décrypter la clé privée et vérifier l'intégrité et les informations de l'assembly. Evidemment la clé publique, elle, est diffusée ! (c'est pour ça qu'elle est publique).

C'est l'utilitaire SN.EXE qui va nous permettre de continuer. Vous devrez l'exécuter en ligne de commande DOS.

Pour créer la paire de clés, exécuter : SN -k [nom du fichier]
C'est à vous de préciser l'extension. Le fichier n'en aura pas si vous n'en spécifiez pas. D'usage, il faut mettre l'extension .SNK qui est reconnue comme l'extension Strong Name Key.
Par exemple : SN -k ClesProjet.snk qui sera donc intégré dans notre solution.

Dans le projet que vous voulez signer, vous devrez éditer AssemblyInfo.cs (ou .vb) et y ajouter :
<Assembly: AssemblyKeyFileAttribute("ClesProjet.snk")>
Si vous utilisez une version RECENTE de Visual Studio, vous pouvez spécifier le fichier de clés en utilisant l'onglet SIGNATURE (ou SIGNING) disponible quand vous aurez affiché la fenêtre PROPRIETES du PROJET.

En résumé :
- un assembly avec un nom fort est un assembly signé par : son nom + sa version + les informations de culture + une clé publique
- les avantages d'avoir des assemblys avec noms forts sont la sécurité, la garantie de la provenance, la possibilité de gérer plusieurs versions d'une même DLL.
- on utilise l'outil SN.EXE pour généré une paire de clés privée/publique qui seront contenues dans un fichier .SNK
- on intègre une référence au fichier contenant la paire de clés en éditant AssemblyInfo.cs (ou .vb) ou en utilisant l'onglet SIGNATURE disponible dans les PROPRIETES du projet.
- les fichiers .SNK peuvent être intégrés à la solution mais ne doivent surtout pas être diffusés.

ATTENTION : un assembly avec nom fort qui référence un assembly avec un nom simple ne respecte plus la chaîne et les garanties ne sont plus là !

MVC & ASP.NET

Hi,

j'en parlais ce midi avec Ludovic et du coup j'ai voulu un peu voir ce que l'on voulait nous faire avec le MVC appliqué à ASP.NET...

De manière un peu rapide j'ai affirmé que MVC était finalement ce qui avait tué J2EE et empêché JSF de complètement s'épanouir dans le monde JAVA/JEE... Evidemment c'est mon point de vue un peu extrèmiste... Mais c'est vrai qu'on peut se demander pourquoi on viendrait nous imposer un modèle qui a fait le malheur de J2EE au profit des méthodes peut-être plus simplistes d'ASP.NET qui pourtant permettent d'avoir un résultat aussi bon en moins de temps !

Du coup, avant tout et comme d'habitude avant de sortir le CHAR LECLERC, il faut se demander ce que peut nous apporter MVC... Model View Controller...
Donc on rappelle avant tout que le Modèle Vue Contrôleur a pour objectif de séparer l'Interface Homme Machine (IHM) en :
- un modèle de données.
- une vue pour la présentation.
- un contrôleur qui va gérer la logique, les événements.

Il suffit de lire WIKIPEDIA pour en savoir plus. 
Evidemment, comme initialement j'étais en mode critique, on notera que dans l'article trouvé sur WIKIPEDIA, dans la section Avantages et INCONVENIENTS, on nous explique brièvement que justement MVC montre ses limites dans le cadre des applications utilisant les technologies WEB...

Enfin, c'est pas grave... Faut toujours se faire du mal quand on programme ; ça permet de s'auto-alimenter en projets à dépanner :-)

Pour mettre en oeuvre très simplement MVC avec ASP.NET, rien de très compliqué en fait puisque même si ce n'est pas parfait, le principe du code sous-jacent (Code-Behind) d'ASP.NET permet déjà une bonne dissociation du code avec l'interface.
Du coup pour avoir du pur MVC pas grand chose à faire :

1) La vue : c'est notre page ASPX qui va la contenir. On va donc y trouver du HTML et nos contrôles ASP sans code !
2) Le modèle ; c'est finalement lui qui vient se greffer dans notre projet et pour lui on va devoir créer un nouveau fichier de type classe (.cs pour C# ou .vb pour VB.NET) qui va mettre à dispositions les données en provenance de la source de données (en provenance de la base de données SQL Server par exemple). On pourra donc y trouver des DataSet and co...
3) Le contrôleur : encore une classe (.cs ou .vb) qui va hériter de System.Web.UI.Page et où on retrouvera encore Page_Loag and co... C'est elle qui va associer aux contrôles de la VUE (1) les données mise à disposition par le MODELE (2).

 Maintenant soyons clair, comme d'habitude certains vont se faire embarquer par le phénomène de MODE et ne vont pas prendre en compte la réponse à la question simple qu'il faut se poser :
EST-CE QUE J'AI BESOIN D'APPLIQUER MVC A MON PROJET ?

La réponse étant PROBABLEMENT OUI si :
- besoin de beaucoup de javascript
- beaucoup de tests unitaires à réaliser
- vraiment bien dissocier le HTML

La réponse étant NON car ASP.NET simple plus approprié si :
- beaucoup de formulaires
- j'aime bien le VIEWSTATE (tu m'étonnes, c'est la base d'ASPNET !!)

Mon avis ? S'il intéresse quelqu'un : comme cela m'arrive assez fréquemment avec ce qui vient de J2EE, je suis totalement alergique ! Pourquoi ? Parce que les projets J2EE sont malheureusement un ambroglio d'une armada de classes justement pour répondre aux exigences de MVC et que le résultat est un plat de Spaghettis qu'ASP.NET avait réussi à nous débarasser.

Sans doute qu'il y a du bon à reprendre l'idéologie MVC... Mais pour ma part, si j'ai quitté J2EE ce n'est sûrement pas pour retrouver les chantiers labyrinthes de l'époque !

Le fait de mettre des classes de délivraisons de données, appelées depuis la page code-behind de ma page ASPX et qui alimentera justement les contrôles sur ma page ASPX sera largement suffisant pour avoir répondu à l'éventuelle nécessité de dissocier correctement VUE, MODELE et CONTROLEUR...

Enfin, j'ai pu lire ici et là que le modèle MVC permettait d'avoir un meilleur contrôle de ce qui se passe par rapport à l'approche ASP.NET VIEWSTATE... Excusez-moi, mais si justement les gens qui se disent capables de développer en ASP.NET pouvaient déjà savoir comment fonctionne le VIEWSTATE on aurait pas à trainer des casseroles... Et tout le monde serait content...

UN VRAI COUP DE GUEULE désolé !

Serveurs IIS Gratuits jusqu'en Juin 2010 !

Merci à Ludo pour le tuyau :-) - MAIS A QUAND TON BLOG bon sang ?! :-)

5 000 serveurs tout équipés gratuits jusqu’au 30 juin 2010 pour découvrir et développer des applications sur le web avec des pas à pas disponibles pour vous aider !

http://msdn.microsoft.com/fr-fr/maplateformeweb.aspx

 

 

 

A propos de l'auteur

 

Développeur depuis plus de 10 ans, j'ai commencé la programmation dès l'âge de 9 ans sur un PC 8088 !!

GW-Basic, Pascal, Turbo Pascal, Delphi ont fait mes bases... Puis Java , bien plus tard... Pour enfin avoir découvert le C#... Quel plaisir de développer avec ce langage des solutions ASP.NET... Le développement Web comme jamais je ne pouvais l'imaginer possible :)

Aujourd'hui titulaire du MCSD VS 6.0, MCAD .NET, et MCT ...

Sur ce blog, je souhaite partager des choses simples mais efficaces... Des problèmes de tous les jours que l'on peut rencontrer et qu'il est simple de régler :)

Mes certifications

Month List