Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

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 includeExceptionDetailInFaults="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.

 

 

Bonne année et bon code pour 2015.

Je vous souhaite un bon Visual Studio 2015 tout neuf et tous les beaux produits qui vont avec !

Aujourd'hui, je m'attaque à un fleau bien connu du monde TFS : l'utilisation d'une édition SQL Enterprise qui empêche de migrer son TFS vers une édition inférieure (type Standard ou Express).

Tout administrateur TFS, le sait, la solution est simple. Il suffit de supprimer les features Enterprise activées sur les bases de données à migrer. En soit, rien de compliquer. Par contre quand il faut l'appliquer à une un gros volume de collections... cela devient vite rébarbatif.

Pour faciliter la chose, j'ai réalisé un script SQL bien pratique :

-- Déclarations
declare 
 @DataBase sysname

-- Crusor pour aller chercher les bases de données
declare databases_cursor cursor for
select db.name
from sys.databases as db
where db.name like 'tfs_%';

open databases_cursor

-- Passer à la base suivante
fetch next from databases_cursor into @DataBase

while @@FETCH_STATUS=0
begin
    -- Changement de propriétaire
	exec('exec [' + @DataBase + '].dbo.prc_EnablePrefixCompression @online = 0, @disable = 1');

	-- Passer à la base suivante
	fetch next from databases_cursor into @DataBase
end

close databases_cursor
deallocate databases_cursor

 

Note, en plus d'empêcher la migration, si l'édition SQL Server est inapproprié, car induisant des features superflues, on peut contacté un usage de la RAM plus important que ce qu’il devrait être.

Exemple constaté : TFS 2013, SQL 2012, une trentaine de collections, 2 CPU, 4 Gb RAM. Après suppression de la compression, le serveur utilise 11% de RAM en moins et les performances pour les utilsaiteurs sont restées identiques.

Voilà, bonnes migrations ;)

Mauvaise surprise pour les utilisateurs de Windows Technical preview sur Windows To Go : Les upgrades de builds ne sont pas possibles.

J'ai testé avec les toutes les builds disponibles à ce jour, et aucune ne permet l'upgrade.

Voici le message obtenu :

Note : Windows Update reste fonctionnel.

Grand fan de Windows To Go, je me suis lancé dans la préparation d'un disque externe avec Windows 10. Dans un élan de folie, j'ai voulu tenter l'opération à partir de mon Windows 8.1 Enterprise.

Bonne surprise, ça marche. Cela fait maintenant une semaine que j'utilise la Technical Preview Enterprise à partir d'un support Windows To Go.

Le déploiement a suivi les étapes classiques d'une installation Windows To Go à partir d'un PC Windows 8.1.

Il faut ouvrir son panneau de configuration. Utiliser le raccourci Windows To Go.

 

On sélectionne sa clé USB ou son disque externe.

 

On ajoute le chemin vers le disque (ici, j'ai monté l'iso sur F:\)

 

On fait suivant (hors mis si on veut tester BitLocker)

 

Et c'est parti

 

Ensuite il faut patienter

 

La dernière boite de dialogue propose de rebooter. On peut la fermer sans apporter de modification a sa machine et utiliser le disque.

 

Testé et approuvé ;)

Aujourd'hui, je vous propose un petit tour d'horizon des possibilités offertes par IIS et .net pour personnaliser ses pages d'erreurs.

Première chose à assimiler, il ne faut pas confondre les pages d'erreurs de nos applications .net et les pages d'erreur IIS :

  • La première catégorie sert principalement à afficher les erreurs internes à nos applications (exceptions diverses)
  • La seconde catégorie contient toutes les erreurs clients et applicatifs IIS qui peuvent être utilisée par des applications autres qu'ASP .net (erreurs 400-500 type : page introuvable, site indisponible, accès refusé …)

La première catégorie d'erreur se gère assez facilement via la section customErros du fichier web.config. Il n'y a pas grand-chose à dire. Vous pouvez gérer les erreurs dans vos applications web, et choisir sur quel client on veut ou non afficher les erreurs en détail. Dans certains cas, vous risquez d'être en grosse galère, car les pages d'erreur IIS peuvent prendre le dessus sur vos pages d'erreurs ASP.net. Un développeur .net doit donc avoir connaissance des possibilités offertes par la personnalisation des pages d'erreur IIS.

