Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Par défaut dans IIS, un pool applicatif est recyclé toutes les 29 heures (et quand le serveur reboot). Cette valeur permet que ce recyclage ne se produise pas toujours à la même heure. Ce recyclage peut cependant poser problèmes s’il se produit alors que vos utilisateurs ont un usage intensif du site web associé.

Pour éviter les problèmes, certains administrateurs et/ou développeurs désactivent le recyclage du pool.

Malheureusement cette action peut provoquer d’autres désagréments. Les ressources n’étant jamais libérées, on peut avoir :

  • Des verrous sur des fichiers.
  • Des connexions à des bases de données qui ne se ferment jamais.
  • Un usage de la RAM supérieur à qu’il devrait être.
  • Des fuites de mémoires.
  • ... etc …

De manière générale, une application web peut aussi :

  • Contenir des bugs.
  • Nécessiter des optimisations (que vous n’avez pas le temps de planifier).
  • Utiliser de nombreuses variables statiques (certaines ont peut-être besoin d’être réhydratées périodiquement ?).

Le recyclage du pool peut justement éviter les problèmes liés aux ressources, et vous aider le temps que vous résolviez les erreurs de jeunesse de vos applications web.

Heureusement, IIS offre la possibilité de contrôler quand le pool est recyclé. Comme de coutume sur IIS, il faut passer par la liste des pools. Un clic droit sur le pool à configurer permet de sélectionner les paramètres avancés du pool.

clip_image001

Note : Attention à ne pas sélectionner la seconde option présente dans ce menu. Celle-ci permet de fixer des valeurs par défaut pour tous les pools du serveur. Ces valeurs ne seront appliquées qu’aux pools dont les paramètres n’ont pas été changés manuellement.

 

Via les paramètres du pool on peut mettre à 0 le paramètre « Intervalle de temps régulier (minutes) » pour désactiver le recyclage par défaut (1740 minutes étant égal à 29 heures). On peut ensuite utiliser le bouton « … » qui apparait quand on sélectionne la ligne « heures spécifiques ». Ceci va ouvrir le formulaire pour choisir les heures de recyclage.

clip_image002

 

On peut alors utiliser les boutons « Ajouter » et « Supprimer » pour définir des heures de recyclages.

clip_image003

 

Après validation de ce formulaire et du précédent, les paramètres sont appliqués au pool. Celui-ci sera alors recyclé à heures fixes.

Ensuite, pour éviter le problème de démarrage à froid de l’application web, on peut utiliser les options de démarrage automatique fournies par IIS.

Simple, facile et efficace ;)

Note : Cette option est disponible sur toutes les versions de IIS en service actuellement. Windows 2003 R2 et ces prédécesseurs n’étant plus à utiliser aujourd’hui, je n’ai pas monté de VM pour faire le test.

Visual-Studio-2017-400x400Comme il est de coutume en cette période de l’année, je vous souhaite une bonne année, et surtout un bon Visual Studio 2017. Vu la dernière RC, je ne m’inquiète pas, il sera bon !

Elle est bien loin cette année 2000, où tout le monde prédisait la fin du monde. A cette époque Microsoft parlait de créer le Framework .net. La presse spécialisée n’y croyait pas, cela n’allait pas marcher, C++ allait progressivement disparaître au profit de Java EE qui allait tous les dominer. Windows était le grand méchant loup qui n’allait jamais supporter le moindre standard industriel, et encore moins Linux.

Aujourd’hui les choses ont bien changé. Le Framework .net va bientôt avoir 17ans, il est plus que mature a fait des petits. Je pense à sa variante Open Source et les divers projets Open qui vont avec. De son côté Java s’est vu mettre un pied dans la tombe par Oracle (qui l’aurait cru à l’époque) et est aujourd’hui critiqué par Gartner. C++ se porte toujours bien et l’ami PHP aussi. Windows se porte sur de plus en plus de devises et embarque même un Shell Linux.

Nul doute que cette année encore beaucoup de choses vont changer ;)

A force de passer d'un projet à un autre, il y a toujours un moment où l'on tombe sur ce code que personne ne veut maintenir. Si ! Vous savez, celui qui est là mais que personne ne veut voir car « ça marche bien comme ça! », et « si on y touche, cela ne fonctionne plus ».

