Archives de catégorie : .net

image

Ressources supplémentaires sur le développement d’applications métier (LOB) pour Windows 8 et WP8

Comme indiqué précedemment, j’ai eu l’opportunité de présenter une session sur le développement d’applications métier pour Windows 8 et Windows Phone 8 avec la précieuse aide d’Audrey Petit.

image

Nous avons évoqué une grande variété de sujets (Opportunités, Déploiement (via le Store ou déploiement privé), Ergonomie Modern UI, Stratégies, Transition vers ModernUI, etc.) et n’avons donc pas pu approfondir tous ces sujets en 1h.

En fonction des Q&A de fin de session, je vous propose donc une liste de ressources complémentaires qui vous permettra d’aller plus loin sur certains points.

Pour débuter cette liste de ressources, je vous propose en plus des différentes démonstrations que nous vous avons montré, un case study sur le développement d’applications métier pour Win8.

Du côté utilisateur, voici un post de blog indiquant comment Utiliser des applications d’entreprise avec Windows 8 [US]. La fonctionnalité est présentée dans le contexte “Bring your own device” mais correspond tout à fait à celle indiquée durant la session.

Du côté IT, pour le déploiement des applications via Intune et l’app portail d’entreprise vous pouvez consulter cette présentation très complète sur le déploiement d’applications d’entreprise pour Windows Phone [FR]

Si vous souhaitez une synthèse du processus de déploiement que nous avons décrit vous pouvez également consulter ce post ainsi que ce post rentrant plus dans le détail de Windows Intune.

Toujours sur Windows Intune, Channel9 propose une démo en vidéo du process de déploiement.

Nous avons également parlé des possibilités de déploiement via scripts, vous trouverez sur cette page la documentation sur ceux-ci mais également sur la suppression des applications comme demandé durant la session de Q&A.

A propos de la question sur la possibilité de créer des applications ASP.net avec le look ModernUI, vous trouverez ici un ensemble de ressources permettant d’y arriver avec présence des plugin jQuery que j’avais évoqué.

Et enfin pour confirmer ce que j’indiquais à propos de l’addin de storyboarding pour Powerpoint il vous faudra disposer de Visual Studio 2012 Test Professional, Premium ou encore Ultimate pour être capable d’en profiter :

image

image

RIP Client Profile –Tips #4

C’est avec surprise que je viens de constater que le framework .net 4.5 ne propose plus de profil “Client Profile” :

image

La confirmation officielle se trouve dans la MSDN avec une explication bateau qui tire plus du marketing que de la véritable explication technique : http://msdn.microsoft.com/en-us/library/cc656912(v=vs.110).aspx

Ce profil permettait de disposer d’un profil de framework très légèrement plus léger destiné au développements d’applicatifs clients (exit donc ASP.net, la couche serveur WCF, etc.).

Un des principaux avantages étant que cette version du framework .net était préinstallé sur les OS les plus récents, ou inclus dans des mises à jour via Windows Update.

Il ne reste plus qu’à espérer que le framework 4.5 soit installé d’office sur les prochains OS de Microsoft à commencer par Windows 8.

image

La détection de Copier Coller–Tips #3

Afin de lutter contre les copier coller intempestif et plus généralement d’aider à trouver des blocs de code identiques ou très proches, Visual Studio 11 propose une fonctionnalité de détection de clone de code.

Si l’on prend un exemple simple :

image

Un clic sur le menu Analyze, Analyze Solution for Code Clones permet de lancer une analyse sur le code source de l’intégralité de la solution et d’afficher un nouveau panneau :

image

Il est ensuite possible de naviguer dans les blocs de code détectés afin de refactorer et donc d’améliorer la qualité du code.

A noter que l’outil ne permet pas d’uniquement trouver les blocs de code strictement identique mais permet de faire des analyses légèrement plus poussées. Le nommage des variables n’est par exemple pas pris en compte, si la structure du code est voisine avec des noms de variables différents, la fonctionnalité sera capable de trouver des résultats pertinents.