La seconde est bien plus intéressante car elle offre des possibilités de personnalisations aux hébergeurs et administrateurs système. Ceci de manière uniforme quelle que soit la technologie utilisée. Certes les pages ainsi personnalisées sont en général statiques (pour éviter de donner trop d'informations aux utilisateurs finaux), mais au moins elles sont chartes aux couleurs de la société.

Pour ceux qui n'auraient jamais fait attention, voici une capture du panneau IIS qui met en avant les deux zones de configurations :

 

Pour présenter correctement la chose, j'ai choisi d'utiliser le plan suivant :

  1. Activité les erreurs personnalisées IIS
  2. Scope de la configuration des pages d'erreurs
  3. Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs
  4. Possibilité 2 : Embarquer les pages dans son site
  5. Possibilité 3 : Hébergement sur un serveur dédié

Ma volonté étant de vulgariser les pages d'erreurs IIS pour les développeurs .net, j'omettrai volontairement un certain nombre de détails. Je n'aborderai donc pas des notions comme :

  • Les pages détaillées
  • Les redirections/réécritures de pages
  • La possibilité absolument diabolique d'empêcher les développeurs de personnaliser les pages d'erreurs (c'est méchant ça !)

Attaquons donc dans le vif !

 

1. Activité les erreurs personnalisées IIS

En soit, l'activation des pages personnalisées n'a rien de bien compliquer. Sur un poste client, il suffit d'aller dans le panneau de configuration t d'ajouter une fonctionnalité Windows.

Ici sur un Windows 8.1 en français : « Erreurs http » 

 

Sur un serveur, il faut ajouter une fonctionnalité au rôle IIS. Ici sur un Windows 2012 R2 qui a déjà cette fonctionnalité activé : « Erreurs HTTP (Installé) » 

Aucun reboot n'est utile.

 

2. Scope de la configuration des pages d'erreurs

La configuration des pages d'erreurs étant enregistrée dans un fichier *.config section system.webServer (nœud httpErrors). Voici ce à quoi ressemble la configuration par défaut :

Il est possible de la modifier à différents endroits :

  • applicationHost.config
  • web.config

Bien entendu, machine.config ne fait pas parti des possibilités envisageables. Imaginez une page d'erreur qui change en fonction de la CLR ou de la plateforme ciblée (32 ou 64bits). Ce serait un cauchemar !

 

En fonction de l'endroit où l'on configure la section system.webServer, il est donc possible de personnaliser les erreurs pour :

  • Tous les sites d'un même serveur (applicationHost.config)
  • Un site (web.config)
  • Une application (web.config)
  • Un répertoire virtuel ou non (web.config)

La configuration peut donc être très souple. Via la console IIS, on dispose même d'une interface très pratique. Celle-ci permet de changer une page d'erreur existante et d'ajouter/supprimer des erreurs.

 

Le formulaire de configuration d'une erreur reste simple, à condition de comprendre les trois possibilités de personnalisation offertes par IIS.

 

3. Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs

La première possibilité offerte consiste dans l'usage de pages statiques stockées sur le serveur. Il s'agit de la configuration par défaut de IIS. Les fichiers sont stockés dans le répertoire « %SystemDrive%\inetpub\custerr\ » (donc bien souvent dans C:\ inetpub\custerr\).

Si vous le souhaitez, vous pouvez choisir d'utiliser des pages qui diffèrent en fonction de la langue de l'utilisateur (pages localisées). Pour cela, il suffit de créer un répertoire par langue. Exemple : ici le français (fr-FR)

 

Lors de la saisie, si la case «Essayer de retourner le fichier d'erreur dans le langage client » est cochée, le bouton définir est disponible. Il permet d'accéder au formulaire suivant :

Dans le cas où cette case n'est pas cochée, vous ne pourrez pas avoir de pages d'erreurs localisées. Il faudra donc donner le lien complet vers la page d'erreur.

Voici par exemple, la configuration obtenue en personnalisant uniquement deux pages (401 localisée et 403 non localisée)

Notes :

  • errorMode doit être défini sur Custom pour que votre configuration soit prise en compte
  • On peut utiliser un noeaud <clear/> si on veut supprimer les autres pages.

 

4. Possibilité 2 : Embarquer les pages dans son site

Il s'agit là de l'approche préférée des développeurs. Les pages font partie du site. On peut en profiter pour avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).

 

5. Possibilité 3 : Hébergement sur un serveur dédié

Cette approche est très pratique dans le cas d'une ferme IIS. Les fichiers n'ont pas besoin d'être répliqués sur l'ensemble des serveurs de la ferme. Cette approche comme la précédente permet d'avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).

 

Voilà, j'espère que cet article vous donnera envie de considérer cette possibilité de personnalisation de IIS.

Aujourd'hui je suis toujours surpris pas la complexité mise en place pour sécurisées des informations (bases de données, partages de fichiers, FTP…). Pour une même application, il y a les développeurs qui vont stocker 50 comptes qui ne sont utilisés que par l'application (ou le groupe d'applications qu'ils gèrent). Pour ne pas distribuer les mots de passe sur les serveurs, ou les pc clients, on se retrouve souvent avec trois solutions qui parfois se complètent:

  • Le stockage de logins, mots de passe cryptés (dans l'application ou le fichier de configuration).
  • L'utilisation d'un API tiers de sécurité pour stocker logins et mots de passe (parfois avec un mot de passe ou token d'accès qui lui n'est pas sécurisé)
  • L'impersonation pour que le processus s'exécute avec des droits d'un autre utilisateur.

Il y a peut-être d'autres solutions que je n'ai pas croisées.

Dans tous les cas, on finira systématiquement avec un problème : « il y aura toujours un mot de passe qu'une personne devra conserver », ou « une personne qui aura accès à l'information sans restriction ».

Exemples absurdes, car l'utilisateur aura accès quoi qu'il soit décidé :

  • Ne pas vouloir donner accès à un site SharePoint alors que l'utilisateur est administrateur de la collection contenant le site.
  • Ne pas vouloir donner accès à un partage alors que l'utilisateur gère aussi le compte qui sert au backup de ce dossier (donc un compte qui lui aura accès quoi qu'il arrive)
  • … etc ….

Chacun a connu dans sa carrière l'une de ses situations absurdes. Je sais d'expérience qu'il y a des personnes qui préfèrent ne pas expliquer la situation : « c'est sécure ! ». Personnellement, j'ai toujours bataillé pour que la situation soit claire. Il n'y a pas de sécurité dans l'opacité.

La solution simple :

1. L'humain :

Ne pas prendre un responsable de votre société, car dans la plupart des cas, ils ne sont pas formés à la sécurité et risquent de compromettre l'information.

Exemple typique de ce type d'utilisateur :

  • Téléphone sans verrouillage d'accès posé sur une table.
  • PC laissé session ouverte lors de la pause pipi.
  • Lien vers les mots de passe sur le bureau Windows.
  • … etc…

Mettre en avant une personne « administrateur système » ou un « administrateur applicatif ». Cette personne a l'accès complet à l'outil et la sécurité fait partie de son métier. S'il faut conserver un mot de passe, c'est lui qui doit le faire.

 

2.  Le technique simple

La quasi-totalité des applicatifs peut utiliser une authentification Windows (aussi appelée authentification intégrée sur certaines applications comme SQL Server). Ce qui permet aussi la centraliser la gestion des comptes dans l'Active Directory. Notre administrateur aillant accès à l'AD, il pourra immédiatement couper un compte si besoin. Ceci est très pratique dans le cas d'applications compromises, ou changer le mot de passe rapidement.

A partir du moment où l'on utilise ce mode d'authentification, il n'est plus utile de stocker des chaines de connexion avec mot de passe dans l'applicatif ou le fichier de configuration. Ni même de stocker un mot de passe. Le ou les processus lancés se feront avec les droits de l'utilisateur qui a lancé le processus.

Pour chaque type d'application, il y a une solution simple qui s'appuie sur un compte Windows:

  • Application Windows classique : Le compte d'ouverture de session est utilisé
  • Site Web : Le compte du pool IIS est utilisé.
  • Planificateur de tâche : On peut déterminer un compte lors de la mise en place
  • Service Windows : On peut déterminer un compte lors de la mise en place
  • SharePoint : On a une liste de compte géré.

Note : On peut faire encore plus simple si l'on n'a pas besoin d'accéder aux ressources d'autres machines. On peut utiliser un compte système (ou un compte intégré à IIS par exemple)

 

3. Le technique un peu plus évolué

Si l'authentification Windows n'est pas disponible et qu'il faut sécuriser des données, on stocke les données cryptées dans un fichier de configuration. Mais avant de crypter les données, il faut commencer par extraire les clés machines qui serviront au cryptage.

Sans ces clés, votre fichier ne pourra pas être déployé hors de la machine qui a servi au cryptage. Ceci est très important pour une ferme IIS, ou pour un plan de reprise d'activité (PRA). Il s'agit là d'une erreur qui est malheureusement trop courante.

Il y a une documentation très claire que l'on peut trouver ici : http://msdn.microsoft.com/en-us/library/ff650304.aspx

Cette page date un peu, mais son contenu reste valable. Vous y trouverez le nécessaire pour sécuriser vos fichiers de configuration de manière fiable et portable.

 

Voilà. Vu que sécurité rime avec simplicité, j'espère que ces petites vous seront utiles et vous faciliterons la tâche.

Après avoir lu avec beaucoup d'attention l'annonce de S. Somasegar, j'ai été surpris de ne pas trouver de lien direct vers l'ISO de Visual Studio 2015.

Ce matin, une recherche sur Bing ou Google ne donnait pas grand-chose. Ce soir la donne a un peu changé et on peut enfin trouver facilement le lien vers la preview ici :

http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs

Petit avertissement pour les plus distraits : c'est le second lien qu'il faut utiliser pour obtenir l'ISO complète. Le premier pointe vers l'installer web.

Bons tests ;)

