Visual Studio 2010 et TFS 2010 – Évènements PreBuild et PostBuild d’une ou de toutes les Solution(s) Visual Studio

Avec TFS 2010, on crée souvent une définition de Build spécifique qui permet non seulement de vérifier l’intégration continue, mais également de préparer les éléments obtenus en sortie de compilation (Packaging), voire même de déployer ces éléments.

Si le Workflow 4 du template de Build permet d’effectuer ces étapes assez aisément , il est parfois intéressant de ramener cette étape de packaging au niveau de la compilation de la solution. Ce faisant, il est alors possible de générer le package à la fois côté serveur, et à la fois côté client.

Dans le cas où le packaging est configurable par projet, les évènements PreBuild et PostBuild des projets sont suffisants. Dans le cas par contre où le packaging nécessite d’effectuer des actions avant ou après la compilation de l’ensemble de la solution, des évènements PreBuild et PostBuild de la solution sont nécessaires.

Cas d’évènements spécifiques à une Solution Visual Studio :

Pour enregistrer des évènements avant la prise en compte du fichier .sln d’une Solution Visual Studio, il est possible de créer un fichier appelé before.NomDeLaSolution.sln.targets situé au même niveau que le fichier .sln Celui-ci peut alors contenir des instructions MSBuild telles que :

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="PreBuildPackaging" BeforeTargets="Build">
    
	<Message Text="PreBuildPackaging..." Importance="high" />
	
	<!-- Some MSBuild instructions: Copy, Move, Zip, Exe, etc. -->
	
  </Target>
</Project>

