Wilfried Woivré & .Net

Afficher des informations dans la fenêtre de sortie de Visual Studio

MAI19

Quand on fait du XAML que ce soit en WPF, Silverlight ou WP7, on est bien heureux de voir apparaitre ces petits messages d’erreur dans la fenêtre de sortie lorsque l’on est en mode debug de notre application !

Ici comme on peut le voir il s’agit uniquement d’une erreur de binding, qui nous informe que la propriété “FirstName” n’a pas été trouvée :

 

image

 

Et si on voyait comment ajouter nos propres messages dans cette fenêtre, et bien tout est là pour nous aider, c’est très facilement faisable grâce au namespace System.Diagnotics

 

this.Loaded += (sender, e) => System.Diagnostics.Debug.Print("Message perso => Un petit test ?");

On obtient en mode DEBUG, notre message personnel dans la fenêtre de sortie

image

Et comme la vie est bien faite, en mode release, rien n’apparait !

 

Bon bien entendu, rien ne sert de polluer cette fenêtre outre mesure, mais c’est toujours mieux qu’une trentaine de message box d’information pour lancer votre programme et être sûr que tout ce passe bien !

Remonter

Grouper vos classes partielles dans l’explorateur de solution.

OCTO22

Pour tout ceux qui programme en .Net, notamment avec C# ou VB.Net, vous avez déjà du créer des classes partielles, surtout si vous travaillez avec Entity Framework et que vous allez lu cet article. Vous pouvez donc, vous retrouver un jour dans ce cas avec deux classes partielles avec des noms un peu différents afin de séparer les différents méthodes pour que cela soit plus facile à lire. image Le problème dans ce cas, c’est que les fichiers OuSuisJeService et RequestService ne sont pas placés côté à côte dans l’explorateur de solution comme on peut le voir image Ce qui serait bien, ça serait de grouper vos fichiers, un peu à la manière des edmx ou des interfaces / code behind. Et bien vu qu’avec Visual Studio on peut presque tout faire. Il suffit pour cela d’éditer votre fichier csproj
  <ItemGroup>
    <Compile Include="GeoLoc\GeoLoc.cs" />
    <Compile Include="OuSuisJeService.cs" />
    <Compile Include="Place.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
    <Compile Include="Repository.cs" />
    <Compile Include="RequestService.cs" />
    <Compile Include="Response.cs" />
    <Compile Include="User.cs" />
  </ItemGroup>
Ensuite vous retrouver votre élément RequestService.cs, que vous allez modifier de cette façon :
  <ItemGroup>
    <Compile Include="GeoLoc\GeoLoc.cs" />
    <Compile Include="OuSuisJeService.cs" />
    <Compile Include="Place.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
    <Compile Include="Repository.cs" />
    <Compile Include="RequestService.cs">
      <DependentUpon>OuSuisJeService.cs</DependentUpon>
    </Compile>
    <Compile Include="Response.cs" />
    <Compile Include="User.cs" />
  </ItemGroup>
Il vous suffit de recharger ensuite votre projet, et voilà la magie opère image
Remonter

Attribuer un alias à une classe

JANV22

 

Dans la création de gros site ASP.Net, on se retrouve souvent avec des sites qui contiennent de nombreuses pages ou UserControl, pour éviter que notre projet devienne ne soit dévasté par la pollution de page ou UserControl, il faut créer des dossiers et des sous dossiers pour qu’on puisse facilement si retrouver.

 

On va donc classiquement créer un dossier User qui regroupera toutes les pages et user control concernant les utilisateurs du site. Jusque là rien de bien surprenant, on va créer une page du type de celle-ci :

namespace WebApplication3.User
{
    public partial class EditUser : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {

        }
    }
}

On a donc bien dans notre page WebApplication3.User.EditUser, on va donc vouloir récupérer notre utilisateur à éditer, qui est un objet de type User, on va donc commencer par appeler notre objet métier en créant une méthode GetUser, et là on a un problème, en effet notre entité User n’est pas trouvé, mais il trouve un namespace.

image

Ceci est donc parfaitement normal puisqu’il n’y a pas de référence et using vers ce objet de type métier dans notre cas pour le moment, cependant Visual Studio ne nous le propose pas contrairement à d’habitude. On va donc l’ajouter à la main…

 

