En effet, SSE est :
– Léger
– Simple à mettre en oeuvre (client ou server)
– Interopérable (java / dotnet dans mon cas)
– Transparent sur le réseau (ne nécessite que http)

Le lien suivant vous permet de disposer d’une implémentation simple en C# de SSE…

https://github.com/benjamin-devuyst/dotnet.serversentevents.client/tree/master/Foxrough.ServerSentEvents.Client/

Plus d’infos sur SSE : https://medium.com/conectric-networks/a-look-at-server-sent-events-54a77f8d6ff7

Si vous souhaitez disposer des outputs par projet, il vous faut ajouter : /p:GenerateProjectSpecificOutputFolder=true à la ligne de commande MSBuild.

Cela peut s’ajouter dans les configurations de build TFS :

Attention : cela ne fonctionne qu’avec MSBuild du Framework 4.5 !

Enjoy

Solution #1 : Utiliser l’activity présente dans la librairie tfsbuildextensions.
Inconvénients :

• L’utilisation de l’activity est peu documentée… Il convient donc d’ouvrir avec iLSpy l’assembly pour pouvoir la paramétrer.
  Cela pourra faire l’objet d’un autre billet.
• L’implémentation de l’activity impose à la build de ne contenir (au plus) qu’une seule application !

  En effet, la création du package ClickOnce est réalisée à la main.
  Les grandes lignes du processus sont les suivantes :
  1. Copie du contenu du répertoire binaries de la build dans le répertoire du package
  2. Renommage des fichiers en .deploy
  3. Manipulation de Mage.exe pour créer le manifest de déploiement et le signer.

  Etant donné que sous un build TFS, le répertoire des binaries est commun à tous les projets de la build, si votre solution contient plus d’une application, le package ClickOnce généré contiendra également les binaires des autres applications…

  Dans ce cas, il ne vous plus reste qu’à passez votre chemin et à évaluer la solution #2 !

Solution #2 : Modification du template pour ajouter la génération du package ClickOnce par l’appel MSBuild.
Étapes :

1. Configuration ClickOnce dans le projet concerné
   Cela consiste à ouvrir les propriétés du projet, et a paramétrer la publication ClickOnce.
   Ensuite, à exécuter le wizard de déploiement afin de tester le paramétrage, et le corriger le cas échéant.
   Attention a ne pas oublier d’archiver les modifications sur TFS !
2. Trouver les bons paramètres en ligne de commande msbuild
   L’idée est la suivante : il est possible de générer un package ClickOnce à partir d’un appel MSBuild à condition de disposer des bons paramètres.
   La ligne de commande est la suivante (dans mon cas) :
   msbuild  chemin-vers-fichier-projet.csproj
     /t:build;publish
     /p:ApplicationVersion=1.2.3.4
     /p:BootstrapperEnabled=true
     /p:IsWebBootstrapper=true
     /p:Configuration=Release
     /p:ManifestKeyFile=chemin-vers-fichier-signature.pfx
     /p:OutputPath=chemin-vers-repertoire-sortie
     /p:InstallUrl=http://url-installation-clickonce

   /t:build;publish	MSBuild doit exécuter Build et Publish
   /p:ApplicationVersion	Propriété indiquant le numéro de version ClickOnce du déploiement Le format : Majeur.Mineur.Build.Revision
   BootstrapperEnabled	Valeur indiquant si le bootstrapper (setup.exe) doit être généré.
   IsWebBootstrapper	Valeur indiquant que le déploiement ClickOnce doit pouvoir être effectué par le Web (manifeste de déploiement xxx.application)
   Configuration	Valeur indiquant la configuration de build (Debug, Release).
   ManifestKeyFile	Chemin vers le fichier pfx qui signe le manifeste ClickOnce
   OutputPath	Chemin vers le répertoire de destination du package (pour la génération)
   InstallUrl	URL cible de l’installation ClickOnce Ex. : http://server/monapplicationClickOnce

   Attention : Si le fichier de signature a besoin d’un mot de passe, il est indispensable d’installer le certificat de l’autorité racine dans le magasin correspondant du poste de travail, et d’installer le certificat de signature dans le magasin my de l’utilisateur courant.

3. Modification du template de build
   Elle consiste à ajouter une activité de type « MSBuild » après la commande MSBuild native au workflow en renseignant les paramètres obtenus à l’étape ci dessus.
   Il peut être nécessaire de préciser une condition d’exécution (« If ») si plusieurs fichiers solution sont indiqués dans la build afin d’éviter que l’action de packaging soit exécutée plusieurs fois.
   Exemple d’utilisation dans un workflow :
   

   La paramétrage de l’activité msbuild de packaging ressemble à ceci :
   
   
   J’attire votre attention sur les deux points suivants :
   – Les paramètres /p: … sont injectés dans la case « CommandLineArguments »
   – Le contenu de « CommandLineArguments » formatte la chaine à l’aide de string.Format (d’où la syntaxe {x})
   – Les paramètres /t: … sont injectés dans la case « Targets »

   Je vous laisse consulter la MSDN pour la documentation relative aux paramètre d’une activité de build