Un petit bug existe sur le package Oracle Database Client (12.1.0.2.0) for Microsoft Windows (32-bit) qui se trouve sur la page de téléchargement suivante : http://www.oracle.com/technetwork/database/enterprise-edition/downloads/database12c-win64-download-2297732.html

Le fichier oranfsodm12.dll est manquant, ce qui empêche l'utilisation de SQL*Loader.

En recherchant dans la documentation, on découvre qu'il s'agit d'une version modifiée de la librairie oraodm.

https://docs.oracle.com/database/121/NTDBI/postcfg.htm

 

En copiant oraodm12.dll et en la renommant oranfsodm12.dll on obtient une dll de remplacement utilisable sans NFS. On peut donc l'utiliser sur un poste client, mais on ne profitera pas de fonctionnalités du client direct NFS documenté ici (en version 11) :

http://www.oracle.com/technetwork/articles/directnfsclient-11gr1-twp-129785.pdf

 

Si la solution est acceptable dans un environnement, de développement, sur un environnement de production, il sera préférable de se procurer la DLL présente dans le package DataBase. Seul hic, ce package n'existe pas en 32 bits L

 

Derrière ce titre étrange se cachent quelques conseils sur l'utilisation de dépendance externes à vos projets. Que ce soit dans le cadre d'une maintenance, de la migration d'une application ou tout simplement dans l'évolution d'une application, des dépendances mal gérées peuvent faire capoter votre projet.

