Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Je suis un peu surpris que les évolutions d'Hyper-V sur Windows 10 n'aient pas fait beaucoup de bruit. Certaines évolutions sont pourtant très intéressantes.

Pour mon usage, j'ai surtout noté les points suivants :

  • Le changement à chaud de la quantité de RAM d'une VM. Ceci fonctionne avec des VM Windows 10 ou un OS Server (je n'ai pas testé en dessous de Windows 2012). Il faut cependant faire attention à ne pas trop diminuer la RAM du client, surtout si vous avez un SQL serveur sur la VM ;)
  • Le changement à chaud des cartes réseau d'un VM (ajout, suppression possible). Très pratique quand on est tête en l'air.
  • La possibilité de choisir les credentials utilisées pour se connecter à un serveur Hyper-V. Il n'est donc plus utile de faire du runas pour lancer sa console.
  • La mise en veille qui ne perd plus en fonctionnalités quand on a un Hyper-V installé sur son portable (ou sa tablette).
  • Le support des nouveaux formats de fichiers pour stocker les configurations des VM et de leurs états. Ceci tout en conservant la possibilité de gérer un serveur Hyper-V de version plus ancienne.
  • Le SecureBoot exploitable par les VM Linux.

Il y a aussi les CheckPoint de production. Cependant, je n'ai jamais été très chaud pour utiliser les Checkpoints. Je préfère utiliser des backups. Ceci évite beaucoup de problèmes quand une machine du domaine doit être restaurée.

La Technical Preview 3 de Windows Server 2016 arrive avec beaucoup de changements. L'ISO a été revue pour simplifier le déploiement de NanoServer. Si on monte l'ISO sur son PC, on trouve un dossier NanoServer :

 

Ce dossier contient des scripts PowerShell qui facilite le déploiement et la création de disques virtuels (testé et approuvé, cela marche très bien).

Le ReadMe pointe vers le site Technet qui explique comment utiliser les scripts https://technet.microsoft.com/en-us/library/mt126167.aspx

On y apprend entre autre :

  • Comment effectuer la configuration de base (Nommage, IP, Drivers…)
  • Comment créer et utiliser un fichier de réponse (avec un exemple pour ajouter son server au domaine)
  • … et quelques astuces pour bien démarrer.

Maintenant, vous n'avez plus d'excuse pour ne pas essayer.

Je viens d'avoir une petite surprise sur mon Lab Hyper-V. En voulant migrer un VM en Live d'un server vers un autre, je me suis retrouvé confronté à la boite de dialogue suivante :

En gros : mon serveur source a un processeur Intel, et ma destination un processeur AMD. Les deux processeurs ne sont pas compatibles pour cette opération. Jusqu'ici, mon Lab était constitué de matériel « Grand public peu couteux » à base d'AMD Turion et AMD Athlon x4. Je n'avais jamais rencontré cette situation. L'ajout d'un serveur utilisant un Intel Xeon a changé les choses. Dans un Lab, ce n'est pas grave.

Moralité : si vous voulez exploiter la migration Live ou la réplication, il faudra que vos serveurs utilisent des processeurs de même marque. Il vaut mieux le savoir avant de procéder à des achats qui pourraient s'avérer couteux ;)

Hello, pour ceux qui seraient de passage à Reims, sachez qu'il y a en ce moment, le Festival Clin d'Œil :

Le Festival Clin d'Œil est le seul évènement artistique mettant en avant toutes les facettes de la Culture Sourde. La 7ème édition s'étend sur 4 jours, du jeudi 2 au dimanche 5 juillet 2015 ! Le festival garde pour objectifs de promouvoir les artistes sourds et la culture sourde, de favoriser l'accès à la culture pour tous et de proposer un programme éducatif et artistique aux jeunes.

(Introduction visible sur le site du festival)

Pour plus d'informations, ça se passe par ici http://www.clin-doeil.eu/2015/

Ce post a pour vocation d'introduire une série d'articles sur l'accessibilité. Avant de partir plus en avant sur le « comment faire », je pense qu'il convient de savoir le « pourquoi ». Beaucoup de développeurs ont une vision très nébuleuse de ce qu'est l'accessibilité numérique et ce qu'il faut faire pour développer des applications accessibles.

Initialement, quand je pensais accessibilité, je visais trois axes :

Aide aux personnes à mobilité réduite exploitant un dispositif mécanique ou uniquement le clavier.

Aide aux personnes qui n'ont que l'ouïe pour se diriger. (Souvent associé à un clavier ou un dispositif mécanique)