Point qui peut être intéressant, l’analyse se fait bien sur le code source et non sur l’IL, il n’est donc pas nécessaire que le code compile pour lancer la détection (oui, je sais; c’est tordu mais c’est toujours bon à savoir Sourire).

Inconvénient, l’analyse se faisant sur la structure du code source, l’outil n’est pas capable de détecter du code identique  fonctionnellement mais pas syntaxiquement.

Par exemple le code suivant ne renvoie aucun résultat :

image

A noter que la fonctionnalité ne se concentre que sur des blocs d’une 10 de lignes de code uniquement, les blocs plus petits ne sont pas détectés.

De plus; il est possible de lancer une analyser afin de rechercher des clones d’un bloc de code en particulier. Il suffit pour cela de le sélectionner et de sélectionner le bon élément dans le menu contextuel pour y parvenir.

Et sur du vrai code ? J’ai lancé l’analyse sur l’application sur laquelle je travaille (plusieurs centaines de milliers de lignes de code) et j’attends le résultat depuis 2 heures !

Grosse déception, le moteur d’analyse ne semble à priori pas multithreadé. Sur mon quad-coeur, le process de VS 11 tourne en moyenne à 20%, la consommation mémoire reste à peu près stable, et les accès disque sont faibles. Le CPU semble donc être le goulot d”étranglement…

image

Après 2 heures d’analyse, cela progresse lentement… mais surement… Je mettrais à jour ce post si cela se termine un jour ! Sourire

image

Integrated Security = True ou SSPI ?

Est un exemple de question à laquelle je connais la (bonne) réponse, sans trop savoir
pourquoi. J’ai donc profité que l’on me pose de nouveau la question pour effectuer
quelques recherches.

Afin de mettre en place l’authentification Windows pour une connexion vers SQL Server
il existe donc deux possibilités : utiliser Integrated Security = true ou Integrated
Security = SSPI.

A la question, lequel est le mieux, j’ai répondu SSPI sans trop savoir la vraie raison.
Ce à quoi un collègue m’a répondu en me demandant pourquoi le Server Explorer de Visual
Studio générer une chaine de connexion avec “True” si “SSPI
était meilleur.

Donc la réponse définitive est simple : Il vaut mieux utiliser SSPI
la place de True et ceci pour deux raisons :

Donc pourquoi Visual Studio génère le contraire ?

Parce ce que par défaut il utilise le provider SQL Client de .net : image

Il doit donc probablement faire appel à ce provider pour générer la chaine de connexion
qui va donc générer le true. Si l’on sélectionne celui d’OLE DB, on retrouve bien
le SSPI. Et ce provider ne doit probablement pas respecter la recommandation, et probablement
à tort !

image

Légers changements autour du 64 bits et de Visual Studio 2010

image C’est
en lisant le premier chapitre de
la 3ème édition de CLR via C#
de
Jeffrey Richter que m’est revenu cette information qui a son importance lorsque l’on
souhaite le pourquoi du comment à propos du support du 64 bits.

Jeffrey Richter indique à juste titre que le compilateur C# compile par défaut les
assemblies en AnyCPU afin que celles-ci soient portables et compilées en 32 ou 64
bits par le compilateur JIT en fonction de la plate-forme sur laquelle on souhaite
exécuter l’application. Ceci est vrai, mais on pourrait penser que donc Visual Studio
compile également par défaut vos assemblies en AnyCPU.

Et cela était effectivement le cas avec les précédentes versions de Visual Studio,
mais il y a eu un changement de politique avec Visual Studio 2010 qui a eu lieu assez
récemment il me semble (probablement à partir de la RC).