1. Lister ses dépendances

Il n'y a rien de pire qu'un projet dont on ne connait pas les dépendances. Savoir quelles dépendances on a, s'est déjà connaitre une partie de ce que l'on a besoin pour faire fonctionner son application. Dans certains cas, si vous connaissez les dépendances, vous pouvez même anticiper certains problèmes.

Si l'on ne connait pas ses dépendances, il est possible que l'on ne puisse pas déployer l'application.

Dans le cadre d'une migration, c'est une étape primordiale. Cette liste vous permettra de savoir quelles dépendances pourront être conservées, mises à jour, ou devront être supprimés. Si trop de dépendances n'existent pas sur la plateforme cible, il est possible que cela change complètement la philosophie de votre projet de migration en le transformant en projet de réécriture complète (pas de chance).

2. Ne garder que des dépendances utiles

Cette remarque vous fait sourire ? Si oui, avez-vous déjà listé les dépendances utilisées par le Template d'application web de Visual Studio ? Êtes-vous certain d'avoir besoin de toutes celles-ci pour votre projet ?

Il y a trop de projets qui incluent des dépendances pour effectuer des opérations déjà possibles avec les Frameworks. Exemple : sur un projet .net on peut déjà faire de la compression ou du cryptage sans utiliser de dépendances supplémentaires (et ça n'est pas très compliqué).

Parfois, il y a de dépendances que l'on garde par habitue. Il faut être vigilant avec celles-ci et régulièrement se tenir informé sur les évolutions de son Framework pour vérifier que celles-ci ne sont pas devenues inutiles. Exemple : avec le passage de Windows 8.0 à 8.1, j'ai supprimé plus de la moitié de mes dépendances, car j'ai presque trouvé tout ce dont j'avais besoin dans WinRT et les évolutions de Xaml.

3. Bien choisir ses dépendances

On a vite fait de lancer une recherche sur CodePlex, Nuget…etc… pour aller chercher des dépendances censées nous simplifier la vie. Certain préfèrerons acheter des composants aux près de fournisseurs bien connus comme DevExpress, Telerik… etc…

Quelle que soit la source des dépendances, il faut s'assurer de :

  • La viabilité de la source : un projet maintenu par un seul développeur très actif peut être parfaitement viable. Mais qu'en est-il d'un projet dont il n'y a toujours eu qu'une version ?
  • La fraicheur de la dépendance : un produit qui n'a pas été mis à jour depuis longtemps est un produit qui est peut-être mort. Il n'a donc pas d'avenir. Un bon indicateur pour identifier un projet mort, c'est de vérifier qu'il utilise un Framework récent. Exemple : une dépendance qui cible .net 2 en 2014… c'est risqué.
  • La maintenance corrective et évolutive : Un produit acheté doit toujours l'être avec ses mises à jour. Cela vous permettra de profiter des correctifs de celui-ci. Ce surcout doit être considéré avant tout achat pour éviter des débordements sur votre budget. J'ai déjà vu des projets en galère, car les bugs induits par les dépendances ne peuvent être résolus.
  • Regarder les breacking change : toujours vérifier si une dépendance est habituée à induire des breackin change suite à ses mises à jour. S'il y en a beaucoup, vous aurez beaucoup de travail à fournir lors des mises à jour.

4. Les dépendances ont des dépendances

On l'oublie souvent, mais une dépendance peut induire l'utilisation d'autres dépendances. Rien de pire que le message disant : «  la dépendance X où l'une de ses dépendances ne peut être résolue…. ».

À ce titre, vous devez appliquer les mêmes précautions sur celles-ci que sur vos dépendances directes. Il faut aussi être très prudent sur le fait qu'une dépendance n'aille pas à contrario des contraintes qui vous sont imposées. Exemple : Dépendance indirecte qui dépend de .net 4.5 alors que vous ciblez .net 4.0.

5. Garder un œil sur ses dépendances

Comme votre application, les dépendances évoluent. Ceci peut être pour votre plus grand bonheur. Mais ceci peut aussi être un véritable casse-tête à gérer.

Les problèmes pouvant être anticipés si on suit l'actualité de ses dépendances :

  • Breaking changes
  • Classes/Méthodes obsolètes
  • Classes/Méthodes abandonnées
  • Classes/Méthodes remplacées par d'autres
  • Ajout/suppression de dépendances indirectes
  • Abandon du projet par l'éditeur
  • .. etc…

Outre le fait de suivre ses informations, il faut aussi mettre à jour régulièrement ses dépendances. Ceci permet de réduire le travail à fournir. Si on espace les mises à jour de plusieurs mois ou années, on s'expose à de grands risques. Exemple : perte de temps, delta trop important entre deux versions et donc situation difficilement gérable.

6. Garder ses dépendances au chaud

Il faut toujours stocker les dépendances et/ou les fichiers qui ont servi à leur déploiement. Que ce soit sur un TFS, un SharePoint ou un simple partage. Ces fichiers vous seront indispensables pour remonter un environnement. Que ce soit un environnement de développement ou de production.

Même si aujourd'hui des dispositifs types Nuget sont devenus fréquents, j'ai toujours pris l'habitude de conserver les fichiers téléchargés par ceux-ci. Qui sait, la source sera peut-être coupée un jour.

Stocker, c'est bien, mais il faut aussi penser à noter clairement la plateforme cible. Il n'y a rien de pire que d'avoir deux DLL avec le même nom, le même numéro de version et ne plus savoir laquelle est destinée au 32 bits ou au 64 bits.

 

Il est fort probable que j'oublie une ou deux petites choses, mais l'essentiel est là.

Et vous, auriez-vous d'autres conseils à donner sur la gestion des dépendances ?

Depuis ce début d'après-midi, on peut aussi profiter des Minidrones de Parrot avec une tablette Windows 8.1 !

Contrairement à la version Windows Phone, cette version n'est pas en beta.

L'ensemble des fonctionnalités déjà présentes sur iOS, Androïd et Windows Phone sont disponibles, exception faite de la partie sociale. L'application a exactement la même ergonomie que sur les autres plateformes. On peut donc passer de la tablette au téléphone sans se poser de questions.

Je viens de tester avec un Rolling Spider et ma tablette Asus Vivota. On retrouve les mêmes comportements qu'avec un Windows Phone. C'est aussi bon. J'ai tout de même préféré utiliser le mode de pilotage dit « manette » , car utiliser le gyroscope de la tablette pour déplacer le drone m'a semblé trop étrange (voir inutilisable du fait de la taille de la tablette 10pouces). Il y a une option associée à bing map, mais cela ne semble pas marché comme convenu. Il y a un petit problème de compte développeur Bing Map ;) (en tout cas, c'est ce que j'ai constaté sur ma tablette)