Dernièrement, je suis tombé sur l'un de ces codes. Une vue MVC doit être modifiée car une erreur de script se produit de manière imprévisible une fois sur six. Le contexte de l'erreur n'arrive pas à être reproduit. A la première lecture, je suis surpris par le nombre de balises « script » utilisées. Me vient alors l'idée folle de faire la recherche de « text/javascript » dans la page.

Ce qui donne le nombre magique de 23 ! A ce moment, je comprends mieux pourquoi la page est difficile à corriger. Si l'on en avait eu 42, on avait la réponse universelle à tous les problèmes.

« Noooon !!!! Mais pourquoi est-il aussi méchant ???… Parce que ! »

Après regroupement des scripts, j'ai pu facilement constater :

  • Qu'aucune méthode n'attentait que la page ne soit totalement chargée pour se lancer.
  • Qu'il y avait une bonne dizaine d'évènements capturés par ces scripts.
  • Certaines méthodes utilisant des services étaient lancées à la suite les uns des autres, au petit bonheur la chance, alors quelles étaient dépendantes les unes des autres.
  • Des variables déclarées globalement et portant le même nom étaient parfois utilisées par les mauvaises méthodes.

J'ai aussi été en mesure de saisir l'utilité des scripts et de revoir leur orchestration. Petit bonus, le poids de la page a été réduit. En plus, le code peut même être extrait vers un fichier .js pour être minifié.

Moralité ? Pour faciliter la lecture de vos scripts, pensez à les regrouper. Vous y gagnerez :

  • Lisibilité accrue.
  • Gestion des évènements plus claire.
  • Maintenance et évolutivité simplifiée.
  • Poids de la page réduit.

Voici deux nouveautés de la version Core de Windows Server 2016 qui ne raviront pas tout le monde :

  • Il n'est plus possible de passer d'une version Core à une version avec interface graphique.
  • Il n'est plus possible d'installer les consoles sur un server Core.

Ils s'agissaient pourtant de possibilités bien sympathiques introduites par Windows Server 2012 (voir mon billet à ce sujet ici). Lors de la mise à disputions de la RTM de 2016, la nouvelle m'avait désagréablement surpris. Ces possibilités permettaient de s'initier à Core sans pour autant finir bloqué par ces limitations. Maintenant, il faudra donc vérifier la compatibilité de vos outils avant de choisir de procéder à un déploiement de type Core. A noter, qu'aujourd'hui la plupart des features de Windows Server fonctionnent sur Windows Core.

Avec le recul, on peut très bien vivre sans. Si l'on utilise SCVMM, il faut avouer que le fais d'ouvrir une session sur certain serveurs devient totalement inutile.

Par exemple, pour mon Lab personnel, j'ai plusieurs serveurs sur lesquels je n'ai jamais ouvert de sessions (que ce soit pour l'installation ou la configuration de features : AD, DNS, DHCP, WSUS).

 

Lien vers la documentation : https://technet.microsoft.com/en-us/windows-server-docs/get-started/getting-started-with-server-with-desktop-experience

Si vous avez activé les fonctionnalités «Server Essentials» de Windows Server 2016 et autorisé l’accès distant, celui-ci peut ne pas fonctionner normalement. Il est possible que le site d’accès distant ne soit pas bien configuré. En lieu et place de celui-ci, vous pouvez vous retrouver avec la page d’accueil par défaut de IIS 10.

clip_image002

Si l’on ouvre la console IIS et que l’on demande à explorer le répertoire du site, on peut trouver ceci :

clip_image003

On est bien loin de ce que devrait contenir ce répertoire :

clip_image004

Le problème vient du fait, que le site ne pointe pas vers le bon répertoire. Pour corriger cela, il faut modifier le répertoire du site (propriété de base du site) pour le faire pointer vers « C:\Program Files\Windows Server\WebApps\Site » :

clip_image005

Après modification de la configuration, le site est disponible :

clip_image007

Bonne nouvelle pour les abonnés MSDN : TFS 2017 est disponible au téléchargement ;)

Bonne migration !