(Pour obtenir une liste complète des activités MSBuild disponibles : http://msdn.microsoft.com/fr-fr/library/7z253716(v=vs.100).aspx)

L’enregistrement d’évènements après la prise en compte du fichier .sln d’une solution Visual Studio s’effectuera de manière similaire : Il faut créer un fichier appelé after.NomDeLaSolution.sln.targets situé au même niveau que le fichier .sln. Exemple de fichier :

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="PostBuildPackaging" AfterTargets="Build">
    
	<Message Text="PostBuildPackaging..." Importance="high" />
	
	<!-- Some MSBuild instructions: Copy, Move, Zip, Exe, etc. -->
	
  </Target>
</Project>

Note : Pour les plus familiers du scripting MSBuild, ces évènements s’effectueront avant ou après une compilation ayant pour target Build. Pour gérer des dépendances entre les targets, il est possible d’utiliser l’attribut DependsOnTargets en lieu et place de AfterTargets ou BeforeTargets.

Pour pouvoir déclencher l’exécution de ces évènements, il suffit ensuite d’appeler le Visual Studio Command Prompt et de lancer la command MSBuild sur le fichier .sln :

image

(1) Commande MSBuild de compilation simple (2) Èvènement PreBuild de la Solution Visual Studio (3) Évènement PostBuild de la Solution Visual Studio
Note : Dans l’exemple ci-dessus, des fichiers before.ConsoleApplication9.sln.targets et after.ConsoleApplication9.sln.targets ont été créé au préalable

Pour reproduire ce packaging du côté de TFS, il suffit d’ajouter ces fichiers au contrôle de code source pour que ceux-ci soient pris en compte lors de la compilation MSBuild effectuée par les Agents de Build !

Cas d’évènements communs à toutes les Solutions Visual Studio :

/!\ Attention, les évènements MSBuild globaux sont à manipuler avec précautions car les modifications peuvent impacter toutes les solutions compilées sur l’ordinateur (Compilation MSBuild, compilation TFS)

Pour ajouter des évènements à toutes les Solutions Visual Studio compilées sur un ordinateur précis, cette fois-ci il faut se rendre du côté de : C:\Program Files (x86)\MSBuild. Il faut ensuite y créer des dossiers pour reproduire l’arborescence suivante : C:\Program Files (x86)\MSBuild\4.0\SolutionFile\ImportBefore.

Tout fichier ajouté dans ce répertoire (peu importe l’extension du fichier) est pris en compte lors de l’appel de la commande MSBuild.exe sur un fichier .sln.

En reprenant l’exemple précédent, en lieu et place de deux fichiers .targets, il est possible d’ajouter au répertoire ImportBefore un fichier AllSolutions.Packaging.proj. Ce fichier contient :

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="PreBuildPackaging" BeforeTargets="Build">
    
	<Message Text="PreBuildPackaging..." Importance="high" />
	
	<!-- Some MSBuild instructions: Copy, Move, Zip, Exe, etc. -->
	
  </Target>
  
  <Target Name="PostBuildPackaging" AfterTargets="Build">
    
	<Message Text="PostBuildPackaging..." Importance="high" />
	
	<!-- Some MSBuild instructions: Copy, Move, Zip, Exe, etc. -->
	
  </Target>
  
</Project>

Le résultat obtenu lors de la compilation de la solution est le même. Cependant ce packaging est également disponible pour toutes les autres solutions si la compilation est lancée depuis l’ordinateur qui possède ce répertoire ImportBefore !

Dans un environnement TFS, plus besoin de mettre dans le contrôle de code source des fichier pour le packaging, mais il faudra par contre déployer le répertoire ImporteBefore et son contenu sur tous les Agents de Build qui doivent pouvoir exécuter le “packaging”.

TFS 2010 - Déplacer les bases de données sur une autre partition

Durant le cycle de vie d’utilisation de TFS, il arrive parfois que la partition, sur laquelle les bases de données ont été placées, devienne trop petite (ou lorsque l’on se trompe de partition lors de l’installation du Serveur SQL…). Il faut alors déplacer les fichiers de base de données d’une partition à une autre.

L’opération s’effectue assez simplement avec TFS à l’aide d’une ligne de commande TFSServiceControl, et de SSMS (SQL Server Management Studio).

Pour commencer, il faut exécuter une console avec les droits administrateurs

image

Il faut ensuite se placer dans le répertoire où se trouve l’outil en ligne de commande TfsServiceControl.exe (C:\Program Files\Microsoft Team Foundation Server Dev11\Tools pour la version 11 ou C:\Program Files\Microsoft Team Foundation Server 2010\Tools pour la version 2010) puis l’exécuter avec le paramètre quiesce.

/!\ N’oubliez pas de prévenir vos utilisateurs de l’arrêt momentané du TFS /!\

image

Une fois les services arrêtés, la suite des opération va s’effectuer avec le SQL Server Management Studio.

image

On se connecte à la base de données

image

Il faut ensuite se positionner sur la base de données Tfs_DefaultCollection puis dans la section Tasks du menu, sélectionner Detach…

image

Cochez les cases des actions à effectuer avant le détachement de la base de données, puis cliquez sur OK

image

Rendez-vous ensuite dans le répertoire contenant les bases de données de TFS, puis coupez le fichier de base de donnée ainsi que son fichier de log (Généralement Tfs_DefaultCollection.mdf et Tfs_DefaultCollection_log.ldf)

image

Collez ensuite ces fichiers sur la partition cible

image
Dans la capture d’écran, les fichiers de base de données sont passés de la partition D à C)

Retournez ensuite dans SSMS puis cliquez sur le répertoire Databases et sélectionnez Attach…

image

Sélectionnez ensuite le nouvel emplacement de votre base de données

image
Le fichier de log qui l’accompagne est automatiquement associé

image
Le fichier de log a été automatiquement récupéré

image
La base de données réapparait dans la liste des bases de données de l’instance SQL

Il ne reste plus qu’à démarrer les services TFS à l’aide de la commande TfsServiceControl.exe unquiesce pour retrouver le fonctionnement normal du serveur.

image

Le serveur TFS est de nouveau disponible depuis les différents clients (Team Explorer, Test Manager, Excel, SharePoint, etc.)

image

TFS 2010 - Restriction champ Assigned To à un groupe de sécurité TFS

Lorsque la taille de votre SI commence a être assez conséquente, il arrive souvent que la liste des personnes à qui l’on peut assigner une tâche consiste en une liste déroulante interminable. On se retrouve alors à scroller indéfiniement pour pouvoir assigner une tâche à un membre de l’équipe, parmi toute une ribambelle d’autres personnes qui ne font même pas parti du projet.

Pour cela il est possible de limiter les valeurs autorisées dans le champs Assigned To (Assigné à en FR) avec un groupe de sécurité de TFS.

Prenons par exemple un projet d’équipe contenant 2 membres

image