Aide aux personnes qui ont des difficultés à voir temporairement qui ne voit pas du tout ou qui éprouvent rapidement une fatigue visuelle.

 

Au fil de mes expériences, cette vision de l'accessibilité a beaucoup évolué. Les premiers utilisateurs qui bénéficiaient des ajustements que je faisais étaient parfaitement valides. Ils n'avaient aucun handicap ni aucune difficulté à manipuler un PC, une tablette ou un téléphone. Pourtant ils étaient particulièrement friands de ces ajustements. Ceci m'a conduit à changer complètement ma manière de voir et de penser l'accessibilité.

Aujourd'hui, ma vision de l'accessibilité consiste à penser :  « par l'accessibilité on cherche à améliorer l'expérience de l'utilisateur ». On a trois axes principaux d'amélioration :

Saisie, touché, interactions.

Accompagnement, confirmation des actions, description de l'interface via l'audio.

Lisibilité, compréhension visuelle de l'interface.

 

Tout le monde est concerné. Potentiellement, toute application peut donc profiter de l'accessibilité et évoluer vers un produit de meilleure qualité.

 

Dans les prochains articles, je démontrai chaque type d'amélioration possible. Vous pourrez constater que les solutions sont simples, et les outils faciles d'accès. La plupart des outils étant déjà à notre disposition quand on installe Visual Studio.

Même si la plateforme VBA a plus de 20ans et qu’elle n’a pas bougé depuis, il n’en reste pas moins simple de manipuler des données de SQL Server à partir de macros VBA.

Premières choses :

  • Oubliez DAO. Utiliser ADO. Cela fait un paquet d’années qu’ADO à gagner le grand combat qui l’opposait à DAO. Je ne reviendrai pas sur ce sujet qui a fait couler beaucoup d’encre par le passé. Aujourd’hui si vous voulez une solution qui marche partout et sur un Office récent, c’est ADO.
  • Oubliez l’idée de « protéger » les chaines de caractères. (ex : il y a une simple cote, donc je dois en mettre deux…)
  • Oubliez l’idée de « coder » les caractères spéciaux. (ex : Office n’aimerait pas les accentuations, « à é è ç …»)

Ensuite, on ajoute une référence à ADO. Pensez à regarder si toutes les machines ciblées on le même Office et les mêmes composants ADO de déployer. Si ce n’est pas le cas, on peut toujours utiliser une version inférieure (2.8, 2.6…). Ou alors, on peut télécharger les derniers MDAC pour avoir un composant ADO récent.

ADO 6.1

 

Coter code, avec ADO, on peut utiliser des objets commande et paramètre. :

  • Dans la commande SQL, chaque paramètre est représenté par un point d’interrogation « ? »
  • Les paramètres doivent être ajoutés dans l’ordre de leur présence dans la commande SQL (les noms ne sont là que pour faire propre).
  • Les paramètres sont créés via l’objet commandes.
  • Les valeurs fournies à chaque paramètre doivent avoir un type défini. C’est ce qui fait qu’il n’y a pas besoin de torturer ses données avant de les utiliser avec SQL Server.
  • Les objets ADO, son tous dans un namespace ADODB. Si un type n’est pas préfixé par « ADODB. » il ne provient pas d’ADO (danger !)

Un code valant toujours mieux que de longues explications, voici un exemple d’update suivi d’un exemple de select (le résultat est manipulable avec les fameux Recordset et ses EOF,BOF,…).

 

Update

    ' -----------------------------------------------------------------------------------------
    ' Update de la table avec monText en fonction d’un Id
    ' -----------------------------------------------------------------------------------------
    Dim connection As New ADODB.connection
    Dim command As New ADODB.command
    
    ' Ouverture de la connexion
    connection.Open connectionString
    
    ' Préparation de la commande SQL
    command.ActiveConnection = connection
    command.CommandText = "UPDATE MaTable SET MonText =? WHERE Id=?"
    command.CommandType = adCmdText

    ' Ajout des paramètres dans l'ordre de la requète SQL
    command.Parameters.Append command.CreateParameter("MonText ", adLongVarChar, adParamInput, Len(monText), monText)
    command.Parameters.Append command.CreateParameter("Id", adChar, adParamInput, 12, id)
    
    ' Execution
    command.Execute
    
    ' Fermeture
    connection.Close

 