En temps normal, il n’y a rien de particulier à faire pour qu’une application UWP soit localisée. On ajoute les ressources, et Visual Studio trouve de lui-même les langues utilisables.

Ceci est défini via la section Resources du fichier Package.appxmanifest :

<Resources>
    <Resource Language="x-generate" />
</Resources>

Mais si Visual Studio n’arrive pas à déterminer les langues utilisées, on peut avoir plusieurs difficultés :

- Vous avez localisé une application et vos utilisateurs ne peuvent utiliser que la langue par défaut.

- Lors de la publication, le Store ne vous propose pas de renseigner toutes les langues contenues dans l’application.

Cette situation peut se produire si on a placé nos ressources dans un projet d’assembly dédié de type Portable Class Library. Dans ce cas de figure, il faut lister les ressources que l’on utilise dans le fichier Package.appxmanifest

Ex :

<Resources>
    <Resource Language="en-US" />
    <Resource Language="fr-Fr" />
    <Resource Language="it-It" />
</Resources>

Ceci n’est pas forcément très joyeux à faire, mais cela résout le problème.

Lors de la connexion d’un client à un Windows Server Essentials 2016, il existe a une erreur qui n’est pas documentée :

« Impossible de se connecter au serveur. Le serveur n’est pas disponible ».

Lors de mes tests, j’ai repris la liste des opérations que j’avais planifiées pour ma migration vers Windows Server 2016. C’est alors que je me suis rendu compte que j’avais rétrogradé le contrôleur principal de domaine qui était en service lors de l’installation des features Windows Server Essentials.

Si on regarde du côté des paramètres Windows Server Essentials, on peut constater qu’il existe une section : « Contrôleur de domaine désigné ». Si ce paramètre n’est pas bon, aucun client ne peut être ajouté au serveur.

clip_image001

Pour le changer, il suffit d’utiliser le bouton « Modifier », puis de choisir un serveur dans la liste de ceux qui sont disponibles.

clip_image002

Comme sur 2012 R2, sur Windows Server 2016, pour changer la langue d’un server core, il faut passer par PowerShell.

Toutes les langues n’étant pas installées par défaut, on doit commencer par installer la langue voulue : New-WinUserLanguageList fr-fr

clip_image002

Puis la définir comme étant la langue à utiliser : Set- WinUserLanguageList fr-fr

clip_image004

On peut aussi passer par "control int.cpl" pour changer les options de localisation et de globalisation.

En voulant upgrader un hôte Hyper-V de Windows 2012 R2 à 2016, j'ai eu une petite surprise : Les configurations NIC Teaming doivent être supprimées avant l'upgrade et reconstruites après.

Si en plus vous avez la chance d'utiliser cette fonctionnalité avec des switchs managés, il faudra planifier quelques manipulations supplémentaires avant de passer à Windows Server 2016.

clip_image002

Bonnes migrations à vous ;)

Lors des Microsoft Expériences, j’ai eu l’opportunité de présenter avec Pierrick un talk très sympathique sur l’accessibilité : Tout pour mijoter de belles applications UWP accessibles à tous et partout

Comme promis, voici les slides que nous avions présenté Pierrick et moi : https://1drv.ms/p/s!AmH_MyeRP0S6m89eo3Mltck8lPOg0g

clip_image002 Je souhaitais vous faire part de ma joie de recevoir un nouveau MVP Award. Comme tous les ans, je l’annonce avec un peu de retard. Octobre étant toujours un mois très chargé pour moi.

Cette année, je suis passé de l’expertise "Microsoft Azure" à "Visual Studio and Development Technologies".

Merci à Microsoft pour cet honneur, et un