Pour le téléchargement, cela diffère d'une machine à l'autre. Par exemple mon PC portable n'a pas accès à l'application (Dell XPS 17)

Belle exemple d'application universelle adaptée ;)

Maintenant, il me reste à m'acheter une seconde batterie pour mon drone. 10 minutes de jeux, c'est court quand on reste un grand gamin..

Depuis ce matin, on peut enfin profiter des Minidrones de Parrot avec un Windows Phone !

L'application est en beta pour le moment, mais l'ensemble des fonctionnalités déjà présentes sur iOS et Androïd semblent disponibles. D'ailleurs l'application a exactement la même ergonomie.

Je viens de tester avec un Rolling Spider et mon Lumia 1520 (Windows Phone 8.1 Cyan) et c'est bon, c'est même très bon ;)

Pour le téléchargement, cela se passe par ici.

Heureux propriétaire de SSD Samsung 840 EVO, j'ai une bonne nouvelle pour vous. Disposant moi-même de deux de ces SSD pour mes serveurs de test, j'ai testé l'utilitaire « Samsung SSD 840 EVO Performance Restoration Software » destiné à résoudre les récents problèmes de performance découverts sur ce modèle.

http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/support/downloads.html

 

L'utilitaire fonctionne parfaitement sur Windows 2012 R2 en version Core. Je l'ai exécuté sur mes deux serveurs Core sans la moindre difficulté. Il faut cependant noter que le processus nous oblige dans un premier temps à arrêter le serveur pour appliquer la mise à jour. Il faudra donc être près de la machine pour pouvoir la relancer. Après redémarrage, l'utilitaire se relance de lui-même et termine les opérations d'optimisation. Rien à redire, cela fonctionne parfaitement bien et depuis je n'ai pas constaté le moindre problème.