Si l’on décide de créer un nouveau Work Item dans ce projet d’équipe, on peut voir apparaître des personnes qui ne font même pas parti de ce projet d’équipe :

image
Ici dans cet exemple, l’utilisateur Reader fait parti d’un autre projet d’équipe

Pour pouvoir restreindre l’accès, il faut commencer par utiliser les TFS Power Tools de Visual Studio

image
J’utilise dans cet article la version 11 de Visual Studio et de TFS, cependant la procédure reste la même à partir d’un Visual Studio et d’un TFS 2010

Il faut ensuite se connecter au projet d’équipe

image

Puis il faut sélectionner le type de Work Item que l’on veut modifier

image
N.B. : Si l’on veut restreindre les choix de tous les types de Work Items, il faut répéter cette opération autant de fois qu’il y a de types de Work Items

Une fois la définition ouverte dans l’éditeur, dans l’onglet Fields (1) , sélectionnez le champ Assigned To (2) puis cliquez sur Edit (3)

image

Sélectionnez ensuite l’onglet Rules (1) puis supprimez la propriété VALIDUSER (2) en cliquant sur Delete (3)

image

Confirmez votre choix

image

Puis ajoutez une nouvelle règle en cliquant sur New. Sélectionnez ensuite la règle ALLOWEDVALUES puis cliquez sur OK

image

Dans la fenêtre de configuration de la règle, commencez par cocher la case Exclude Groups (1) puis précisez le groupe de sécurité TFS que vous voulez utiliser en cliquant sur New (2) puis en saisissant [project]\NOMGROUPSECURITÉ NOMGROUPESECURITÉ est le nom d’un groupe de sécurité du projet d’équipe

image

Confirmez (cliquez sur OK) et fermez les nombreuses fenêtres ouvertes et n’oubliez pas de sauvegarder une fois les modifications terminées

image
La petite étoile signale que le fichier n’est pas encore sauvegardé

Pour que la modification apparaissent dans les prochaines modifications de Work Items, il est nécessaire de rafraichir le Team Explorer

image

Vous pouvez alors constater la bonne prise en compte de votre modification en créeant un nouveau Work Item ou en modifiant un Work Item déjà créé par le passé

image

SharePoint 2010 – Installation offline de SharePoint Foundation 2010

Team Foundation Server 2010 inclut par défaut un Windows SharePoint Services 3.0 (La version gratuite de SharePoint 2007), cependant, il est également possible de l’associer à une version plus récente de SharePoint i.e. la version SharePoint 2010.

Cependant pour pouvoir installer cette version 2010, il est nécessaire de disposer d’une connexion internet pour pouvoir télécharger automatiquement les prérequis. Dans le cas contraire, il faut télécharger un par un les prérequis, il est ensuite possible de les installer manuellement avant de commencer l’installation de SharePoint Foundation 2010 en elle-même.

Lors du lancement de l’installation des prérequis sans connexion internet, la fenêtre suivante s’affiche :

image
Le Server Web (IIS) s’installe/configure automatiquement en lançant l’installation des prérequis. Le Client Natif SQL Server 2008 s’installe automatiquement lors d’une installation manuelle d’un SQL Server 2008 R2

6 logiciels sont alors nécessaires pour valider l’installation des prérequis (3 autres sont facultatifs et peuvent être installés de la même manière) :

Pour vérifier leur bonne installation, il est possible de réexécuter l’installeur des prérequis, la fenêtre suivante devrait alors s’afficher :

image
L’installeur indique qu’une erreur s’est produite car les composants facultatifs n’ont pas été installés, cependant, cela ne devrait en aucun cas perturbé la poursuite de l’installation de SharePoint Foundation 2010

Vous pouvez ensuite continuer normalement l’installation de SharePoint Foundation 2010

image

TFS Integration Tools – Suivi des synchronisations avec Reporting Services

Afin de s’assurer du bon fonctionnement des différentes synchronisations effectuées par les TFS Integration Tools, 2 rapports sont présents dès l’installation. Il suffit alors d’effectuer les manipulations suivantes pour pouvoir les visualiser :

Localisez l’emplacement des rapports

image
L’un des rapports fournira un récapitulatif des différentes erreurs de synchronisation actuelles, et l’autre donnera des informations sur la latence de synchronisation des projets d’équipe