Microsoft Store Services SDK est le nouveau nom du SDK dédié à la monétisation d'applications UWP. Depuis son passage à la version 10.0.0, de gros changements sont à noter :

  • Fin du support Windows 8.1, ce SDK est orienté UWP à 100%.
  • Fin du AdMediatorControl (il faut utiliser le AdControl, la médiation se faisant côté serveur)
  • Il n'est plus utile de télécharger les packages NuGet des annonceurs.
  • Il n'y a plus de configuration des annonceurs dans l'application.
  • Le AdControl est une classe sealed (donc l'héritage est impossible… sniff).
  • Changements de namespaces.
  • Les events du AdControl ne sont pas les mêmes que ceux du AdmediatorControl.

Si comme moi vous aviez codé une classe partagée entre Windows 8.1 et 10 qui héritait du AdMediatorControl, il va falloir revoir votre code en profondeur. Pour les autres, quelques changements de namespace et d'events devraient suffire.

Côté Windows 8.1 : on peut rester sur la version 2.0.8 du Microsoft Advertising SDK for Windows and Windows Phone 8.x (ceci sans changer son code). Ce SDK peut aussi être utilisé pour passer au AdControl. À l'avenir, ce SDK n'évoluera plus. Seules des correctifs se sécurité pourront être apportés.

Bonne mise à jour ;)

Suite à l'update 3 de Visual Studio 2015, Universal Windows Platform est passée en version 5.2. Version qui a le très désagréable inconvénient de ne pas respecter toutes les règles du store, et qui peut provoquer un rejet lors de la publication d'un package.

Le store indique une erreur 1300 (conformément à la capture suivante). Et la documentions sur cette erreur, n'est pas très épaisse… On nous dit juste de préparer un nouveau package avec Visual Studio. A la seconde tentative qui échoue, on peut laisser tomber.

Le sujet à déjà pas mal animé les forums :

https://social.msdn.microsoft.com/Forums/en-US/6cecb739-f41c-4449-9182-54c40e067652/uwp-submission-failed-with-error-code-1300-and-no-appxsym-file-inside-appxupload-package?forum=wpdevelop

https://social.msdn.microsoft.com/Forums/en-US/e766a904-7346-4f76-bad2-852d3b301b0e/known-issue-version-52-of-microsoftnetcoreuniversalwindowsplatform-delisted-all?forum=Win10SDKToolsIssues

Des issues en rapport ont été créées sur GitHub.

https://github.com/dotnet/corefx/issues/9711

https://github.com/dotnet/corefx/issues/9743

 

Si vous avez mis à jour une application UWP cette semaine, une seule solution s'offre à vous pour le moment : revenir à UWP 5.1.

Pour cela, il suffit de lancer la gestion de package NuGet et de sélectionner ses projets et de demander l'installation de la version 5.1.0 (liste version, on sélectionne 5.1.0 et on click sur Install)

La UWP 5.2 a été retirée temporairement, il n'y a donc pas à craindre pour la suite qu'elle revienne avec ces méchants bugs.

Vous avez envie de découvrir l'accessibilité ? Vous voulez vous faire une idée de ce que peut être la vie avec un PC quand on a un handicap ?

Ne cherchez pas midi à quatorze heures. Pour commencer, il n'est pas utile de vous bander les yeux. Il n'est pas non plus utile d'installer cinquante utilitaires sur son PC, ou d'acquérir de couteuses licences.

Commencez en douceur. Choisissez l'un des deux défis suivants et tenez-vous-y une journée :

  1. Utiliser son PC uniquement avec le clavier.
  2. Utiliser son PC uniquement avec la souris.

Saurez-vous tenir une journée sans craquer ?

Note : contrairement à ce que l'on pourrait croire, le fait de se passer de la souris est souvent plus simple que de se passer du clavier.

Ma définition préférée de l'accessibilité c'est : « Simplifier l'accès aux services pour tous ».

Certain préfèreront des tournures plus longues, plus élaborées ou documentées. Personnellement, je préfère en rester à ces quelques mots essentiels qui traduisent toute la difficulté de la chose et son périmètre.

« Simplifier l'accès »

Avec un PC, on a accès à une infinité de possibilités, d'applications et de service. C'est génial. Mais est-ce pour autant simple d'accès ? Pas toujours !

