My life coding HTML5, .NET Core, Azure, Docker, Kubernetes, ASP.NET, UWA, WPF, ...

...mais ce n'est pas le bon! En recevant ma mise à jour MSDN Library ce matin, j'ai sauté au plafond en voyant que le Service Pack 1 de Visual Studio en faisait partie . Je savais que le SP1 de Visual Studio 2005 était en beta, mais je n'avais pas ouï dire de sa sortie. Quelle joie! Parce qu'avec les nombreux bugs et limitations de Visual Studio 2005, un SP se fait vraiment attendre... Mais la joie fut de courte durée: en regardant de plus près, j'ai vu que c'était le SP1 de Visual Studio 2003 . Quelle déception! D'autant plus que Visual Studio 2003 est nettement plus stable que 2005.

Visual Studio 2003 prenait en charge l' héritage visuel . C'est à dire le fait d'hériter d'un formulaire pour en créer un nouveau (après tout ce sont des classes, donc c'est permis par les langages .net). Visual Studio 2005 le prend donc aussi en charge. Mais avec un certain nombre de limites . Il est notamment impossible de modifier un ToolStrip dans un formulaire enfant s'il a été défini dans son formulaire parent. Pire: l'enfant ne peut même pas ajouter son propre ToolStrip. Et Microsoft, que disent-ils de ce problème? Qu'ils savent, et qu'ils ne l'ont pas fait " parce que cela demandait un effort d'ingéniérie" ! A noter que ces limitations ne s'appliquent qu'au mode Design. En écrivant le code, on peut faire tout cela sans problème. Mais dans ce cas à quoi sert le mode Design?

Lors de l'installation de Visual Studio Orcas September CTP, dont je vous parlais ce matin , après démarrage de la machine virtuelle, on a le message suivant: Rien d'extraordinaire, puisque sur ma machine le disque de base se trouve à un autre emplacement que chez Microsoft. Mais ce qui est cocasse, c'est le répertoire dans lequel ils placent la base: TimeBombedBase . Nous sommes donc prévenus: si ça explose, on ne pourra pas venir se plaindre!

Greg nous annonce que la CTP de septembre de Visual Studio Orcas est maintenant disponible. Vu le rythme auquel Microsoft sort des betas en ce moment, il n'y a rien de surprenant. Mais la nouveauté, c'est que cette CTP est disponible en tant qu' image virtual PC . Et là ça change tout: au lieu de devoir installer Vista, le SDK et Visual Studio, c'est du "download and play". A télécharger ici . Le message de Greg est ici .

Mes formations inter-entreprises sont maintenant planifiées jusqu'en juin 2007. Vous pouvez dores et déjà préparer le plan de formation d'entreprise 2007. Pour rappel, mes formations sont les suivantes: Développer une application Web dynamique avec ASP.net 2.0 Introduction au développement d’applications Windows avec le Framework .net V2.0 Elles sont admissibles au titre du plan de formation de l'entreprise, du DIF (Droit Individuel à la Formation) et du CIF.

Nous connaissons la syntaxe: using Toto = System.Data; Toto.DataTable t; Elle est pratique, mais d'une utilité finalement limitée. Ce qui est moins connu est que cet aliasage fonctionne aussi sur les noms de classes. Ce qui tombe bien car les noms de classes générés par un DataSet typé sont pour le moins alambiqués. Par exemple, si je génère un DataSet AllData contenant une table Comics, pour faire référence à la DataTable et à ses lignes il faudra écrire: using API; [...] AllData.ComicsDataTable t = a.GetData(); AllData.ComicsRow c = t[0]; Grâce aux alias, il suffit d'écrire: using Comics = API.AllData.ComicsDataTable; using Comic = API.AllData.ComicsRow; [...] Comics t = a.GetData(); Comic c = t[0];

Plus je l'utilise, plus je déteste Visual Studio 2005 . Il permet de créer des petits projets très vite, mais on se rend compte que tout son code autogénéré est inmodifiable. Ce qui est très gênant pour les gros projets, où ce code est rarement adapté. En l'occurrence, je me rends compte que sa gestion automatisée des propriétés est inmodifiable, et même boguée. Pour éviter au développeur d'écrire dans le fichier app.config (qu'est-ce que c'est dur, écrire dans un fichier XML!), il pond une classe codée dans Settings.Designer.cs , qui ne fait presque rien à part placer un attribut DefaultSettingValueAttribute devant chaque propriété fortement typée. Et justement, ce DefaultSettingValueAttribute prend le pas quand les configurations sont pour une DLL, car alors VS2005 (qui veut pourtant tout automatiser) ne recopie pas le contenu du fichier de configuration dans celui de l'EXE utilisateur.