Commencez par vous rendre sur le site de Reporting Services (généralement de la forme http://NOMSERVEUR/Reports pour un SQL Server 2008 ou http://NOMSERVEUR/Reports_SQLEXPRESS pour sa version express with advanced services).
Créez ensuite un nouveau dossier Sync Status qui va stocker les 2 rapports

image 
Cliquez sur New Folder

Vous pouvez ensuite uploader dans ce dossier les 2 rapports

image

Rajoutez ensuite une nouvelle Data Source

image

Pour faire la liaison entre la base de données de TFS Integration Tools, spécifiez la chaine de connexion. Précisez ensuite les identifiants d’utilisateurs possédant les droits de récupérer des informations de la base Tfs_IntegrationPlatform et cochez la case Use as Windows Credentials when connecting to the data source.

image
N’oubliez pas de cliquer sur Test Connection pour vérifier que la configuration est correcte

Revenez dans le dossier Sync Status pour connecter votre nouvelle Data Source à vos 2 rapports

image
Cliquez sur Manage pour gérer la sources de données du rapport

Cliquez sur Browse pour aller sélectionner le Data Source créé précédemment.

image
Le chemin peut être différent si vous avez positionné votre dossier Sync Status ou le Data Source Tfs_IntegrationPlatformDS dans un répertoire différent.

image
Affichage du rapport de conflits actifs

image
Affichage du rapport de latences

TFS Integration Tools – Installation

L’installation des TFS Integration Tools demande une grande rigueur. Il convient alors de s’assurer des points suivants :

  • Le compte d’installation possède les droits dbcreator sur l’instance du serveur SQL
  • Ne pas utiliser “localhost” lors de la spécification du nom de l’instance SQL mais le nom du serveur.
  • Ne pas avoir échoué d’installation des TFS Integration Tools auparavant

Il faut ensuite suivre les différentes étapes suivantes :

image

image

image

 

image
Attention, le compte doit posséder les droits dbcreator (ou sysadmin) sur l’instance du serveur SQL

Préciser le nom du serveur SQL et ne pas utiliser localhost !

  • Pour un serveur SQL, utiliser généralement “NOMORDINATEUR
  • Pour un serveur SQL Express, utiliser généralement “NOMORDINATEUR\SQLEXPRESS

image

image

Dans le cas où vous avez utilisé localhost comme nom de serveur, vous risquez de rencontrer l’erreur suivante :

image

Il conviendra alors de réessayer l’installation en utilisant cette fois ci le nom du serveur à la place de localhost (Il sera alors peut-être nécessaire d’activer le protocole Named Pipe à partir du Sql Server Configuration Manager image)

image


Classé sous

TFS 2010 - Renommer User Story (Récit utilisateur) en Exigence

Une modification qui peut sembler tout à fait anodine à première vue : Renommer le Work Item User Story en Exigence. Cette modification possède pourtant des liens étroits que l’on ne soupçonnerait pas avec l’un des produits phare de l’offre TFS 2010: Microsoft Test Manager !

Je vais commencer par renommer le Work Item User Story en Exigence. Pour cela, à l’aide des TFS Power Tools de Visual Studio 2010, je lance l’édition du Work Item

image
Il est également possible d’éditer le Template de Work Item d’un Process Template plutôt que de travailler directement sur les Template de Work Item du serveur.

image
Le Work Item User Story s’appelle Récit Utilisateur en version française

Je renomme ensuite le Work Item en Exigence puis je sauvegarde la modification sur le serveur.

image
Le renommage d’un Work Item va entrainer la création d’une copie de ce Work Item. Le Work Item User Story n’est donc pas supprimé du serveur

Premier soucis: Les Exigences ne sont pas sélectionnables en tant que Requirement dans Microsoft Test Manager

image

Cause du problème : Microsoft Test Manager se base sur la catégorie Requirement Category pour filtrer les éléments considérés comme exigence. Il faut donc ajouter le nouveau type de Work Item Exigence à cette catégorie.

Pour cela, utilisez la commande suivante qui va permettre d’exporter le fichier XML contenant les catégories du projet d’équipe modifié. Remplacez pour cela les arguments qui correspondent à la configuration de votre serveur TFS (URL de la collection de projet d’équipe, nom du projet et nom du fichier d’export)

image

witadmin.exe exportcategories /collection:http://win-gs9gmujits8:8080/tfs/defaultcollection /p:"Tailspin Toys" /f:C:\categories.xml

Ouvrez ensuite ce fichier, puis localisez la catégorie ayant pour référence Microsoft.RequirementCategory puis remplacez le type de Work Item User Story par Exigence (éventuellement renommez également cette catégorie) et sauvegardez le fichier

image

Importez ensuite le fichier modifié sur le serveur TFS à l’aide de la même commande que précédemment, en utilisant cette fois-ci le paramètre importcategories

image

Les Exigences devraient maintenant être sélectionnables en tant que Requirement depuis Microsoft Test Manager.

image

Deuxième soucis: Si l’on créé un cas de test associé à l’exigence, ce cas de test n’arrive pas à lister les exigences auxquelles il est lié.

image
La liaison Exigence > Cas de test fonctionne bien

image
Pourtant les liaisons Cas de test > Exigences ne s’affiche pas

Cause du problème: Le Work Item Test Case utilise une requête pour afficher ses liaisons vers des Exigences mais celle-ci est mal configurée. À l’aide des TFS Power Tools, ouvrez le Work Item Template Test Case

image

Localisez alors l’onglet permettant de lister les anciennes User Story

image

Vous pouvez commencer par remplacer le texte contenant User Story par Exigence, puis cliquez sur les Control Settings

image

Dans ces settings, remplacez User Story par Exigence. Sauvegarder ensuite le Work Item Template

image

Les liaisons du cas de test vers des exigences devraient maintenant apparaitre.

image

N.B.: Dans le cas de l’édition du Process Template, les catégories sont modifiables directement depuis l’éditeur de Process Template.

image
L’édition du Process Template permet de répercuter toutes ces modifications dans les prochains projets d’équipes créés à partir du Template modifié.

Dans le cas où l’on décide d’utiliser la partie utilisant Microsoft Test Manager, il est possible de renommer le Work Item d’exigence (par défaut nommé User Story) mais cela reste une manipulation assez délicate.

TFS 2010 - Définir la hauteur du champs d’un Work Item dans le portail d’équipe SharePoint (Team Web Access)

Le portail d’équipe SharePoint est le point d’entrée de prédilection pour toutes les personnes, n’utilisant pas Team Explorer, qui ont besoin de créer des Work Items (Déclaration de bug, création de tâche, etc.)

image
Déclarer un bug, une tâche depuis le portail d’équipe SharePoint

L’affichage d’un Work Item est généralement identique entre l’affichage sous Visual Studio et à partir du site web Team Web Access, à quelques exceptions près…

 image
L’affichage sous Visual Studio semble correct tandis que l’affichage web semble prendre beaucoup de place inutilement

Dans Visual Studio, si l’on a installé les Power Tools, un menu permet de modifier le Template des Works Items, directement depuis le serveur TFS.

image
Menu disponible si l’on a les TFS Power Tools installés

Il est possible de modifier l’affichage de n’importe quel type de Work Item (Bug, Task, User Story, Test Case, etc.)

image 
Sélection du Template de Work Item de type Task pour le modifier

À partir de l’ongle Layout, il sera possible de modifier l’affichage d’une fiche de Work Item. Il faut alors sélectionner l’élément graphique à modifier puis lui rajouter un attribut via sa collection de propriétés Attributes

image
Cliquer sur […] permet d’afficher une fenêtre dédiée à l’édition des attributs

Pour modifier la hauteur du Work Item, il faut rajouter l’attribut height=[valeur en pixels]

image
L’utilisation du caractère * permet de préciser que le champ Description du Work Item variera selon son contenu

image
On peut également fixer une taille fixe de 150 pixels pour le champ History

Si la valeur n’est pas correcte ou si l’on saisit une valeur vide (ex: “height=”), le Work Item prendra une valeur par défaut.

Après avoir sauvegardé ses modifications (qui sont envoyées directement au serveur TFS), il est temps d’aller constater la nouvelle apparence du Work Item.

/!\ Il ne faut pas oublier de fermer toutes les instances du navigateur web pour être certain d’afficher la nouvelle interface du Work Item.

image
La hauteur du champ Description s’agrandira en fonction du nombre de lignes contenues à l’intérieur. Le champ History quand à lui utilise une taille fixe

Finalement, le Template de Work Item utilise ses propres attributs avec leur propres valeurs (on ne précise pas la mesure “px” pour l’attribut height par exemple) et les retranscrit en CSS pour l’affichage Web.

image
Le champ Description est agrandi suivant son contenu et le champ History voit son attribut CSS height fixé à 150px

Le portail d’équipe SharePoint, couplé à ses interactions avec le site Team Web Access, permet de fournir une interface utilisable par tous les utilisateurs. En rajoutant quelques personnalisations, on obtient une interface très ergonomique, disponible pratiquement dès la création du projet d’équipe !

TFS 2010 - Configurer l’itération d’un rapport (ex. Burndown & Burnchart)

Lors de la création d’un projet sous TFS 2010 (Team Foundation Server), un rapport de Burndown (Taux d’avancement) est affiché sur le portail d’équipe.

image
Le rapport de Burndown du portail d’équipe qui n’affiche rien

Il est souvent nécessaire de configurer ce rapport (notamment pour n’afficher qu’une itération en particulier)

Pour cela, il faut commencer par se rendre sur le rapport en question

image
En passant par le Team Explorer par exemple

Le rapport qui nous intéresse se trouve dans le dossier Dashboards (Tableau de bord) et se nomme Burndown. Il faut l’afficher puis se rendre sur ses propriétés

image
L’onglet Properties sous SQL Server 2008

Dans la section Parameters, observez le champs IterationParam

image
Le paramètre IterationParam avec comme valeur “[Work Item].[Iteration Hierarchy].[All]”

Il nous faut maintenant récupérer la valeur de l’itération qui nous intéresse (itération 2 par exemple) pour pouvoir la donner comme valeur à ce paramètre.

Pour cela, connectez vous au cube Olap de TFS avec SQL Server Management Studio (SSMS)

image
Bien sélectionner Analysis Services

Créez alors une nouvelle requête.

image
L’arborescence des métadonnées du cube de TFS

Naviguez ensuite dans Work Item.Iteration Hierarchy > Iteration2 puis faites un Drag & drop de (Iteration 2) dans la zone de requête

image
L’identifiant d’une itération sous TFS ne s’invente pas

Copiez cette valeur puis collez la dans le champs IterationParam précédemment vu. Vous pouvez en profiter pour configurer la date de début et de fin de votre itération, l’affichage de la courbe idéale et réelle, etc. N’oubliez pas de cliquez sur Apply

image
Ne pas oublier de cliquer sur Apply

Et voilà, vous pouvez retourner sur votre rapport ou directement sur votre tableau de bord pour voir la nouvelle configuration de votre rapport de Burndown. Il sera alors nécessaire de refaire la même opération cette fois-ci pour le rapport de Burn Rate

image

N.B. : Bonne nouvelle ! Dans la nouvelle version de TFS 11, il ne sera plus nécessaire de configurer à la main ce rapport car celui-ci se mettra automatiquement à jour en fonction du Sprint (= Itération) sélectionné !


Les 10 derniers blogs postés

- ProcDump 6.0 : support du filtrage sur messages d'exceptions .NET, des filtres multiples et du ciblage par nom de service par CoqBlog le 05-20-2013, 14:50

- Votez pour le TOP 10 des influenceurs SharePoint francophones ! par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 12:59

- [Conf’SharePoint] Dernier rappel ! :-) par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:09

- [ #SharePoint 2013 ] les modèles de sites standards… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:03

- 10 erreurs de compréhension concernant SharePoint… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 08:27

- Conf’SharePoint : 10 bonnes raisons pour ne pas la rater par Le petit blog de Pierre / Pierre's little blog le 05-14-2013, 02:24

- [Event] Soirée de lancement Agile .NET France à Lyon par Blog Agile/ALM de Vincent THAVONEKHAM le 05-13-2013, 01:29

- .NET / Debug : inspection de la mémoire d'applications .NET (dump ou processus live) : première livraison d'une librairie .NET par Microsoft par CoqBlog le 05-11-2013, 22:21

- SharePoint : Incompatibilité avec Internet Explorer 10 (IE10) par Blog Technique de Romelard Fabrice le 05-08-2013, 16:29

- AutoSPInstaller pour SharePoint 2013 maintenant disponible en “RTM” par Julien Chable le 05-06-2013, 23:30