Exemples d'application ou sites, dont l'accès n'est pas simple :

  • Textes écrits en pourpre ou violet sur fond noir (merci le mal de tête).
  • Navigation impossible au clavier. Comment faire si on ne peut pas utiliser une souris ?
  • Navigation impossible avec une tablette.
  • Plan d'accès d'un salon au format timbre-poste de 300x300px (c'est du vécu).

Et si l'on a un handicap lourd, c'est encore plus difficile. Si l'on est aveugle, nombre de sites ou d'applications sont tout simplement inutilisables. Avec un peu de travail, les développeurs pourraient les rendre accessibles.

« Tous »

On est tous concernés. Potentiellement à tout moment de notre vie, on peut se retrouver avec des difficultés pour effectuer une action ou une autre. Ceci peut être le produit d'un accident, d'une maladie, de l'âge.

En France, on associe presque toujours l'accessibilité à un handicap (vue, fauteuil roulant, amputation). Mais il y aussi ces contenus / applications / sites dont le contenu ne parle à personne ou presque. Exemples :

  • La notice de montage d'un meuble suédois.
  • La première déclaration d'impôts (pour certains, les suivantes aussi peuvent poser problème).
  • Les feuilles de paie.
  • …. Etc…

Dans ces cas-là, nous sommes tous en difficulté.

« Service »

Aujourd'hui, l'informatique est là pour rendre des services. En tout cas, c'est que l'on en attend. Quand votre application n'est pas accessible à un utilisateur, elle ne peut lui rendre aucun service. Pire, elle peut donner une mauvaise image de votre société et de votre travail. Il y a de fortes chances que ce ne soit pas ce que vous souhaitiez.

Conclusion

Pour conclure avec l'exemple ultime de ce que n'est pas l'accessibilité, ce serrait :

  • Une déclaration d'impôts rédigée en suédois.
  • Sur une page écrite en pourpre sur fond noir.
  • Avec une notice de 30 pages qui s'affichent dans un encart de 300 par 300 pixels.
  • Avec un bouton « valider » qui bouge dès qu'on l'approche.
  • Le tout étant inutilisable au clavier.

Voilà, en espérant avoir été accessible ;)

Sur de nombreux projets web, j’ai pu voir des personnes être bloquées pour rediriger les utilisateurs vers une page de login personnalisée. Elles avaient monté des authentifications Custom sans Forms. Pourtant, elles utilisaient la configuration de l’authentification Forms pour fixer la page de Login.

Exemple :

<system.web>
  <authentication mode="Forms">
    <forms loginurl="~/Login">
  </forms>
  </authentication>
</system.web>

Ceci n’est pas très élégant et peut compliquer la compréhension de vos intentions : « Authentification Forms, ou pas Forms ???? »

Heureusement, il existe une solution plus élégante : Coder un module de redirection. Ce module aura pour vocation de rediriger l’utilisateur dès que l’accès à une page lui est refusé. Ceci, sans avoir connaissance des processus d’authentification et d’autorisation.

Pour l’exemple, j’ai codé le module suivant :

- Dès qu’une erreur 401 est produite, on redirige l’utilisateur, vers la page de login.

- La page peut être configurée via les AppSettings.

Ce qui donne ceci :

using System;
using System.Configuration;
using System.IdentityModel.Services;
using System.Web;

namespace MyDemo.Modules
{
    public sealed class LoginPageHttpModule : HttpModuleBase
    {
        private const string LoginPageSettingsKey = "LoginPage";
        private const String LoginPageDefault = "~/Login";        
        private String _loginPage;

        /// 
        /// Chargement de la configuration
        /// 
        protected override void InitializePropertiesFromConfiguration()
        {
            // Utilisation des settings, si il sont présents
            _loginPage = ConfigurationManager.AppSettings[LoginPageSettingsKey] ?? LoginPageDefault;
        }

        /// 
        /// Initialisation du module
        /// 
        /// 
        protected override void InitializeModule(HttpApplication context)
        {
            // S'abonner pour connaitres les réponse données aux utilisateurs
            context.EndRequest += Context_EndRequest;
        }

        /// 
        /// Action en fin de request web
        /// 
        /// 
        /// 
        private void Context_EndRequest(object sender, EventArgs e)
        {
            // Test si il y a un refus d'autorisation
            if (HttpContext.Current.Response.StatusCode == 401)
            {
                HttpContext.Current.Response.Redirect(_loginPage);
            }
        }
    }
}

Côté configuration, il suffit d’ajouter le module à la liste des modules web

<system.webserver>
  <modules>
    <add name="LoginPageHttpModule" type="MyDemo.Modules.LoginPageHttpModule, MyDemo"/>
  </modules>
</system.webserver>