Select

    ' -----------------------------------------------------------------------------------------
    ' Lecture de monText en fonction d’un Id
    ' -----------------------------------------------------------------------------------------
    Dim connection As New ADODB.connection
    Dim command As New ADODB.command
    Dim recordset As ADODB.recordset
    Dim monText As String
    
    ' Ouverture de la connexion
    connection.Open connectionString
    
    ' Préparation de la commande SQL
    command.ActiveConnection = connection
    command.CommandText = "SELECT MonText FROM MaTable WHERE Id=?"
    command.CommandType = adCmdText

    ' Ajout des paramètres dans l'ordre de la requète SQL
    command.Parameters.Append command.CreateParameter("Id", adChar, adParamInput, 12, id)

    Set recordset = command.Execute()
    
    ' Lecture, sans tests de EOF et BOF pour vérifier qu'il y a un enregistrement
    monText = recordset("MonText").Value
    connection.Close

Juste un petit poste pour signaler que mon témoignage sur le travail d'architecte a été publié sur le Blog de l'association « Fier d'être développeur ».

Cela se passe par ici.

Par défaut WCF, permets de créer des services REST qui acceptent de fonctionner avec des corps de messages en JSon et en XML. La technologie est assez intelligente pour savoir qu’il faut répondre du XML à un client qui a formulé sa requête en XML et en JSon pour le client qui a communiqué du JSon.

Seul petit hic, par moment on aimerait prendre la main sur le processus et n’autoriser qu’un format d’échange. Si on tente de jouer sur les méthodes de nos services avec les attributs WebInvoke, on se retrouve avec une grosse masse de travail le jour où l’on veut changer d’approche. Et surtout, on ne peut pas être certain de vraiment forcer le service à répondre de la manière attendue (la configuration peut toujours prendre le dessus).

Pour forcer le format des messages, la solution se trouve donc dans la configuration :

<protocolMapping>
   <add scheme="http" binding="webHttpBinding" />
</protocolMapping>
    
<behaviors>
   <endpointBehaviors>
     <behavior>
       <webHttp defaultBodyStyle="WrappedRequest"
         defaultOutgoingResponseFormat="Json"
         automaticFormatSelectionEnabled="false" />    
     </behavior>
   </endpointBehaviors>
   <serviceBehaviors>
     <behavior>
       <serviceMetadata httpGetEnabled="false" httpsGetEnabled="false" />
       <serviceDebug includeExceptionDetailInFaults="false" />
     </behavior>
   </serviceBehaviors>
</behaviors>

 

Le choix de la réponse est interdit du fait du “false” dans “automaticFormatSelectionEnabled”. Le format du corps de la réponse est fixé par le “defaultOutgoingResponseFormat” qui apour valuer “Json”.

Seul petit hic. Si le client vous interroge en XML, la réponse JSON risque de déstabiliser votre navigateur qui n’acceptera peut-être pas le message ou qui vous ouvrira une boite de dialogue pour vous proposer d’enregistrer la réponse dans un fichier JSon. Heureusement, une solution existe : il faut modifier le ContentType de la réponse pour lui dire qu’il s’agit d’un text (text/plain). Le navigateur n’y verra que du feu et votre client pourra lire la réponse.

En général, les services qui seront concernés seront rares. Il s’agit souvent de services de gestion ou d’upload de fichier. Pour  ceux-ci, il suffit d’inclure le code suivant dans les méthodes du service :

 WebOperationContext.Current.OutgoingResponse.ContentType = "text/plain";

 

Bien sûr, si tous vos services sont concernés, il serait peut-être plus simple d’utiliser ce code dans un behavior WCF.

À ma grande surprise, nombre de développeurs MVC ne savent pas comment utiliser facilement une seule avec plusieurs verbes. Certain coderons une méthode par verbe, d’autres coderont un attribut custom.

Dans la pratique, la solution est bien simple. HttpVerbs étant une énumération, on peut très bien utiliser un OU pour les cumuler. Par exemple, pour un controller de Login qui doit accepter du GET et du POST, cela donne :

[AcceptVerbs(HttpVerbs.Post | HttpVerbs.Get)]
 public ActionResult Index(string login, string password)
{
   // ...
}

Rien de bien sorcier ;)

De base, WCF fournit toute l’infrastructure pour monter des solutions de services multiprotocoles. On peut fournir et consommer des services sur des carneaux divers et variés. Avant .net 4, fournir un même service pour deux Binding différents imposait une configuration très verbeuse (peut-être un peu trop). Après .net 4, et l’introduction des configurations à défaut, la configuration est devenue beaucoup plus facile.

Pour rappel: la configuration à défaut consiste à introduire des nœuds de configuration WCF (binding, beavior,.. etc…) sans propriété name ou alors avec la propriété name=””.

