Patrice 's Blog

Changement d'adresse de mon blog...

Tout est dans le titre, ce blog change d'adresse et est donc dorénavant disponible via http://blogs.labo-dotnet.com/blogs/patrice

Je suis rentré de Chine hier soir et grosse surprise, je me rends compte que tout a été migré sur Community Server et que donc ma skin a disparu mais surtout que l'url du blog a changé... :(

Je vais donc essayer cette nouvelle version avant de décider si mon blog déménage vers un nom de domaine perso que je maitriserai totalement.

Merci de mettre à jours vos feeds si vous souhaitez continuer à me lire.

Bientot en Chine...

Après avoir passé 15 jours début Janvier à SUPINFO Océan Indien (île de la réunion) (pour ceux qui le veulent, quelques photos de la réunion) :

(Sympa comme cadre de travail non ? :))

Je m'envole demain soir en Chine à 1h30 de voiture de Pékin pour donner des cours à l'université de Hebut. Vous aurez donc droit à quelques photos de Chine dans les jours qui viennent. (je m'excuse d'avance de la pollution pour ceux qui n'aiment pas ce genre de post...)

ASP.net 2 : Passer de la beta 1 à la beta 2

Si vous développez déjà avec Whidbey et que vous souhaitez préparer vos projets ASP.net à la beta 2 qui sortira en Mars-Avril vous pouvez consulter cette page qui liste les principales différences qu'il faut prendre en compte pour rendre ses pages compatibles.

Ayant un projet ASP.net 2 (un projet un peu "proof of concept" où je refond un site existant en ASP avec l'aide de mon collègue Jb) et l'ayant débuté (le site sera en prod lorsque la beta 2 et la licence go-live sera disponible) , j'ai développé un petit outil qui permettra de se faciliter la vie. Il sera disponible quand la béta 2 de VS 2005 le sera ;). (Vous n'en avez pas besoin si vous utiliser la CTP December).

Utiliser l'émulateur Windows CE (donc Pocket PC) sans Visual Studio

Malgré ce que l'on peut lire sur le net, il est tout à fait possible d'installer l'émulateur Pocket PC sans a avoir à installer Visual Studio .net. Cela peut être pratique pour tester ou même pour faire tout type de démo avec l'émulateur.

Pour ce faire télécharger l'émulateur Windows CE 5.0 :

http://www.microsoft.com/downloads/details.aspx?FamilyID=a120e012-ca31-4be9-a3bf-b9bf4f64ce72&DisplayLang=en

Puis télécharger les images en français :

http://download.microsoft.com/download/e/2/8/e28792ca-d04b-407b-9b18-75b9128f0cc9/Windows%20Mobile%202003%20Second%20Edition%20Emulator%20Images%20for%20Pocket%20PC%20-%20FRA.msi

Faites ensuite un .bat contenant la commande suivante :

"C:\Program Files\Windows CE 5.0 Emulator\Emulator_500.exe" /ceimage "c:\Program Files\Pocket PC 2003 Second Edition Emulators\FRA\Pocket_PC\PPC_2003_SE_FRA.bin" /skin "c:\Program Files\Pocket PC 2003 Second Edition Emulators\FRA\Pocket_PC\PPC_2003_SE.xml"

(tout mettre sur une seule ligne)

Et le tour est joué :)

[Tips] Petit bug VS .net 2003 : Les évènements fantômes dans le compact framework

Ce post aurait pu être dans la rubrique VB.net is not C# mais plus que le langage C# qui aurait pu être mis en cause, c'est bien l'IDE qui est fautif sur ce petit problème qui intervient lorsque l'on développe des applications en C# pour le Compact Framework.

Certaines personnes sont venues me voir en me disant que le C# ne gérait pas l'évènement Deactivate lorsqu'ils développent une application Compact framework. En effet, en regardant la liste des évènements disponibles on constate que cet évènement est absent de la liste.

Bien evidemment, ce n'est pas le langage qui est en faute, c'est Visual Studio qui ne l'affiche pas dans la liste.