Avec la dernière version de l’ide, les projets qui sont généralement des points
d’entrées applicatifs (les types de projets relatifs au GUI clients) sont par défaut
compilés en x86.
Ainsi si vous créez un projet Windows Forms, un projet WPF
ou une application Console vous pouvez constater que l’AnyCPU qui faisait loi jusqu’
présent à laisser place à une configuration en x86. Les projets ASP.net et les bibliothèques
de classes ne sont pas concernés et restent par défaut en AnyCPU.

Pourquoi ce changement alors que l’AnyCPU permet d’avoir des assemblys
multi-plateforme et donc portables ?

Tout simplement, parce que les développeurs ne font pas assez souvent de tests de
leurs applicatifs sur des environnements 32 bits ET 64 bits.
Si vous développez dans un environnement 32 bits, et que vous ne testez pas votre
application 64 bits vous risquez
d’avoir des problèmes si vous référencez des composants 32 bits
. En effet, votre
point d’entrée étant en AnyCPU votre application sera compilée en 64 bits et sera
donc incapables de charger des composants 32 bits.

Modifier le paramétrage par défaut afin de compiler en x86 les projets de types GUI
clients permet d’avoir des applications qui fonctionneront dans tous les cas puisque
elles seront (par défaut) exécutées en 32 bits même sur un OS 64 bits. Vous êtes toujours
libre de changer cette configuration vers un compilation en AnyCPU mais prenez bien
garde à vos dépendances.

Quand aux projets ASP.net, ceux-ci concernent des applications serveurs qui ont potentiellement
bien moins de chance d’avoir des dépendances vers des composants 32 bits, et les bibliothèque
de classes restent en AnyCPU afin de garder leur portabilité, le point d’entrée de
votre application étant l’élément clé indiquant si le process doit être en 32 ou 64
bits.

Quand la CLR V2, la CLR V4 et du code mixte se rencontrent

“Mixed mode assembly is built against version ‘v2.0.50727’ of the runtime and
cannot be loaded in the 4.0 runtime without additional configuration information”

Voici le petit message d’amour que peut vous renvoyez votre ami la CLR lorsque vous
essayez d’exécuter une application qui :

  • référence une assembly mixte (mêlant code natif et code managé) qui a été compilée
    pour être basée sur une version différente de la CLR utilisée par votre point d’entrée.

La solution à ce problème est assez simple, il suffit de rajouter une section dans
votre fichier de config :

<configuration>

<startup useLegacyV2RuntimeActivationPolicy="true">

<supportedRuntime version="v4.0"/>

</startup>

</configuration>

L’attribut useLegacyV2RuntimeActivationPolicy

La clé du problème se situe donc dans l’utilisation de l’attribut useLegacyV2RuntimeActivationPolicy
qui est à false par défaut. Cet attribut permet de changer la politique de chargement
de CLR au sein de votre application. Il y a eu en effet un gros changement à ce sujet
:

  • Dans l’ère pré-CLR V4, en V2 quoi, il n’était possible de charger
    qu’une seule version de CLR au sein d’un process. La politique par défaut était de
    charger toutes vos assemblies en utilisant la version la plus récente de la CLR que
    vous aviez à disposition. Cette stratégie a comme avantage que votre ancien code bénéficie
    automatiquement des améliorations apportées par des versions plus récentes de CLR.
    Mais cela pouvait posait des problèmes de compatibilité dans certains rares cas.
  • Avec la CLR V4, il est à présent de charger différentes versions
    de CLR au sein d’un même process et afin de ne plus être confronté aux problèmes de
    compatibilité la politique de chargement a changé. A présent les assemblies basées
    sur la CLR 4, utilisent la CLR 4, et les autres utilisent la version la plus récente
    inférieure à la V4.

Le problème avec les assemblies mixtes c’est que la CLR doit être capable de savoir
quelle est la CLR a utiliser lorsque un thread natif appel du code managé. Il faut
donc désactiver le side by side afin d’avoir une seule version identifiable.

Mais pourquoi ça marche très bien depuis mes tests unitaires ?