Et on peut définir sa page via les settings

<appsettings>
  <add value="~/Login" key="LoginPage"/>
</appsettings>

Voila ! Simple et efficace en WebForm comme en MVC ;)

 
		

Pour faire suite à mon précédent article sur l’update avec Entity Framework, voici une autre une idée qui a la peau dure : “pour supprimer des données avec EF, il faudrait systématiquement aller chercher en base l’entité avec toutes ses propriétés”.

Même si cela à longtemps été le cas, ceci est faux aujourd’hui. Avec EF, on peut effectuer une suppression en un seul DELETE.

Ceci peut se faire en quelques étapes clés :

1. Instancier un objet avec les valeurs voulues. Seul impératif: utiliser la clé primaire de l’enregistrement à supprimer (logique).

// Instanciation de l'entité à supprimer
Customer entity = new Customer
{
    Id = 10// ma clé primaire
};

 

2. Attacher l’entité au contexte de donnée.

// Attacher l'entité au context
_datacontext.Customers.Attach(entity);

 

3. Expliciter le fait que l’entité doit être supprimée.

// Recupération de l'entry et la marquer pour suppression
var entry = _datacontext.Entry(entity);
entry.State = System.Data.Entity.EntityState.Deleted;

 

5. Lancer l’enregistrement des modification, donc l’exeution du DELETE.

// Enregister les modifications
Boolean result = _datacontext.SaveChanges() > 0;

 

Et pour ceux qui voudraient avoir une idée de ce que cela peut donner dans une méthode complette :

public Boolean DeletCustomer(Int32 id)
{
    // Instanciation de l'entité à supprimer
    Customer entity = new Customer
    {
        Id = id,
    };

    // Attacher l'entité au context
    _datacontext.Customers.Attach(entity);

    // Recupération de l'entry et la marquer pour suppression
    var entry = _datacontext.Entry(entity);
    entry.State = System.Data.Entity.EntityState.Deleted;

    // Enregistrement
    return _datacontext.SaveChanges() > 0;
}

Avec MVC, Entity Framework a pris un essort incroyable. Les mauvaises pratiques aussi. Je profite de cet article pour tordre le coup à une idée qui a la peau dure : “pour mettre à jour des données avec EF, il faudrait systématiquement utiliser l’entité avec toutes ses propriétés”.

C’est est faux. Avec EF, on peut effectuer des mises à jour en choisissant les propriétés utiles.

Ceci peut se faire en quelques étapes clés :

1. Instancier un objet avec les valeurs voulues. Seul impératif: utiliser la clé primaire de l’enregistrement à mettre à jour. Le set sur les propriétés n’a pas besoin d’être fait lors de l’instanciation, ceci facilite juste l’écriture.

// Instanciation de l'entité à mettre à jour
Customer entity = new Customer
{
    Id = 10,// ma clé primaire
    Name = "Duc",
    FirtName = "Donald",
    Email = "faux.mail@outlook.com",
};

 

2. Attacher l’entité au contexte de donnée.

// Attacher l'entité au context
_datacontext.Customers.Attach(entity);

 

3. Expliciter les propriétés qui seront modifiées.

// Recupération de l'entry et marquages de propriété à mettre à jour
var entry = _datacontext.Entry(entity);
entry.Property(c => c.Name).IsModified = true;
entry.Property(c => c.FirtName).IsModified = true;
entry.Property(c => c.Email).IsModified = true;

 

4. (optionnel) Désactiver la validation Si on ne modifie pas certaine propriété qui ont des contraintes (ex: une propriété qui ne peut pas être null).

// Désactiver la validation 
// pour ne pas chercher à valider des donnée qui ne font pas partie de l'update
_datacontext.Configuration.ValidateOnSaveEnabled = false;

 

5. Lancer l’enregistrement.

// Enregister les modifications
Boolean result = _datacontext.SaveChanges() > 0;

 

Et pour ceux qui voudraient avoir une idée de ce que cela peut donner dans une méthode complette :