Seul petit hic, tous les développeurs n’ont pas forcément saisi que la pierre angulaire de tout cela résidait dans le mapping des protocoles. Sans ce mapping, WCF ne peut pas savoir que vous voulez utiliser tel ou tel type de Binding.

Avant toute configuration, si vous souhaitez utiliser les configurations à défaut il faut donc fixer le Binding utiliser pour chaque protocole.

La MSDN nous donne un exemple simple de configuration (https://msdn.microsoft.com/en-us/library/ee816881(v=vs.110).aspx)

<protocolMapping>
   <add scheme="http" binding="basicHttpBinding"/>
   <add scheme="net.tcp" binding="netTcpBinding"/>
   <add scheme="net.pipe" binding="netNamedPipeBinding"/>
   <add scheme="net.msmq" binding="netMsmqBinding"/>
</protocolMapping>

 

Cet exemple est simple, et s’utile pour les cas les plus faciles. Dans la pratique, dès que l’on veut mixer http et https, les choses sont un peu plus complexes.

Par exemple, la configuration suivante n’est pas possible :

<protocolMapping>
   <clear/>
   <!-- Binding utilisé par le HTTPS -->
   <add scheme="https" binding="webHttpBinding"/>
   <!-- Binding utilisé par le HTTP -->
   <add scheme="http" binding="webHttpBinding"/>
</protocolMapping>

 

Pourquoi?

La réponse se trouve dans les configurations des Binding. On ne peut pas avoir un deux configurations de Binding à défaut pour un même type de Binding. Ceci est tout à fait normal, comment le system peut savoir quelle configuration utiliser, si aucune n’a de nom? Dans ce genre de situation, j’ai souvent vu des développeurs choisir d’utiliser un type de Binding pour HTTP et un autre type pour HTTPS ou alors coder leur propre type de Binding.

Heureusement, WCF est bien plus simple qu’il n’y parait, et il suffit de donner un nom à ses différentes configurations. Les noms peuvent ensuite être affectés comme bindingConfiguration de chaque protocole.

Ce qui donne au final ceci :

<system.serviceModel>
  <protocolMapping>
    <clear/>
    <add scheme="https" binding="webHttpBinding" bindingConfiguration="httpsConfiguration"/>
    <add scheme="http" binding="webHttpBinding" bindingConfiguration="httpConfiguration"/>
  </protocolMapping>
    
  <bindings>
    <webHttpBinding>
      <clear/>
      <binding name="httpsConfiguration">
        <security mode="Transport"/>
      </binding>
      <binding name="httpConfiguration">
        <security mode="None"/>
      </binding>
    </webHttpBinding>
  </bindings>
    
  <behaviors>
    <serviceBehaviors>
      <clear/>
      <behavior>
        <!-- Suppression de meta-->
        <serviceMetadata httpsGetEnabled="false" httpGetEnabled="false"/>
        <serviceDebug includeExceptionDetailInFaults="false"/>
      </behavior>
    </serviceBehaviors>
    <endpointBehaviors>
      <clear/>
      <behavior>
        <!-- Configuration REST -->
        <webHttp defaultBodyStyle="Bare" defaultOutgoingResponseFormat="Json"/>
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

 

Facile non?

Souvent, on me dit que WCF est compliqué à utiliser, à configurer, et qu’il faut toujours du code custom pour que cela marche. Connaissant bien la plateforme, j’aime que l’on me présente un cas concret quand on a ce genre de propos. À force de décortique ces cas, je me suis rendu compte que ce qui clochait le plus souvent était la configuration. Les possibilités de WCF étant parfois mal comprises, les développeurs configurent mal leurs services ou compensent avec du code personnel. Dans la plupart des cas, ce code ne fait que reproduire la configuration WCF en dure. Dans d’autres cas, ce code introduit des beahaviors ou des binding qui existent déjà.

La base de tout cela reste donc la connaissance de la configuration WCF. Entre celle-ci et IIS, les développeurs ont parfois du mal (voir mon précédent article sur IIS). Pour éviter tout écueil, je conseille de partir d’une configuration de base clean. Son objectif est de s’assurer que l’on n’hérite pas d’une autre configuration (via la topologie de IIS, et des applications qui seront en production sur le serveur).

On doit donc faire systématiques un clear des éléments de configuration suivant :

  • protocolMapping
  • serviceBehaviors
  • endpointBehaviors

Ce qui donne comme configuration de base ceci :

<system.serviceModel>
  <protocolMapping>
    <clear/>
  </protocolMapping>    
  <behaviors>
    <serviceBehaviors>
      <clear/>
    </serviceBehaviors>
    <endpointBehaviors>
      <clear/>
    </endpointBehaviors>
  </behaviors>
</system.serviceModel>

 

Si par exemple on reprend une configuration à la mode comme un REST, on a donc au final ceci :

<system.serviceModel>
  <protocolMapping>
    <clear/>
    <!-- Binding utilisé par le HTTPS -->
    <add scheme="https" binding="webHttpBinding"/>
  </protocolMapping>
    
  <bindings>
    <webHttpBinding>
      <clear/>
      <binding>
        <!-- Ajout du SSL -->
        <security mode="Transport"/>
      </binding>
    </webHttpBinding>
  </bindings>
    
  <behaviors>
    <serviceBehaviors>
      <clear/>
      <behavior>
        <!-- Suppression de meta-->
        <serviceMetadata httpsGetEnabled="false"/>
        <serviceDebug includeExceptionDetailInFaults="false"/>
      </behavior>
    </serviceBehaviors>
    <endpointBehaviors>
      <clear/>
      <behavior>
        <!-- Configuration REST -->
        <webHttp defaultBodyStyle="Bare" defaultOutgoingResponseFormat="Json"/>
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

Cela fera déjà quelques années que l'on se pose des questions sur l'avenir de l'AppFabric. L'AppFabric n'avait presque pas évolué entre ses versions 1.0 et 1.1. Il y a quelques mois, l'AppFabric 1.1 était annoncée comme compatible avec Windows 2012 R2. Mais aucune nouvelle version n'était publiée.

Depuis le 3 avril dernier, la situation est enfin claire : fin de support le 2 avril 2016 ( Microsoft AppFabric 1.1 for Windows Server Ends Support 4/2/2016 ).

Workflow Foundation et WCF vont souffrir de la disparition de ce produit qui leur apportait dans de facilités. Comme le dit si bien l'équipe AppFrabric sur son blog, il a y des solutions de remplacement possibles pour le Cache, le Hosting. Pour le monitoring et la gestion des services, il faudra monter ses propres solutions. Ayant déjà monté ce type de solution pour des projets personnels, je ne me fais pas de soucis, on peut y arriver sans monter une usine à gaz.

Étrangement, c'est au sujet des solutions de cache que je tiens à mettre en garde les utilisateurs d'AppFabric (ou d'autres produits). Avec les temps, je me suis rendu compte que l'AppFabric n'était pas toujours utilisée à bon escient. Son service de cache avait pour vocation première de fournir un cache distribué entre les serveurs IIS d'une ferme. Avec un seul serveur, le cache était souvent contre performant.

 

Demain, si vous devez choisir une nouvelle solution de cache, regardez de plus près votre besoin :

 

Cache partagé : Vous devez charger des objets et fournir un cache de ceux-ci qui soit synchro pour tous vos IIS

Redis est prometteur. Cependant sa dernière version n'est pas encore supportée par Windows Server, et toutes les fonctionnalités n'y sont pas encore (mais ça va venir).

Les puristes seront tentés d'utiliser la version Linux. Attention, à ne pas être dans la contreperformance. Le cache n'étant plus disponible localement sur votre serveur IIS, il devra passer par le réseau. Il faudrait mieux vérifier que le jeu en vaut bien la chandelle avant de se lancer. Pour les futurs projet .net Core, il est peut-être un peu trop tôt pour se faire un avis.

 

Cache applicatif non partagé : Vous devez charger des objets uniquement pour le serveur local

La simple classe Cache de System.Web.Caching peut certainement faire l'affaire.

https://msdn.microsoft.com/fr-fr/library/6hbbsfk6(v=vs.100).aspx

 

Cache de pages web dynamique : Vous devez mettre en cache des pages ASP .net

Que vous soyez sur du WebForm ou sur du MVC, ASP .net a tout l'outillage pour répondre à votre besoin (sans rien ajouter). De plus, rien ne vous empêche d'utiliser les bonnes vielles entêtes http et metas pour demander à vos clients d'utiliser le cache de leurs navigateurs.

https://msdn.microsoft.com/fr-fr/library/06bh14hk(v=vs.100).aspx

https://technet.microsoft.com/en-us/library/dd239248(WS.10).aspx

 

Cache de pages web ou contenu statique : Vous devez mettre en cache des pages HTML, des fichiers ou des images

IIS étant votre ami, il dispose déjà de tout ce dont il faut pour gérer un cache des contenus qu'il sert (statique comme dynamique). Cela se trouve ici :

https://technet.microsoft.com/en-us/library/cc732475(v=ws.10).aspx

Ce poste est destiné à couper court à une rumeur qui a la peau dure: WCF ne serait pas en mesure d’utiliser SSL et api REST en même temps???

Ceci est totalement faux. WCF peut faire du REST sur du SSL.

Pour y arriver, il suffit de mettre en place sa configuration REST habituelle. La seule partie qui change se trouve au niveau du transport du Binding qui devient sécurisé.

Exemple:

<system.serviceModel>
  <protocolMapping>
    <clear/>
    <!-- Binding utilisé par le HTTPS -->
    <add scheme="https" binding="webHttpBinding"/>
  </protocolMapping>
    
  <bindings>
    <webHttpBinding>
      <binding>
        <!-- Ajout du SSL -->
        <security mode="Transport"/>
      </binding>
    </webHttpBinding>
  </bindings>
    
  <behaviors>
    <serviceBehaviors>
      <behavior>
        <!-- Suppression des meta-->
        <serviceMetadata httpsGetEnabled="false"/>
        <serviceDebug includeExceptionDetailInFaults="false"/>
      </behavior>
    </serviceBehaviors>
    <endpointBehaviors>
      <behavior>
        <!-- Configuration REST -->
        <webHttp defaultBodyStyle="Bare" defaultOutgoingResponseFormat="Json"/>
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

De base, la politique de validation utilisée dans .net fait bien son travail. Elle nous prémunit de toute mauvaise utilisation d'un certificat (objet non valide, certificat d'une autorité non reconnue … etc…)

Dans certains cas, vous pouvez vouloir ajouter des règles ou en supprimer. Pour arriver à vos fins, il suffit de modifier la propriété ServerCertificateValidationCallback de l'objet ServicePointManager. Cette propriété attend une fonction aux multiples arguments, qui doit retourner un Boolean à True quand on accepte un certificat. Les arguments nous permettent de savoir quel certificat est à valider ainsi que son contenu.

Ceci est utilisable avec toute technologie .net qui exploite un certificat : WCF, ASMX, Workflow foundation… etc.

Par exemple, si on veut accepter tout type de certificat comme les certificats auto signés, on peut utiliser le code suivant.

// Faire confiance au certificat quoi qu'il arrive et d'où qu'il vienne !!! 
ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) => 
{
    return true;
};