(En VB, l'évènement est bien présent dans la liste)

Pour régler ce problème, c'est très simple, il suffit de coder la gestion de l'évènement à la mano :

Créer un delegate dans la méthode InitializeComponent :

this.Deactivate+=new System.EventHandler(this.mydeactivate);

Puis créer la méthode qui sera appelée lorsque l'évènement sera déclenché :

private void mydeactivate(object sender, System.EventArgs e)

{

//mon code

}

Student Club Summit 1ère edition

La première édition du Student Club Summit a eu lieu ce vendredi et ce samedi. Cet évènement gratuit et organisé par Microsoft France était destiné aux étudiants, students clubs, et MVS de toute la France. Les personnes présentes ont pu découvrir (ou re-découvrir) l'Imagine Cup et notamment la catégorie Visual Gaming, TheSpoke, etc...

Et surtout ces deux journées furent l'occasion d'assister à un bon nombre de sessions aussi interessantes que variées (Présentation de la plate-forme 64 bits, La Programmation Orientée Aspect, Sharepoint, InfoPath, etc...).

Cet évènement fut plutôt réussi et a réunit chaque jour plus d'une centaine d'étudiants venant de toute la France (Lyon, Perpignan, Nice, Paris, etc...)

J'y ai présenté 2 sessions : (Cliquer pour télécharger les slides)

Présentation d'InfoPath

Ecrire du code sécurisé avec .net

[FUN] Don Box Tech Ed 2001

Cela date un peu mais cela reste très fun. Je vous invite à visiter cette page et à regarder cette vidéo pour regarder Don Box qui fait encore une fois preuve d'originalité lors d'une session qu'il présenta au Tech Ed 2001 à Barcelone.

Je ne vous en dis pas plus, à vous de juger...

Compte Rendu Rencontres Visual Basic 9 décembre 2004 à Toulouse

Je vous l'ai indiqué plusieurs fois sur mon blog, Microsoft organise en ce moment les rencontres Visual Basic dans toute la France. Le but principal de ces rencontres et de sensibiliser le développement avec la plate-forme .net et plus particulièrement avec Visual Basic.net. Je me suis donc rendu aujourd'hui à la rencontre VB qui avait lieu sur Toulouse.

74 personnes étaient présentes et ont été très interessées par cette grosse demi-journée. Cette demi-journée fut l'occasion de découvrir vb.net à travers le développement d'applications simples mais variées : une application windows, web, service web, mobile. Nous avons également eu quelques rappels de POO ainsi qu'une introduciton à ADO.net et son mode déconnecté. Les problèmatiques de migration ont été également abordés.

Nous avons donc eu droit à une bonne introduction au développement .net et au VB.net et je suis persuadé qu'il y a plusieurs développeurs présents dans la salle qui ont essayé de developpeur leur première application une fois rentré chez eux grâce à VB.net 2003 Edition Initiation qui est offert gratuitement à tous les participants.

J'ai été également agréablement surpris par les questions posées par le public qui ont bien montré que contrairement à ce que certains pensent les développeurs VB6 savent ce qu'ils font et ce qui se passe derrière...

Si vous êtes développeurs VB 4,5,6 et que vous n'avez pas encore franchi le pas vers VB.net, je ne que vous conseillez de vous rendre aux dernières rencontres VB.net qui seront sur Paris.

Le MSDN Régional Director Sud-Ouest et Eric Vernié (MS France)

[VB.net is not C#] Option Strict

Dans mon post précédent, Matthieu Nicolescu me suggérait un nouveau post pour cette rubrique VB.net is not C# car il semblait plutôt enervé (et il a entièrement raison) des libertés que permet le VB.net.

En effet, par défaut, le code suivant compile mais ne fonctionne pas :

Sub Main()

DoSomething("zzz") ' Le code fonctionne si on met "True" à la place de "zzz"

End Sub

Public Sub DoSomething(ByVal param As Boolean)

If param Then

Console.WriteLine("Le paramètre est à True")

End If

End Sub

Je suis entièrement d'accord il est plutôt choquant que ce code compile sans problème et lève une exception lors de l'éxécution. Cela est du au langage VB lui même qui est très, et même trop permissif. En effet, il est toujours possible de ne pas déclarer ses variables en VB.net. (il suffit de mettre un Option Explicit Off), et on peut toujours laisser faire le compilateur VB pour le cast des variables et ainsi ne se soucier de rien. Si l'on souhaite éviter que le code présenté ci-dessus compile et imposer au développeur le cast explicite il faut mettre la directive Option Strict à On pour tous vos projets VB.net. Vous éviterez ainsi des erreurs plus ou moins subtiles à détecter...

[Rappel] Les rencontres Visual Basic

Je vous rappelle que les rencontres Visual Basic ont lieu dans toute la France et qu'elles continuent. Je serais pour ma part à Toulouse le 9 décembre.

Microsoft organise cette année les rencontres Visual Basic dans 7 villes françaises. Ces rencontres seront l'occasion de découvrir .net et ainsi apprécier tous les avantages de la migration vers la plate-forme .net. Vous êtes développeurs VB 6, Delphi, Powerbuilder, Access, vous savez maintenant quoi faire

Pour vous inscrire :
http://galilee.microsoft.fr/vbtour/

07/12/2004	Nantes	s'inscrire
09/12/2004	Toulouse	s'inscrire
14/12/2004	Paris	s'inscrire
15/12/2004	Paris	s'inscrire

[VB.net is not C#] Les imports (<=>using)

Les développeurs C# seront sans doute surpris mais le code suivant compile sans aucun problème sous VS.net...

Public Class clsAList

Private m_AList As New ArrayList

Public Sub New(ByVal thearraylist As ArrayList)

m_AList = thearraylist

End Sub

End Class

Vous aurez sans doute remarqué qu'il manque normallement un Imports System.Collections nécessaire à l'utilisation de la classe ArrayList.

Cette classe est compilée sans aucun problème par VS.net alors que si vous saisissez cette classe telle quelle dans un autre IDE (#develop par exemple) ou même dans notepad et utilisez le compilateur vb.net, vous devriez avoir des ennuis...

Comment est-ce possible ? Grâce aux Imports "automatiques" fonctionnalité proposée par VS.net (et même #Develop).

Cette fonction peut paraitre séduisante au premier abord mais je vous déconseille néammoins de l'utiliser. En effet, vous l'avez peut-être déjà compris, cela nuit gravement à la portabilité de votre code source... Imaginons que vous creez une solution sous #Develop que vous ajouter la classe ci-dessus, votre application ne compilera plus, etc.. etc... Vous avez compris le problème...

En conclusion mettez explicitement tous les Imports nécessaires dans vos classes pour éviter ce genre d'ennuis...

Les développeurs C# n'auront pas ce genre d'ennuis puisque cette fonction n'est pas implémentée.

Emulateur dans emulateur... (suite et fin)

Après quelques recherches sur les raisons de l'incompatibilité de Virtual PC et l'émulateur utilisé par Visual Studio.net 2003, je me suis rendu compte que l'émulateur utilisé par VS.net ne semble être rien d'autre qu'une sorte de Virtual PC. En effet, cet émulateur n'est pas développé par Microsoft mais par... Connectix la société créatrice de Virtual PC qui s'est fait rachetée par Microsoft... En conclusion ce bug est dit "by design" puisqu'il est n'est pas possible de faire tourner une machine virtuelle VPC à l'intérieur d'une autre machine virtuelle VPC.

Bonne nouvelle, l'émulateur livré avec VS 2005 a été entièrement refait et fonctionne sous Virtual PC. Encore une raison d'attendre avec impatience Octobre ou Novembre 2005...

3637

Emulateur dans Emulateur...

grrr

Je n'aime pas trop Virtual PC et le problème que je rencontre n'arrange pas l'opinion que j'ai de ce logiciel...

Il est apparemment impossible d'utiliser l'émulateur Pocket PC ou autre livré avec Visual Studio.net 2003 sous Virtual PC... J'ai trouvé plusieurs personnes ayant ce problème sur le net mais je n'ai trouvé aucune solution pour palier à ce problème... Quelqu'un a une idée ??

[VB.net is not C#] Les interfaces

Autre différence entre VB.net et C# : les interfaces. Les interfaces en C# profitent du fait que l'objet représenté par l'interface héritera forcément de System.Object. C'est donc tout naturellement qu'une interface (en c#) implémente les méthodes GetType, ToString etc... de System.Object. Voir ci-dessous :

En VB.net, il en est tout autrement comme vous pouvez le voir ci-dessous.

VB.net ne vous permet pas d'utiliser directement les méthodes ToString, GetType pour les interfaces comme c'est le cas en C#, vous devez caster votre interface en un objet pour arriver au même résultat.

On peut se dire que le VB.net à raison, une interface étant un contrat, et donc la consommation de cette interface ne devrait permettre d'utiliser que les méthodes publiées mais la où le C# à raison, c'est que n'importe quel objet implémentant une interface hérite forcément de System.Object.

Outre la question de la pertinance du choix pour telle ou telle implémentation -nous vous laissons discuter de cela dans les commentaires - le fait est que, par exemple, lors ce que l'on récupère une interface, et qu'on veut travailler sur son type, il va falloir créer une variable temporaire, déclarée comme un Object, pour pouvoir enfin accéder à ces méthodes.