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

Suis-je le seul à me battre avec les TableAdapters, ces classes générées par Visual Studio 2005 pour les DataSets typés? D'un côté, ce sont de beaux outils pour générer rapidement des formulaires d'accès aux données: après tout, il s'agit de la génération automatique d'une couche de mapping O/R (les grands mots sont sortis). Mais dès qu'on creuse, c'est la déception: Le TableAdapter se base sur un DataAdapter (après tout il ne fait pas grand chose de plus), mais le DataAdapter sous-jacent est private; Le TableAdapter n'implémente aucune interface (il hérite juste de ComponentModel, ce qui ne nous avance pas à grand chose); Il n'y a pas de moyen de demander à un DataSet typé la liste de ses TableAdapters. Autrement dit, les TableAdapters sont un bel exemple de non-architecture, d'anti-design pattern. En ce moment, j'ajoute la prise en charge de l'accès déconnecté aux TableAdapters, et c'est casse-tête à cause des points ci-dessus. PS: si v

Parmis mes outils favoris quand je développe, il y a NUnit . Il permet de rapidement voir progresser (ou régresser) son projet, au rythme des tests unitaires de plus en plus nombreux qui réussissent. Et il permet bien sûr de rapidement détecter les éventuels effets de bords liés à une (même petite) modification. Malheureusement, NUnit ne permet pas de conditionner des tests par la réussite d'autres tests. C'est apparemment hors de la philosophie de NUnit, pour lequel tout test unitaire devrait être indépendant des autres. Mais la réalité, c'est que l'on a parfois des tests dépendant d'autres test. Un exemple simple: dans une application se connectant à une base de données hébergée, il paraît logique de ne tester la connexion au serveur que si un accès réseau est disponible. Si j'utilise NUnit et que le réseau n'est pas disponible, les deux tests vireront au rouge. Alors que si je conditionne le test de la connexion au serveur à la réussite du test d'accè

A la rentrée 2006, je compte organiser des sessions de formation sur mes deux formations phare: Développer une application Web dynamique avec ASP.net 2.0 (AW2101) Introduction au développement d’applications Windows avec le Framework .net V2.0 (AW2201) Pour cela, je cherche à louer une salle de formation sur Paris, avec des machines bien équipées (1 Go de RAM et un processeur correct). Une salle à me proposer? Contactez-moi ...

En tant que langage fortement typé, C# sauve souvent la vie du développeur grâce à ses vérifications à la compilation. Il nous oblige à connaître lors de la compilation le type vers lequel on veut caster une variable, et c'est l'une de ses forces. Pourtant, je suis tombé sur un cas où j'avais besoin d'un cast (transtypage) dynamique. J'ai en effet besoin d'appeler une méthode par réflexion, et le paramètre à lui passer doit être casté. Considérons l'extrait de code suivant: MethodInfo mi = adapterType.GetMethod("Update", parameterTypes); object[] dataSetParameter = { ds }; mi.Invoke(UnderLyingAdapter, dataSetParameter); Il sert à appeler la méthode Update d'un TableAdapter (celle-ci étant auto-générée, je n'ai pas d'autre choix que la réflexion pour l'appeler, mais c'est un autre sujet). Eh bien, que se passe-t-il si la méthode Update attend un DataSet typé (auto-généré) alors que je n'ai qu'un simple DataSet (System.Dat

C'est avec plaisir que j'inaugure ce nouvel espace, dans lequel vous pourrez me suivre au rythme des octets. Pourquoi un blog de plus? Parce que je crois que c'est la meilleure manière de faire partager au plus grand nombre mes expériences et idées... et de recevoir vos commentaires sur mes projets. Sur ce blog je vous ferai part de mes remarques techniques, pour un public averti, mais aussi de mon point de vue de formateur, de consultant, ainsi que de mes projets. Bref, ce blog est tout public.