Confronté au problème une de mes premières questions a été de comprendre pourquoi
mon code fonctionne très bien depuis mes tests unitaires alors qu’il plante lorsque
je l’appelle depuis mon application. Le moteur d’exécution des tests unitaires MSTest
est QTAgent.exe (QTAgent32.exe en version 32 bits, et oui VS 2010 supporte enfin l’exécution
de tests unitaires en 32 et 64 bits). Si l’on va farfouiller
un petit peu dans le dossier C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDE
à la recherche des fichiers de configs des tests runners on se rend compte que Microsoft
a configuré le chargement de runtime via le fameux attribut useLegacyV2RuntimeActivationPolicy.

Ce qui veut donc dire que par défaut tous vos tests unitaires utiliseront uniquement
la V4 de la CLR et que le hosting de CLR Side by Side est désactivé pour tous vos
tests unitaires.

 

Crypter les chaines de connexions est inutile

En
me rendant sur la page d’accueil de la plate-forme WordPress, je suis tombé sur le
dernier post de blog de l’équipe de développement de ce logiciel. Ce post intitulé
Secure File
Permissions Matter
” indique de manière censée qu’il est toujours nécessaire de
configurer les permissions d’accès à vos fichiers afin d’éviter tout problème de sécurit”,
notamment liés à votre hébergeur.

Ce qui est plus que surprenant, c’est de voir Matt Mullenweg créateur
de WordPress et une des personnes les plus influentes
du web
commencer son post par une banalité (qu’il est néanmoins toujours utile
de rappeler) pour continuer en s’improvisant expert en sécurité en affirmant que, comme
toutes les autres applications,
WordPress doit stocker
les informations de connexions à la base données en clear text et qu’il est inutile
de vouloir crypter ces informations puisque les clés de cryptage seraient facilement
accessibles puisque stockés sur le système de fichiers…

Voir http://awurl.com/rROy45oeC pour
la citation exacte.

Je sais bien que WordPress est développé en PHP mais bon, ASP.net permet de crypter
des sections de configurations depuis ASP.net 2.0 c’est à dire depuis près de 5 ans,
de plus pour éviter les problèmes d’accès aux clés de cryptage, il
est possible d’utiliser DPAPI
qui résous complètement ce problème potentiel.

Donc bon, peut être que crypter ses chaines de connexions n’est pas aussi inutile
que ça et qu’il est techniquement possible de le mettre en place efficacement…

image

Résoudre le problème : Login failed for user IIS APPPOOLDefaultAppPool

En voulant exécuter une application web sur mon poste je me suis retrouvé avec cette
erreur qui a première vue est habituelle :

image

Erreur classique sauf que dans ce cas l’utilisateur en question n’est pas IIS_WPG
comme on le rencontre généralement mais il s’agit curieusement d’un inconnu nommé
“IIS APPPOOLDefaultAppPool”. Et après un petit tour rapide dans la liste des comptes
utilisateurs Windows, on se rend vite compte que cet inconnu est très discret puisque
introuvable.

Cet utilisateur est lié à une nouveauté importante apparue dans Windows 7 et Windows
2008 R2, et pour le moment principalement utilisée par IIS 7.5. En effet la gestion
de l’identité des application pool a été changée :

image

Comme vous pouvez le voir l’identité des application est à présent définie comme étant
“ApplicationPoolIdentity”. IIS 7.5 créé  en effet un nouveau compte utilisateur
pour chaque application pool sous la forme “IIS APPPOOLApplicationPoolName” afin
d’avoir une meilleure isolation. Ces comptes utilisateurs ne sont pas des comptes
utilisateurs classiques puisqu’il s’agit d’un nouveau type de compte utilisateur proposé
par Windows Server 2008 et Windows 7 : les comptes utilisateurs virtuels. Ces comptes
utilisateurs sont des comptes utilisateurs spécifiques qui ont le même comportement
que les comptes traditionnels (ces comptes peuvent être utilisé par des ACL sans aucun
problème) mais ne sont pas visibles dans les interfaces de Browsing de comptes.