public Boolean UpdateCustomer(Int32 id, String name, String firstName, String email)
{
    // Instanciation de l'entité à mettre à jour
    Customer entity = new Customer
    {
        Id = id,
        Name = name,
        FirtName = firstName,
        Email = email,
    };

    // Attacher l'entité au context
    _datacontext.Customers.Attach(entity);

    // Recupération de l'entry et marquages de propriété à mettre à jour
    var entry = _datacontext.Entry(entity);
    entry.Property(c => c.Name).IsModified = true;
    entry.Property(c => c.FirtName).IsModified = true;
    entry.Property(c => c.Email).IsModified = true;

    // Enregistrement
    try
    {
        // Désactiver la validation 
        // pour ne pas chercher à valider des donnée qui ne font pas partie de l'update
        _datacontext.Configuration.ValidateOnSaveEnabled = false;
        // Enregister les modifications
        return _datacontext.SaveChanges() > 0;
    }
    finally
    {
        // Retour à la normale
        _datacontext.Configuration.ValidateOnSaveEnabled = true;
    }
}

Si existait un concours des fausses idées autour de l’utilisation d’un bloc Try, Catch, Finally en .net, j’en proposerais deux :

1. En cas d’exceptions “très particulières”, On peut sortir d’un Try sans aller dans un Catch générique. Il faut donc coder un Finally et utiliser des variable pour savoir si tout c’est bien passé.

Exemple C# :

// Je déclare des variable
// Je déclare aussi des variable pour savoir si tout c'est bien passé
Boolean toutVaBien = false;
try
{
    // Faire qqchose

    // Fin de qqhcose
    toutVaBien = true;
}
catch(Exception ex)
{
    // Je capture tout
}
finally
{
    // Je corrige mon context car je sais que tout ne s'est pas bien passé
    if (!toutVaBien)
    {

    }
}

Désolé, c’est faux. Si il y a exception, on passera par le catch. Ceci est valable, même si’il y a une exception système (on pourra même savoir ce qu’elle contient). Il n’y a pas d’exception “particulières”, “très particulières”, voir “trop particulières” qui puissent passer à côté du Catch.

Seul cas “possible” : le processus de l’application est coupé. Dans ce cas, le finallly ne sert à rien. Votre application est Off, un point c’est tout Winking smile

 

2. Il faut catcher finement ses exceptions pour avoir de meilleures performances et un impacte moindre sur les ressources système.

Exemple C# :

try
{
    // Faire qqchose
}
catch (MyTypedException ex1)
{
    // J'application la corretion générique
    Corriger();
}
catch (Exception ex2)
{
    // J'application la même corretion générique
    Corriger();
}

Désolé, c’est aussi faux. Ce code n’a aucun impact bénéfique. En plus, faire deux fois la même opération dans deux Catch différents. Ce qui induit une redondance inutile Winking smile

voilà, si vous avez d’autres blagues du genre, il ne faut pas hésitez à les partager.

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- Office 365: La gestion des Attachments dans les listes riches de SharePoint Online par Blog Technique de Romelard Fabrice le 01-10-2017, 17:56

- [IIS] On désactive le recyclage des pools, ou on le contrôle ? par Blog de Jérémy Jeanson le 01-06-2017, 20:48

- Bon Visual Studio 2017 ! par Blog de Jérémy Jeanson le 01-06-2017, 12:53

- Office 365: Message d’erreur sur SharePoint Online “The file [file name] is checked out or locked for editing by [username]” par Blog Technique de Romelard Fabrice le 01-05-2017, 16:02

- Office 365 : Script PowerShell pour créer le mapping des utilisateurs dans ShareGate à partir de SharePoint 2007 par Blog Technique de Romelard Fabrice le 12-29-2016, 15:36

- Regroupez vos sections javascript ! par Blog de Jérémy Jeanson le 12-29-2016, 13:02

- Retour en arrière sur Windows Server Core 2016 par Blog de Jérémy Jeanson le 12-20-2016, 13:07

- SharePoint 2007: Script PowerShell pour nettoyer les listes vides avant migration vers Office 365 - Updated par Blog Technique de Romelard Fabrice le 12-14-2016, 16:34

- Server Essentials 2016 et site remote web access indisponible par Blog de Jérémy Jeanson le 12-09-2016, 13:10

- Office 365: Utiliser les alertes dans SharePoint Online par Blog Technique de Romelard Fabrice le 11-30-2016, 12:45