Mais là même erreur, en effet Visual Studio est totalement perdu, il ne sait pas s’il s’agit d’un type ou d’un namespace. Et pourtant à cet endroit du code, un namespace serait légèrement mal placé.

On a donc 2 solutions qui s’offrent à nous, soit passé par le nom complet, soit ici Entities.User, soit ajouter un alias dans les using :

using EntityUser = Entities.User;

namespace WebApplication3.User
{
    public partial class EditUser : System.Web.UI.Page
    {
        public EntityUser GetCurrentUser()
        {
            throw new NotImplementedException();
        }

Notre application compilera donc sans soucis, on a juste ajouté un alias à la classe Entities.User afin que notre Visual Studio ne soit pas chamboulé par tous ces noms de classes, namespaces ou on n’a jamais d’idée pour les nommer.

Remonter

NDepend : Un outil bien pratique

JANV5

 

Les outils pour travailler avec .Net sont très nombreux comme on peut le voir sur SharpToolbox. Parmi les plus connus vous avez bien entendu Reflector qui vous permets de faire de l’introspection de code, ou alors ReSharper qui vous rajoute grand nombre de fonctionnalité dans Visual Studio. Vous pouvez trouver la plupart des outils dont vous pourriez avoir besoin dans votre vie courante.

Prenons un exemple, il arrive souvent en entreprise que vous vous retrouviez sur un projet qui a déjà été amorcé par d’autres développeurs. Malgré les différentes documentations à votre disposition il n’est pas toujours évident de connaître toute la structure de l’application et sa complexité au premier coup d’œil. Il y a pour cela un très bon outil qui s’appelle NDepend.

Ce logiciel développé par Patrick Smacchia existe sous la déclinaison de quatre versions (Trial, Academic, OpenSource ou Professional). Le site de l’outil est d’ailleurs très bien fournis en documentation pour l’utilisation de l’outil.

http://www.ndepend.com/Default.aspx

Grâce à celui-ci vous allez pouvoir explorer en détail la complexité de votre code, ceci grâce à un langage proche du SQL. Effectuer des tests de refactoring et analyser l’impact de ceux-ci sur le code. Mais le mieux pour que vous vous fassiez une idée, c’est d’aller voir toutes les démonstrations du site, et après de le tester bien entendu. Et si vous êtes convaincu n’hésitez pas à l’acheter. C’est un investissement utile pour les gros projets il me semble, mais il convient très bien à des projets de taille moyenne bien entendu !

Remonter

Visual Studio 2010 : Intégration de F#

NOVE27

Alors je suppose que vous êtes au courant, Visual Studio 2010 supporte en natif depuis ces premières versions le langage F#.

Basé sur le langage Caml, il intègre toutes les supers fonctionnalités de la plateforme .Net. Enfin bref, aucune démonstration ici, mais je voulais vous montrer un élément à Visual Studio bien utile quand vous voulez jouer un peu avec le F#.

Je suppose donc que comme moi, lorsque vous avez commencé le C#, vous deviez regretter de devoir à chaque fois compiler, lancer votre jolie application console, et attendre le résultat, qui généralement n’était pas le bon ! (Souvenirs, souvenirs …) Vous auriez je pense avoir une joli fenêtre interactive afin de construire votre application pas à pas, mais tout en vérifiant rapidement vos données.

Alors F# et Visual Studio apporte cela, en effet dans les nouvelles fenêtres de notre outil de développement, on peut voir apparaître “F# Interactive” :

image

Cette fenêtre a toujours été en fait mon rêve, pouvoir rapidement coder et tester en même temps sans à avoir à créer un projet console appelé “ConsoleApplication142”

Alors comment ça marche maintenant, dans votre fenêtre vous pouvez écrire tout code F# que vous voulez tester, par exemple :

image

On voit donc ici, la création d’une méthode square qui prend une valeur en paramètre, et qui retourne le carré de celle-ci, puis un appel afin de tester.

Mais très important, on peut voir aussi que la fenêtre F# Interactive retient bien la méthode square en mémoire, pour d’éventuel appel, et donc on peut vraiment tester, ou apprendre le F# au pas à pas.

Voilà, j’essayerai de vous publier divers articles sur la technologies F#, qui m’a l’air très intéressante, et qui je pense peut avoir un bel avenir dans la recherche, calcul algorithmique, et bien entendu les mathématiques.

Remonter