Enjoy

Customize Team Build 2010

Edit 2013-05-16 : Petite précision, dans la partie Part 5 : Increase AssemblyVersion, l’auteur précise dans le code de l’activité check out l’instruction  » workflow.Folders  » pour récupérer les répertoires mappés dans le workspace.
Ensuite,  » folder.LocalItem  » pour récupérer le chemin local (dans la boucle « pour chaque folder contenu dans le workspace »).
Le problème est le suivant : si le workspace contient un folder cloaked, il est bien contenu dans la liste retournée par la propriété workspace.Folder, mais la propriété LocalItem est nulle ! (ce qui est logique !)
Donc, lorsqu’il est nécessaire de lister les répertoires : il faut ajouter un filtre sur soit folder.IsCloaked soit sur string.IsNullOrEmpty(folder.LocalItem) afin de ne récupérer que les folders mappés dans le workspace courant !

Enjoy !

On obtient des fichiers solutions Visual Studio dont le nombre de projet excède largement la douzaine projets…

ce billet propose juste une piste de travail pour ce genre de problématiques…

Or, d’après les cahiers blancs MS (Un bon guide de mise en place des pratiques TFS), des fichiers SLN de plus d’une douzaine de projet ont des conséquences fâcheuses sur le projet :
– Absence d’optimisation des assemblies à la compilation, (je confirme)
– Temps de compilations excessifs sur les machines des développeurs (je confirme)
– Temps de compilations excessifs sur les agents de builds (intégration continue), (je confirme)
– Piètre performance au chargement de la solution (je confirme)
– …

La solution consiste à considérer les stratégies décrites dans le cahier blanc, pour éventuellement aboutir sur un Multi SLN.
Exemple :
– SLN1 : Projets totalement indépendants des projets de la solution (drivers, API client de partenaires extérieurs, API commune à l’entreprise)
– SLN2 : Projets de la couche de services, la DAL, etc.
– SLN3 : Projets propres à la couche de présentation

L’exemple ci-dessus est une stratégie, d’autres stratégies existent.

La règle, en termes de références entre projets, est la suivante : tous les projets situés au sein du même SLN peuvent se référencer entre eux, les liens entre projets de solutions différentes doivent se réaliser par DLL.
Dès lors, les outputs des projets des solutions (excepté celle de présentation) doivent être archivées (par solution) afin de ne pas forcer les développeur à devoir régénérer toutes les SLN lorsqu’un autre membre de l’équipe modifie une couche intermédiaire.
En d’autres termes :
– les outputs des projets de la SLN1 sont redirrigés en postBuild Event vers un répertoire (ex : $SlnRoot\_Build-SLN1) puis archivés.
– les outputs des projets de la SLN2 sont redirrigés en postBuild Event vers un répertoire (ex : $SlnRoot\_Build-SLN2) puis archivés.

La commande xcopy à placer dans le postBuild Event du projet est la suivante :
xcopy /E /Y /D /R « $(TargetDir)*.* » « $(SolutionDir)_Build-SLN-1-[SlnName] »

/E : Copie les répertoires et sous-répertoires, y compris les répertoires vides
/Y : Supprime la demande de confirmation de remplacement de fichiers de destination existants
/D : Copie les fichiers modifiés à partir de la date spécifiée. Si aucune date n’est donnée, copie uniquement les fichiers dont l’heure source est plus récente que l’heure de destination
/R : Remplace les fichiers en lecture seule

La dernière option est très importante, car les dll’s de destination sont en Read Only (puisque archivées sur TFS)… Sans le /R, on peut avoir des erreurs comme :
Error 3 The command « xcopy /E /Y /D « E:\DEV\…\MonProjet\bin\Debug\*.* » « E:\DEV\_Build-SLN-1-SlnName » … exited with code 4.

Astuce : Pour vérifier le message d’erreur réel : copier la commande remontée par Visual Studio lors des erreurs de build liées à xcopy dans une invite de commande et l’exécuter !

Un dernier point : Si vous êtes confronté à ces problèmes de solutions complexes, je vous invite à
– lire le document cité ci dessus afin d’élaborer une stratégie de multi SLN (non trivial),
– échanger avec les membres de l’équipe, car en définitive ce sont eux qui exploiteront les SLNs !

Enjoy !