Note : Code tellement moche et dangereux, qu'il ne faut pas utiliser en production ;)

Plus d'informations sont disponibles via la MSDN https://msdn.microsoft.com/fr-fr/library/vstudio/system.net.security.remotecertificatevalidationcallback(v=vs.100).aspx

Pour la publication en production, il est conseillé de passer toutes les options un peu trop bavardes de WCF à False. Personnellement, j'aurai tendance à être plus radical. Je supprime donc les behaviors liés aux métas et au debug. Dans le cas où j'utilise les fonctionnalités de configuration par défaut de WCF 4, je peux donc profiter du fichier web.config de Release pour supprimer toutes les configurations indésirables en une seule opération :

Mon fichier Web.Release.config a donc la forme suivante :

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
   <system.web>
      <compilation xdt:Transform="RemoveAttributes(debug)" /> 
   </system.web> 
   <system.serviceModel> 
      <behaviors> 
         <serviceBehaviors> 
            <behavior> 
               <serviceMetadata xdt:Transform="Remove" /> 
               <serviceDebug xdt:Transform="Remove" /> 
            </behavior> 
         </serviceBehaviors> 
      </behaviors> 
   </system.serviceModel> 
</configuration> 

 

Pour la recette, je veux avoir le détail des erreurs, mon fichier Web.Release.config a donc la forme suivante :

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
   <system.web>
      <compilation xdt:Transform="RemoveAttributes(debug)" /> 
   </system.web> 
   <system.serviceModel> 
      <behaviors> 
         <serviceBehaviors> 
            <behavior> 
               <serviceMetadata xdt:Transform="Remove" /> 
               <serviceDebug ptionDetailInFaults="true" /> 
            </behavior> 
         </serviceBehaviors> 
      </behaviors> 
   </system.serviceModel> 
