Prenons par exemple l’organisation suivante et le cas ou la vue « Index » de la zone « MyArea » fait référence au layout « _Layout » par défaut :

Cela fonctionne très bien tant qu’il n’y a pas d' »Action » de défini dans le layout de base.

Ajoutons une instruction d’inclusion de la vue partielle « _LogOnStatus » comme ceci :

@Html.Action(« LogOnStatus », « Accounts »)

La page d’accueil fonctionne toujours correctement et la vue partielle est bien affichée. Naviguons maintenant vers notre zone et patatra ! Le moteur MVC nous renvoi l’erreur suivante lors de l’accès à une page de votre zone (Par exemple lors de l’accès à l’url /MyArea/Test) :

Le message d’erreur semble parlant mais … il n’est pas correct . Le problème ne vient pas du contrôleur de la vue mais de l’action du layout qui tente de trouver un contrôleur « AccountsController » qui possède une action « LogOnStatus » dans la zone en cours. En effet par défaut lorsqu’un contrôleur est recherché, la zone en cours est prise comme contexte.

Pour remédier à ce problème il suffit d’utiliser, dans le layout de base, la surcharge de Html.Action qui permet de spécifier la zone et de lui passer une nom de zone vide afin de cibler la « zone par défaut » :

Exemple :

@Html.Action(« LogOnStatus », « Accounts », new { area = «  » })

C’est tout bête mais encore faut-il le savoir

Son but ? Fournir une liste de succès qui seront débloqués en fonction du code que vous écrivez !

Totalement indispensable pour pouvoir se la raconter à la pause café ^^?

« Quoi ? tu n’as pas encore débloquer le succès « Ecrire une méthode utilisant un dynamic, 5 délégués et 15 requêtes linq » Noob va. »

Ou pour mettre dans un CV :

« Expérience pro : Tout les succès VS 2010 débloqué »

Bref ça ne sert à rien mais c’est fun.

Pour plus d’info c’est par ici :

http://dev9.channel9.msdn.com/blogs/c9team/Coming-Soon-Visual-Studio-Achievements

En tant que développeur consciencieux, la première étape consiste à aller lire la documentation de MS sur le sujet. Vous la trouverez par exemple dans le Windows 7 Training Kit,et plus précisément dans le withepapper de la rubrique « isolation de la session 0″. En particulier vous y trouverez ces quelques lignes :

« If two-way interaction is required, use Windows Communication Foundation (WCF), .NET remoting, named pipes, or any other interprocess communication (IPC) mechanism (excluding window messages) to communicate across sessions. »

Super ! un coup de WCF et c’est gagné.

Sauf que … Ce que ne précise pas le document c’est que le serveur doit être créé par une session ayant les droits de création d’objets globaux (pour informations c’est le privilège SeCreateGlobalPrivilege). Ce qui dans le cas d’une session avec l’UAC activé est faux (par défaut ce privilège n’est accordé qu’aux … Administrateurs locaux !). Impossible donc de faire communiquer deux processus à travers les tubes nommés s’ils appartiennent à deux sessions différentes. Notez cependant que si les deux processus sont dans la même session, alors cela fonctionnera très bien, WCF n’émettant pas d’erreur et se contentant de créer un tube nommé local …

Bref les tubes nommés et l’UAC ne font pas bon ménage. La seule solution que j’ai trouvé pour l’instant consiste à passer par un TcpBinding à la place mais c’est pas le top du tout.

Ah et au passage, un mauvais point pour le training kit 7 qui « oubli » de mentionner ce détail …

La procédure d’installation et les captures sont disponibles sur son site à cette adresse : http://jpobst.blogspot.com/2009/06/mono-in-visual-studio-2010.html

L’intérêt de tout ça ce situe dans la possibilité de développer des applications Mono sans quitter son environnement préféré ! De plus qui dit ne pas quitter VS c’est également pouvoir accéder aux extensions comme, complètement au hasard hein ; ), TFS.

Bref voici une nouvelle qui va pas mal faciliter la vie des développeurs d’application cross-plateform ou tout simplement de ceux qui souhaiterais tester leur application avec Mono sans installer une distribution Linux dans un premier temps.

Il traite des possibilités pour une application métier de réhostez les designers du framework dotnet et en particulier celui de workflow.

Rappelons rapidement ce qu’est la variance. La variance est une notion liée à l’utilisation des generics. Elle permet d’écrire ce genre de chose :

Aujourd’hui avec C# 3.5 (raccourcis rapide sur les numéros de version, je sais ) cela n’est pas possible. Le compilateur sortira en erreur en expliquant que maCollectionDeString n’est pas du type attendu IEnumerable(Of object). Pourtant en toute logique on peux écrire cela :

string s = « toto »;

object o = s;

Il serait donc logique de pouvoir écrire le code précédent. La variance sur les generics amène cette possibilité.

Au premier abord c’est donc une excellente « feature » qui va simplifier pas mal de code.

Mais c’est aussi une source de problème et de danger qui sont pointés et bien expliqué dans le post.

Je vous livre ici l’url, attention c’est du bon, du haut niveau et il faut s’accrocher à ses brettelles

"What’s new in Beta 1 for the Task Parallel Library?”.