Ainsi si vous souhaitez ajouter les droits à l’utilisateur “IIS APPPOOLDefaultAppPool”
pour accéder à votre base, ne changez pas l’identité de votre ApplicationPool
(même si c’est contraire à toutes les pages du web traitant du sujet [ici, ou
encore ])
car vous perdrez le bénéfice de ce nouveau mécanisme de sécurité.

Pour rajouter cet utilisateur au niveau SQL Server il suffit de saisir son nom de
compte complet sans passer par l’interface de sélection de compte.

image

En savoir plus :

What’s New
in Service Accounts in Windows Server 2008 and Windows 7


GoodBye
Network Service

image

Aller plus loin avec les Threads

Lorsque l’on parle de Thread avec le framework .net, le reflexe naturel est de penser
au namespace System.Threading. Ce namespace contient en effet presque tout ce que
.net vous propose afin de gérer le multithreading.

Cela est peu connu et peu utilisé, mais il est possible de dépasser certaines limites
de la classe Thread en utilisant une classe auxiliaire ProcessThread présente quand
à elle dans System.Diagnostics. Cette classe fournit tout un tas de service interessant
comme la possibilité de définir l’affinité d’un thread afin de le faire exécuter sur
un processeur en particulier ce qui n’est pas possible à l’aide de la traditionnelle
classe Thread :

using System.Diagnostics;

namespace FurtherWithThreads
{
    class Program
    {
        static void Main(string[] args)
        {
            int threadId = AppDomain.GetCurrentThreadId();
            SetProcessorAffinity(threadId,1);
            while(true)
            {
                
            }
        }

        static void SetProcessorAffinity(int threadId, int processor)
        {
            var processorThread = (from ProcessThread t in Process.GetCurrentProcess().Threads
                                  where t.Id == threadId
                                  select t).Single();
            processorThread.ProcessorAffinity = (IntPtr) processor;
        }
    }
}

image image

Comme vous pouvez le constater le code s’exécute bien sur des cœurs différents comme
souhaité.

CAT.net n’est pas encore au point

Cela faisait un moment que je souhaitais tester un outil de Microsoft peu connu : Microsoft
Code Analysis Tool .NET (CAT.net)
disponible en version CTP 1.1 depuis la fin
juin. Sur le papier cet outil a l’air prometteur puisqu’il permet d’analyser des assemblies
afin de détecter des failles de sécurité, tels que les injections SQL, les failles
CSS, les injections LDAP ou XPATH, etc. Bref un outil qui devrait être dans la boite
à outils de tout développeur. Connaissant l’existence de l’outil, j’ai toujours été
étonné du peu de publicité qui l’entoure. Excepté le blog
de l’équipe
qui a développé l’outil, quasiment personne n’en parle.

J’ai donc décidé cet après-midi de tester l’outil afin de pouvoir juger de ses capacités
et ainsi en faire la promotion si les quelques tests que j’allais effectuer s’avéraient
concluants. J’avais donc prévu une procédure de test assez simple : test avec un code
créé pour l’occasion pour vérifier que l’outil détectait bien des failles évidentes,
puis test sur de vrais projets tels que DasBlog et Community Server.

Et bien malheureusement, je rédige ce post afin de vous indiquer que je n’ai mis que
10 minutes a effectuer le test puisqu’à la vue de ce simple code, aucune alerte n’est
levée par l’outil :

var connection = new SqlConnection(@"Data Source=.SQLEXPRESS;Initial Catalog=TestDatabase;Integrated Security=True");
connection.Open();
var command = connection.CreateCommand();
command.CommandType = CommandType.Text;
command.CommandText = "select * from employees where lastname_employee='" + textBox1.Text + "'";
var reader = command.ExecuteReader();

Bref, ne perdez pas de temps à utiliser cet outil, il n’est pas encore au point.