</configuration>

Faire un site web, c'est bien. Le déployer, c'est mieux…

Malheureusement, trop peu de développeurs font attention au déploiement. Ce qui fait qu'ils ne sont pas habitués à diagnostiquer une installation ratée ou à identifier une topologie dangereuse. Via ce court article, je me propose de faire un rappel sur la gestion des fichiers de configuration.

On oublie bien vite, qu'une application web ne dépend pas que d'un seul fichier de configuration.

 

Configuration dans l'application

Les fichiers web.config font partie intégrante de votre application. Vous pouvez en avoir plusieurs. En général, on a un fichier principal et des fichiers secondaires que l'on dépose dans les répertoires où l'on souhaite ajouter ou retirer des paramètres (typiquement, la gestion de droits sur un dossier).

Exemple type :

Chaque dossier a son fichier web.config. Les fichiers dans Admin et Services ajoutent ou retirent des paramètres et héritent des paramètres définis dans le fichier de configuration à la racine de la configuration. Cette partie étant fournie avec votre code, en général, il n'y a pas de problèmes.

 

Configuration liée au serveur IIS

La configuration IIS est stockée dans le fichier applicationHost.config que l'on peut trouver ici : «  %windir%\system32\inetsrv\config\ ». Celle-ci peut avoir un impact direct sur votre applicatif. Malheureusement, elle diffère d'un OS à l'autre.