Un petit billet rappelant le principe de fonctionnement d’un IEnumerable.
L’IEnumerable offre une interface permettant d’itérer parmi des objets. Dans les faits, cette interface permet de retourner une instance d’IEnumerator (via une méthode GetEnumerator). Cet IEnumerator ne propose que 3 membres :
– Current : propriété permettant de retourner l’élément actuel
– MoveNext() : méthode permettant d’itérer vers l’élément suivant
– Reset() : méthode permettant de réinitialiser l’itérateur

L’utilisation d’un IEnumerable couplé au mot clé yield return permet (entre autre) de streamer au fil de l’eau les objets récupérés depuis une source de données.
Pour info (ou rappel) : le mot clé yield return est un ovni qui remonte un objet à l’appelant (consommateur de IEnumerable), le laissant utiliser l’objet, puis lors de l’appel au Move Next (élément suivant d’un foreach), redescend l’exécution dans la source de données vers le prochain yield return (ou yield break si fin).

Le principal intérêt est (vous l’avez deviné), de pouvoir appliquer un traitement élément par élément, sans jamais devoir monter en mémoire une liste complète d’objets.
Cela améliore l’expérience utilisateur sur des gros chargements de données.

Exemple : Un utilisateur (humain ou machine) doit traiter une grosse quantité d’informations, élément par élément, sans pénaliser l’exploitation des ressources (réseau, matériel, performance).
La source de données peut être un fichier csv, xml, base de données, etc.

Dans ce cas de figure, la mémoire ne contient jamais plus d’un élément !
L’élément suivant n’est chargé que lorsque l’utilisateur le demande (move next dans un foreach).

Le plus important à retenir est que l’exécution du chargement (donc du premier item) n’est réalisé qu’à l’appel du premier move next … comme un IQueryable ! , au contraire d’un ICollection qui pointe vers une implémentation mémoire de liste de données !

Pour illustrer un problème potentiel :
Lors de l’utilisation de WCF Data Services, la récupération d’IEnumerable{T} où T est un type simple n’est pas géré par la couche cliente Service Reference (mais bien par le coté serveur).
Donc, cela nécessite une implémentation « Maison » utilisant une webrequest (côté consommateur de données).
Imaginons une propriété (coté client) qui retourne un IEnumerable{string}, l’appel au serveur ne se fera que lorsque l’itération sur le premier élément aura été sollicitée par le consommateur de la propriété.
A ce moment là, la mécanique yield return sera mise en oeuvre !

Je vous invite également à comparer le code IL (via Reflector, ILSpy, etc) entre l’un implémentation IEnumerable couplé à un yield return avec celle retournant une liste…

Marrant…

Tout les jours, j’ai l’impression que ce menu me HURLE dessus !

Pour ramener le menu à la normale il faut modifier/Créer (si inexistante) une clé de registre :

>>>> HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General\SuppressUppercaseConversion
>>>> REG_DWORD value: 1

(trouvé ici)

Là, je suis presque content

Petite finesse des scopes (étendues) de la recherche SharePoint Enterprise Search :
Pour information (ou rappel) :
Scope ou étendue : template de recherche dans lequel on précise des règles permettant de filtrer les résultats affichés. Ces règles influent sur l’origine, le type, etc. du contenu à afficher.
Server Name Mapping ou mappage de nom de server : liaison entre une url dans laquelle le contenu est trouvé et l’url de remplacement pour l’affichage publique des résultats. Ce mécanisme permet (par exemple) de crawler du contenu en http et l’afficher en https.

Lorsqu’un server name mapping est définit, et que des scopes utilisent des règles sur les sources de contenu, ces urls doivent préciser l’url publique de la Server Name Mapping.
Sans quoi… ca marche pas

En d’autres termes
Zone par défaut d’un site SharePoint : http://monSite
Zone publique du site : https://www.monsite.com

Server Name Mapping : http://monSite => https://www.monsite.com

Scope de filtrage des document > Règle sur la source n’est pas http://monSite/documents mais bien https://www.monsite.com

Ce cas particulier a été mis en avant grâce au fait que l’Https n’était pas géré dans IIS (et donc pas lié à une zone SharePoint SSL).

Have a good day !

J’ai cherché des informations permettant d’identifier les patchs qui modifient le numéro de version de Sharepoint et le bonheur est dans ce pré :
http://blogs.technet.com/b/moss_it/archive/2011/08/15/lista-di-versioni-di-sharepoint-server-2010-o-sharepoint-foundation-2010-wss-4-0.aspx

EDIT : ou dans celui ci : http://blogs.technet.com/b/sharepointjoe/archive/2011/02/01/sp2010-sharepoint-2010-build-level-and-version-numbers.aspx