Juste un petit mot pour partager avec vous la joie de m'être vu décerner un nouveau MVP Award dans la spécialité Microsoft Integration.

 

L'information date du 1er octobre, mais ce n'est qu'aujourd'hui que j'ai enfin pris le temps de déposer le dernier disque reçu. Cela commence à avoir de l'allure.

 

Merci à Microsoft pour cette reconnaissance et bravo à tous les nouveaux MVP et à tous les MVP renouvelés ;)

Depuis l'arrivée des rubans dans SharePoint, il m'a de nombreuses fois été remonté des difficultés pour naviguer dans une librairie utilisant des dossiers. Avec le temps, je me suis rendu compte qu'il y avait une commande que les utilisateurs ne trouvaient pas naturellement « Naviguer vers le haut ».

Celle-ci se trouve dans le ruban « Bibliothèque » groupe « Gérer les affichages ». Bien entendu la commande est grisée si l'on ne se trouve pas dans un dossier.

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- [WCF] Configuration pour publication en Release par Blog de Jérémy Jeanson le 03-26-2015, 22:54

- SQL Server Reporting Services : Comment identifier des abonnements utilisateurs pour une migration de serveur de rapport par Blog Technique de Romelard Fabrice le 03-26-2015, 10:55

- Le yOS-Tour est lancé, rendez-vous à Genève le 13 avril ! par Le blog de Patrick [MVP Office 365] le 03-25-2015, 22:58

- [ Microsoft #Azure ] Gestion des comptes, des abonnements et délégation d’administration par Le blog de Patrick [MVP Office 365] le 03-21-2015, 20:46

- Qualité de code & Indentation par Fathi Bellahcene le 03-21-2015, 16:56

- [IIS] Mais d’où sort cette configuration ? par Blog de Jérémy Jeanson le 03-21-2015, 09:27

- Avec Microsoft Office 365, la CILE travaille plus vite. par Le Blog (Vert) d'Arnaud JUND le 03-13-2015, 17:19

- SSD : Volume Impossible @ redimensionner par Blog de Jérémy Jeanson le 03-07-2015, 09:36

- Microsoft Regional Director 2.0 ! par Le blog de Patrick [MVP Office 365] le 02-23-2015, 22:10

- TechDays Paris 2015: Malware unchained par Blog Technique de Romelard Fabrice le 02-12-2015, 22:58