La partie 1 se trouve à cette adresse : http://blogs.msdn.com/pfxteam/archive/2009/03/27/9514938.aspx et traite principalement de la librairie et du nouveau modèle d’annulation introduit dans le Framework .NET 4.0.

La partie 2 quant à elle, traite d’un sujet à mon sens plus “sympas”. Les choix du “rollback” par rapport au design de la classe Future. Cette classe que je n’avais pas abordé lors de la session des techdays ni dans mes articles permet d’exécuter du code asynchrone qui renvoi un résultat.

Le “rollback” se situe au notamment au niveau du nom de la classe qui change de Future(Of T) à Task(Of T). Ce changement de nom peut paraitre anecdotique mais il montre bien que le choix de nommage d’une classe est une chose important pour la simplicité de l’utilisation. Parmi les raisons qui ont poussé les développeurs à effectuer ce changement citons :

• Le fait qu’ils définissaient toujours un Future(Of T) comme “une tâche qui renvoi un ou résultats”
• que le nom Future(Of T) ne montrait pas la notion d’héritage entre un Future(Of T) et un Task(Of T)

L’autre point du post qui me parait important est l’annonce de l’introduction d’une nouvelle classe appelé “TaskFactory”. Cette fabrique de tâche va permettre d’éviter décrire des choses du genre :

(Extrait de la deuxième démo de ma session des techdays ).

Dans cet extrait des tâches sont créées à deux endroits différents mais avec les mêmes options. Le but de la TaskFactory est de positionner les options sur la fabrique et de créer des tâches qui auront directement les bonnes options. Le code de l’exemple en mode “beta 1” donnerais cela :

A noter que n’aillant pas accès à cette beta je n’ai pas réussi à déterminer ce qu’est le myScheduler et le myContinuationOptions (bien qu’il me semble logique que cela correspondent respectivement au TaskManager.Default à aux options de continuation en cas d’exception (arrêt immédiat, attente de la fin des tâches enfants, etc, etc, etc)

Pour finir voici le lien vers l’article du blog de l’équipe de la TPL

Il est vrai que je prend des risques : Je ne suis pas graphiste (mon gout des couleurs ne serait, au dire de certain, pas très développé ), je cherche à développer des sites web qui ont une forte interaction avec leurs environnements, qui sont dépend de données souvent volumineuses et surtout qui se focalisent sur les actions métiers et pas sur l’affichage.

Pourtant Silverlight à tout pour plaire : XAML, C# ou VB.NET et un Framework derrière.

Oui mais voilà : Le Framework Silverlight, bien que basé sur celui de .NET, a été tellement réduit qu?il ne reste plus rien

Passons sur le fait que l?utilisation d’Entity Framework avec Sliverlight est obligatoirement faite à travers des appels REST et que la moindre requête Linq est un vrai calvaire (sans parler du nombre de méthode d?extension qui ont été supprimé (comme Count() par exemple !). Au passage petite expérience personnelle : Je suis revenu aux services web WCF ?traditionnels? qui renvoi des « List(Of T) » pour accéder à mes données, ça marche bien mieux

Passons également sur le fait que le nombre de contrôle fournis par défaut est drastiquement réduit, pour résoudre cela nous avons le Silverlight Toolkit.

Mais franchement quand on veux faire un site en Silverlight qui ?fait des choses? alors là c?est la galère. Personnellement pour accéder à mes opérations métier je n?est pas besoin d?une super accélération graphique par la carte vidéo, ce qui me faut c?est la possibilité d’appeler un webservice externe en https ! Et comme je suis exigeant, il faut également que je puisse lui passer des informations de connexion de type NetworkCredential. Or dans Silverlight 2.0, WCF a tellement été taillé en pièce que l?on ne peux même plus fournir des Credential pour la connexion à un service web !

Et pour pousser le bouchon encore plus loin, j’aimerais également pouvoir réutiliser mes classes métier qui ne contiennent rien deux/trois fonctions sans être obligé de les extraire de leur librairies (compilé en 3.5) pour les mettre dans une librairie Silverlight.

Bref ma conclusion de tout ça c?est que Silverlight, c’est beau, c’est cool, c’est du XAML, mais alors c’est vraiment, vraiment pas fait pour être utilisé en entreprise. Et apparemment Silverlight 3.0 ne va changer la donne? De mon coté tant que la réutilisabilité de l?existant ne sera pas amélioré, je ne pense pas que je ne pousserais pas la technologie en avant. Je vais plutôt aller voir du coté du Framework MVC avec lequel j’ai eu l’occasion de jouer en version RC et qui m’avait beaucoup plus. Par contre si vous avez des vidéos, des images, et peu de code, alors oui Silverlight c’est le pied.

Une dernière chose : Si quelqu’un peut m’expliquer pourquoi la classe NetworkCredential et l’authentification d’un utilisateur sur un service web en général a été supprimé de Silverlight, je suis preneur.

Alors avez vous deviné ?

Un nouveau Tony Hawk’s Pro :aie: ?
Une annonce sur Windows Seven ?
La sortie de VS 2010 ? (ok j’arrête de rêver)

Quelles sont vos hypothèses ? je doit avouer que personnellement je sèche complètement.