Si vous utilisez un OS client (Vista, Windows 7, Windows 8, Windows 10), la configuration sera peut-être différente de l'OS serveur que vous utiliserez en production (2008, 2008R2, 2012, 2012R2). Par prudence, il vaut donc mieux faire ses recettes sur un vrai serveur que sur un poste client.

À noter que :

  • certains paramètres fixés peuvent être verrouillés pour vous interdire de les modifier dans vos fichiers web.config. Il est donc bon de connaitre ces verrous (Certains verrous peuvent sauter si on vide les collections via <clear/> et qu'on les repeuple à la main dans son fichier web.config avec des <add>)
  • certains paramètres verrouillés sur un OS client, ne le sont pas sur un OS serveur (ex : authentification anonyme déverrouillée sur 2008R2 et verrouillée sur Windows 7)
  • certains paramètres n'existent pas dans IIS Express, il est donc bon d'utiliser un IIS complet pour développeur.

     

Configuration liée au pool

Le choix du pool a un impact direct sur la configuration. Il y a trois notions à retenir :

1. Pour chaque plateforme x64, x86, il y a un fichier de configuration

Par défaut, notre pool fonctionne en 64 bits. Si on l'autorise à fonctionner en 32, il ne fera plus que du 32 bits.

  • Le fichier de configuration 64bits se trouve dans le dossier « %windir%\Microsoft.NET\Framework64 ».
  • Le fichier de configuration 32bits se trouve dans le dossier « %windir%\Microsoft.NET\Framework ».

     

2. Pour chaque CLR .net, il y a un fichier de configuration

Dans chaque dossier lié à une plateforme, il y a un dossier par CLR déployée. Dans ce dossier se trouve un dossier « config » contenant les configurations.

Exemple pour un pool 64 bits et une CLR4 (c'est le cas par défaut sur les serveurs récents)

%windir%\Microsoft.NET\Framework64\v4.0.30319\Config

 

3. La gestion du pipeline intégré ou non, a un impact sur les sections utilisables dans vos fichiers de configuration

Avant II7, la notion de pipeline intégré n'existait pas. Il s'agit d'une évolution de IIS qui nous permet d'utiliser nos applications dans un pipeline full .net (au revoir ISAPI) et d'utiliser nos modules .net pour des éléments qui n'étaient pas couverts (exemple : contenu statique).

Avec cette option, un certain nombre de configurations sont déportées dans la section system.webServer. Si vous utiliser httpModules, httpHandler, dans vos fichiers de configurations, ils ne seront pas pris en comptes. Il faudra les remplacer par leurs équivalents dans system.webServer.

Ex : https://msdn.microsoft.com/fr-fr/library/bb763179(v=vs.100).aspx

 

Imbrication d'applications

Un site peut contenir plusieurs applications. Les applications héritent de la configuration de l'application qui est à leur racine. Cette situation est extrêmement courante. Par exemple, TFS utilise ce type d'implantation pour fonctionner.

Exemple :

Certaines sections de la configuration de l'application racine peuvent ne pas être compatibles avec les applications App1 et App2. Si vous avez pour responsabilité de gérer App1 ou App2, il faudra dans la mesure du possible connaitre la configuration se trouvant à la racine du site.

Si ce n'est pas possible, il faut être prudent et utiliser autant que possible <clear/> et <remove/> dans vos collections de paramètres. En supprimant systématiquement les paramètres dont vous n'avez pas besoin, vous vous prémunissez de leurs éventuels effets de bords.

 

Imbrication d'applications et de pools

Avec l'imbrication d'applications, on peut aussi se retrouver à imbriquer des pools. On peut donc imbriquer des CLR, et des plateformes 32/64 bits différentes !…

Courage fuyons !

Cette situation est à éviter autant que possible, car on peut conjuguer une multitude de configurations qui ne sont peut-être pas compatibles (exemple : sections qui n'existent pas en .net 2 car elles proviennent de .net 4).

Si vous n'avez pas le choix, et que vous devez effectuer ce genre de déploiement, il faudra utiliser des sections <location>. En utilisant <location> dans le fichier de configuration à la racine du site (et non pas de vos propres applications), vous pourrez créer des zones d'exceptions et ainsi ne pas propager la configuration du site racine aux applications imbriquées.

 

Bons déploiements ;)

Dernièrement, j'ai été confronté à un problème embarrassant : Je ne pouvais plus redimensionner le disque système de l'un de mes serveurs Core.

Il était aussi impossible de défragmenter les données et le Trim ne faisait rien  L . La recherche d'erreur ne trouvait rien.

En cherchant à savoir si je n'avais pas des fichiers trop fragmenté, je suis tombé sur un fichier de log qui était découpé en quelques millions de fragments… Il s'agissait du log de DISM.

Après clean up de DISM, tout est redevenu normal ;)

Moralité : même sur un SSD, surveiller la fragmentation ne peut pas faire de mal. Cela peut même permettre de trouver des problèmes.

N'étant pas un professionnel et l'orthographe, j'ai toujours pris l'habitude de localiser mes applications. J'ai très vite trouvé mon intérêt dans le fait d'avoir un seul endroit où trouver tous les textes à corriger.

Cela m'a aussi forcé à ne rien mettre en dure dans le code et à toujours en extraire ce qui était localisable. Ceci m'a évité nombre d'erreurs. Vous comprendrez donc que je m'énerve quand je tombe sur un programme qui me parle dans ma langue et qui me prose de répondre dans une autre :

Je crois que la capture parle d'elle-même. Je me suis bien énervé sur le « O » de oui, avant de taper le « Y » de yes.

Amis développeurs, s'il vous plait retenez cet exemple comme étant une erreur à ne pas reproduire.

Si au passage, vous pouviez faire attention à l'encodage des textes, ce serait top ;)

Merci

 

PS : En plus c'était pour désinstaller un produit…. Arg !!!!

Vous cherchez les mises à jour pour Test Professional, mais vous ne les trouvez pas ? C'est normal, il n'y en a pas. Ou du moins, il n'y a pas de package de mise à jour propre à ce produit. Celui-ci dépendant de Visual Studio, il faut utiliser l'iso des updates de Visual Studio. Ceci métra à jour vos clients TFS, comme les compléments Office.

Capture de l'Update 3

En faisant le ménage dans mes captures d'écran, je suis tombé sur cette petite perle qui m'avait fait sourire : c'est une boite de dialogue qui s'affiche après la création d'un projet d'équipe via le site web de Visual Studio Online.

 

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- SharePoint 2013 : Erreur lors du chargement de document Office via Office Web Apps par Blog Technique de Romelard Fabrice le il y a 9 heures et 58 minutes

- [Office 365] Administrer SharePoint Online en Powershell par Blog Technique de Romelard Fabrice le 08-28-2015, 16:49

- Mes features favorite d’Hyper-V sur Windows 10 par Blog de Jérémy Jeanson le 08-26-2015, 14:03

- Simplification du processus de déploiement de NanoServer par Blog de Jérémy Jeanson le 08-24-2015, 15:54

- Evènements en français lors des prochains mois… par Le blog de Patrick [MVP Office 365] le 08-24-2015, 15:27

- [Hyper-V] Live migration impossible entre hôtes Intel et AMD par Blog de Jérémy Jeanson le 08-21-2015, 19:19

- SP2013 VM install : pénible erreur de Microsoft Setup Bootstrapper par The Mit's Blog le 08-20-2015, 11:43

- Premiers pas avec AkkaDotNet par Fathi Bellahcene le 08-18-2015, 10:36

- La feuille de route NON-OFFICIELLE d’Office 365 – De MS Ignite 2015 à MS Ignite 2016 par Le blog de Patrick [MVP Office 365] le 07-23-2015, 14:04

- 24 heures de conférence en ligne #Collab365 ! par Le blog de Patrick [MVP Office 365] le 07-21-2015, 18:12