[Skydrive Pro]–Sortie du client standalone pour Windows !

 

Bonjour à tous.

Le travail en mobilité est devenu un vrai besoin à l’heure actuelle. A l’époque de SharePoint 2010 (pas encore révolu ), nous avions le client SharePoint Workspace 2010 qui permettait d’emporter ses documents en synchronisant le client avec SharePoint 2010.

Avec l’avènement de SharePoint 2013, Microsoft nous proposait le client Skydrive Pro… mais seulement avec le pack Office 2013 (et Office 365 Pro Plus ou Office 365 Small Business Premium). Il était impossible de se procurer ce client séparément ! Ce qui compliquait légèrement ce travail itinérant…

C’est maintenant chose faite, il est possible de le télécharger gratuitement ! par ici : http://www.microsoft.com/en-US/download/details.aspx?id=39050.

Il vous suffira de l’installer sur chacun des postes clients concernés et de lancer la synchronisation depuis le bouton “Sync” dans SharePoint 2013 :

 

Le client se lancera alors et vous demandera d’indiquer où il devra effectuer la synchronisation (répertoire local de la machine cliente) :

 

Le répertoire local sera alors synchronisé avec SharePoint 2013 dès que celui-ci sera accessible via le réseau :

 

Bonne installation !

[SharePoint 2013] – Installation des Office Web Apps 2013 avec SharePoint Server 2013

 

Bonjour à tous.

Un nouvel article pour vous montrer comment installer et configurer les Office Web Apps 2013 couplées à SharePoint Server 2013.

Pour l’histoire, les Office Web Apps sont arrivées dans leur deuxième version : nous avons les Office Web Apps 2010 et 2013 à ce jour. Ces OWA vont nous permettre, couplées à SharePoint, d’ouvrir des documents Word, Excel, PowerPoint et OneNote directement dans le navigateur, sans utiliser les composants clients Office. Ce qui peut être évidemment très pratique lors les collaborateurs utilisent des plateformes hétérogènes de types tablettes iPad, Android, des téléphones mobiles ou encore des postes de travail sous MacOS ou une distribution Linux.

Il faut bien intégrer pour commencer qu’à chaque version de SharePoint correspond une version des Office Web Apps :

• SharePoint 2010 (Foundation ou Server) => Office Web Apps 2010
• SharePoint 2013 (Foundation ou Server) => Office Web Apps 2013

Coté Licencing, vous pourrez installer ces OWA (2010 ou 2013) suivant le type de licences que vous possédez pour le pack Office. Si vous possédez les packs Office (en volumes) version 2010 vous pourrez éditer les fichiers Office. Si vous ne les possédez pas, vous pourrez seulement lire des documents Office via les OWA.

 

De plus, avec la version 2010 des OWA, il était possible d’installer ce composant logiciel sur le même serveur que le serveur SharePoint (en le boostant un peu…). Avec la version 2013, ce n’est plus possible et ces composants s’installe sur un serveur dédié, rattaché au même domaine que SharePoint. Il y a quelques contraintes supplémentaires comme de ne pas avoir installé le pack Office sur ce serveur. Pour plus de renseignements : http://technet.microsoft.com/fr-fr/library/jj219458.aspx

 

Pour l’architecture utilisée pour cet article, j’ai 3 machines virtuelles (VM) :

• 1 contrôleur de domaine : DOMAIN
• 1 serveur SharePoint Server 2013 Enterprise (EN) : SP2013-DEV
• 1 serveur Office Web Apps 2013 : SPOWA2013

Ces trois serveurs sont rattachés au même domaine : DEMO, sont installés sous Windows Server 2012 ou Windows Server 2008R2 (EN) et à jour :

 

Et oui… une belle débauche de mémoire et de processeurs…

 

Je précise que mes machines Active Directory & SharePoint étaient déjà installées et fonctionnelles avant l’installation d’Office Web Apps.

Première étape installer et configurer Windows Server 2012 (et mettre à jour !), je ne détaillerai pas cela dans cet article.

 

1/ Préparation du serveur pour Office Web Apps 2013

 

Lorsque le serveur a été installé et configuré, il faut commencer par télécharger les Office Web Apps 2013. Pour cela, vous pouvez télécharger la Preview ici : http://www.microsoft.com/en-us/download/details.aspx?id=30358 ou ici http://www.microsoft.com/fr-fr/download/details.aspx?id=35489. Vous pourrez également télécharger l’iso depuis votre compte MSDN ou Technet.

 

Connectez vous ensuite à votre serveur OWA avec un compte du domaine qui est administrateur local du serveur (dans mon cas, c’est le même que le compte d’installation de SharePoint : DEMO\spadmin).

 

Il faut ensuite exécuter un script PowerShell sur le serveur OWA en lançant la commande en administrateur. Pour cela, rendez-vous sur les “tuiles” de Windows Server 2012, repérez la tuile Windows PowerShell :

 

Faites un clic-droit sur la tuile :

 

Et cliquez sur “Run as administrator” :

 

Vous pouvez avoir l’UAC qui se déclenche, on clique sur “Yes” :

 

Et PowerShell 3.0 :

 

Nous allons lancer un script permettant d’installer et de configurer les rôles et services nécessaires sur le serveur pour OWA 2013. Vous trouverez des informations complémentaires ici : http://technet.microsoft.com/fr-fr/library/jj219455.aspx.

On copie / colle le script :

 

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices

 

Le script d’installation se lance et devrait durer… moins de 3 minutes :

 

Mais que fait ce script me direz-vous ? Il se charge d’installer le rôle Web Server de Windows Server 2012 (installer IIS), et active sur ce rôle les différents protocoles, utilitaires qu’utiliseront les OWA 2013.

Lorsque le script est terminé, redémarrer le serveur OWA 2013. En allant dans le gestionnaire du serveur, on voit tout de suite le nouveau rôle IIS qui apparait :

 

 

 

Les extensions et fonctionnalités activées :

 

2/ Installation des Office Web Apps 2013

 

Maintenant que les prérequis sont installés, il va falloir installer les binaires des Office Web Apps 2013. Pour cela il faut monter l’iso téléchargé précédemment sur la machine virtuelle et lancer le setup d’installation :

 

Pour cela, on se rend dans l’explorateur de fichier et on fait un clic-droit sur le lecteur DVD avec l’iso monté, puis “Install or run program from your media” (s’il ne démarre pas tout seul).

Encore une fois, l’UAC peut s’activer, on clique sur “Yes” :

 

Le contrat de licence apparait, on sélectionne la case à cocher en bas, puis on clique sur “Continue” :

 

On nous demande ensuite d’indiquer l’emplacement d’installation des binaires. Je conserve l’emplacement par défaut : C:\Program Files\Microsoft Office Web Apps et on clique sur “Install Now” :

 

L’installation débute… on patiente :

 

L’installation est terminée, on clique sur “Close” :

 

En option, vous pouvez également installer les languages packs pour OWA 2013. Pour plus de renseignements, visitez ceci : http://technet.microsoft.com/fr-fr/library/jj219455.aspx => Etape 3.

 

 

3/ Déploiement des Office Web Apps

 

L’étape suivante consiste à créer l’application Web qui permettra d’afficher nos documents. Il existe plusieurs types de configurations suivant votre besoin : http ou https, équilibrage de charge, etc.

Dans mon cas, je reste dans un périmètre interne, tous les utilisateurs se connectent en http. Pour corser un peu le tout, nous allons créer l’application en PowerShell. Pour cela, on reprend notre console PowerShell lancée en administrateur et on exécute :

New-OfficeWebAppsFarm –InternalURL "http://servername" –AllowHttp -EditingEnabled

 

Où :

• New-OfficeWebAppsFarm : permet de créer la ferme OWA 2013
• InternalURL : adresse du serveur courant, dans mon cas http://spowa2013
• AllowHttp : puisque je reste en http
• EditingEnabled : puisque je veux permettre de lire / modifier les documents

Cela donne :

New-OfficeWebAppsFarm –InternalURL http://spowa2013 –AllowHttp -EditingEnabled

 

Un avertissement vous stipule que pour utiliser le mode édition de document des OWA 2013, il faut que vos utilisateur aient les licences adéquates. Pour savoir si vous pouvez utiliser le mode édition, je vous renvoie vers : http://technet.microsoft.com/fr-fr/library/ff431682.aspx#license.

Pour faire simple, vous avez les licences pour Office 2013, vous pouvez éditer. Sinon la lecture des fichiers est “offerte” par Microsoft.

 

Pour configurer les licences à utiliser, reportez vous à : http://technet.microsoft.com/fr-fr/library/jj219627.aspx.

Dans mon cas, je choisis donc “Yes” (Y) :

 

La configuration se poursuit. A la fin, un résumé apparait :

 

Remarque MSDN : Si des composants de .NET Framework 3.5 ont été installés puis supprimés, il est possible que vous rencontriez des messages de type « Exceptions de service web (500) » ou « Erreur interne du serveur (500.21) » lorsque vous exécutez des applets de commande OfficeWebApps. Pour résoudre ces problèmes, exécutez les exemples de commandes suivants à partir d’une invite de commandes avec élévation de privilèges afin de supprimer les paramètres susceptibles de gêner le fonctionnement normal d’Office Web Apps Server :

%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –iru
iisreset /restart /noforce

 

 

4/ Vérification que tout est ok…

 

Pour cela, nous allons utiliser le service de discovery des Office Web Apps en se connectant tout simplement sur une URL :

http://servername/hosting/discovery

 

Dans mon cas :

http://spowa2013/hosting/discovery

 

Je lance donc simplement un navigateur (IE 10 ici) et on entre l’adresse ci-dessus. Si Office Web Apps Server fonctionne comme prévu, vous verrez s’afficher un flux XML de découverte WOPI (Web app Open Platform Interface). Les premières lignes de ce fichier doivent se présenter comme dans l’exemple suivant : :

 

Et ce n’est pas fini…

 

 

5/ Configurer SharePoint Server 2013 pour Office Web Apps 2013

 

Il nous reste maintenant à faire le lien entre notre ferme SharePoint Server 2013 et les Office Web Apps 2013. Et encore une fois… une bonne dose de PowerShell !

Cependant, nous n’allons pas utiliser la console PowerShell 3.0 de Windows Server 2012, mais le SharePoint Management Shell de SharePoint Server 2013… un outil bien connu des administrateurs SharePoint !

Lançons donc la console SharePoint Management Shell, sur le serveur SharePoint bien entendu !

 

Puis toujours dans cette console, on lance la commande :

New-SPWOPIBinding -ServerName <WacServerName> -AllowHTTP

 

Dans mon cas (attention aux paramètres suivant ceux fixés lors de la configuration des OWA : http / https en particulier) :

New-SPWOPIBinding –ServerName SPOWA2013 -AllowHTTP

 

 

Le Shell vous liste un ensemble de connections WOPI disponibles :

 

Puis on exécute :

Get-SPWOPIZone

 

Dans les résultats vous devez avoir absolument :

 

Internal-https

 

Et bien sûr nous voudrions avoir du http ! Nous allons donc modifier cette zone avec la commande :

Set-SPWOPIZone –zone “internal-http”

 

Et on relance avec Get-SPWOPIZone pour vérifier que cela a bien été pris en compte :

Maintenant nous avons :

 

Internal-http

 

 

Ca sent la fin… mais pas tout de suite. Il nous reste à autoriser l’authentification OAuth sur http pour que cela fonctionne. Pour cela on éxécute :

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

Si cela renvoie “False” dans la console, alors il faut forcer la valeur à “True” :

$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
$config.Update()

 

On relance une petite vérification :

 

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

La valeur renvoyée doit être maintenant à “True” :

Pour plus d’informations : http://technet.microsoft.com/fr-fr/library/ff431687.aspx.

 

 

6/ Vérification de la configuration globale

 

Pour vérifier… il faut tester ! Nous allons donc nous connecter sur un de nos sites SharePoint avec un compte utilisateur / collaborateur (pas d’administrateur, super admin etc.)

 

J’ajoute quelques documents de type Office… dans une bibliothèque de documents :

 

On clique sur un des fichiers (PowerPoint pour ma part)… et ça marche !

 

Et du Word :

 

Et de l’Excel :

 

Et un OneNote :

 

Notez à chaque fois la présence des boutons dans le ruban pour éditer les documents, les sauvegarder etc. Ca marche plutôt bien !

 

Grâce aux Office Web Apps 2013, nous avons aussi la prévisualisation des documents (dans la bibliothèque de documents et dans la recherche) :

 

 

Si vous avez activé l’édition / création des documents depuis OWA 2013, lorsque vous cliquez sur le bouton Nouveau document Word, vous pourrez créer vos document directement en Web !

 

 

Voilà, c’est fini !

[SharePoint 2013]–Nouvel outil : SharePoint Color Palette Tool

Avec la sortie de la nouvelle version de SharePoint 2013, nous avons vu (encore) son design général changé. Ce design reprend les principes de Modern UI dictés par Microsoft et repris sur l’intégralité des plateformes : Windows 8, Windows Phone, Xbox.

Nous retrouvons donc dans SharePoint en particulier les Tuiles bien connues, et d’autres un peu moins “Visibles” au premier abord.

SharePoint 2013 apporte également son lot de nouveau thèmes graphiques natifs sur lesquels on peut personnaliser le jeu de couleurs, l’icône, et même la navigation latérale via les materpages oslo.master & seattle.master. Cet éditeur de thèmes permet quand même bien des personnalisations, mais il se peut que cela ne suffise pas !

Dans ces cas là, on peut utiliser le Design Manager permettant d’importer des découpages html pour les convertir en masterpages, les canaux, etc. (voir mon article : SP2013–Design Manager).

 

Pour nous permettre d’aller plus loin, mais sans recourir à SharePoint Designer, aux CSS, aux masterpages, Microsoft nous propose un nouvel outil fraichement releasé : SharePoint Color Palette Tool ! Les prérequis sont Internet Explorer 8 ou supérieur et le Framework 4.5.

Pour ceux qui le connaitraient, pour SharePoint 2010 nous avions Theme Builder renommé Open XML Theme Builder et disponible récemment sur CodePlex : Open XML Theme Builder.

 

Voyons ensemble à quoi cela ressemble !

 

On télécharge l’outil ici : SharePoint Color Palette Tool (1,1Mb).

Et on l’installe (ici sur une machine Windows 8 Enterprise x64 en anglais) :

 

On lance le setup, “Next” :

 

On accepte les termes du contrat de licence et “Next” :

 

On choisit l’emplacement d’installation, puis “Next” :

 

Résumé des information, “Next” :

 

L’installation est terminée, on coche “Launch the program”, “Finish” :

 

Le programme se lance :

 

Premières impressions… plutôt bonnes ! On retrouve sur la gauche un ensemble de contrôles “couleur” avec prévisualisation et code couleur RGB. Au centre, une prévisualisation du résultat (on reprend le thème général de SharePoint 2013) et tout en haut le choix du layout (oslo ou seattle), en dessous un affichage des warnings & erreurs. Sur la droite, un contrôle permet de placer une image en fond, de choisir un jeu de couleurs originel, et au centre un outil permettant de tester le contraste appliqué…

 

Première chose que je vérifie… qu’est-ce que génère cet outil ? En faisant File > Save, on me propose de sauvegarder un fichier *.spcolor :

 

Ce fichier spcolor n’est autre qu’un fichier XML :

 

Qu’il faudra importer dans SharePoint 2013, pour en savoir plus, direction MSDN : http://msdn.microsoft.com/en-us/library/jj945889.aspx

En fait on retrouve une certaine analogie entre ce fichier spcolor et les css, mais seulement pour la partie couleurs. En effet, on ne retrouve dans ce fichier aucun information sur la masterpage, le layout etc. Donc les paramètres dans l’outil Color Palette ne servent qu’à la prévisualisation, pas au paramétrage du thème en lui-même.

Notons également que dans la zone de gauche, on a des sous items sur lesquels on pourra modifier les couleurs :

 

A mon avis, cela va être difficile de faire un jeu de couleur correct dès le premier essai ! Il y a beaucoup de couleurs à paramétrer…

 

Avec 3 ou 4 clics, on arrive à quelque chose… ou pas ! (Notez les warnings…)

 

A bientôt !

[Visual Studio & SharePoint]–Paramètres remplaçables

Bonjour à tous.

Si vous développez des projets SharePoint 2010 ou 2013 avec Visual Studio 2010 ou 2012, vous devez connaitre les paramètres remplaçable. En effet, Visual Studio vous permet d’utiliser des sortes de “Pragmas” remplacés à la compilation par Visual Studio lui-même.

Vous reconnaitrez ces paramètres remplaçables rapidement car ils sont entourés par des “$”, du type : $SharePoint.Project.FileName$

Vous retrouverez ces paramètres par exemple dans les pages d’application (Applications Pages), dans l’entête de chacune des pages :

<%@ Assembly Name=”$SharePoint.Project.AssemblyFullName$” %>

Lorsque on lancera la compilation du projet dans Visual Studio, ces paramètres seront remplacés par :

<%@ Assembly Name=”MonProjet.SharePoint, Version=X.X.X.X, Culture=neutral, PublicKeyToken=XXXXXXXXXXXX” %>

Voici le tableau des paramètres remplaçables que vous pourrez utiliser :

Nom du paramètre	Description
$SharePoint.Package.Name$	Nom du package
$SharePoint.Package.FileName$	Nom du fichier de définition du package
$SharePoint.Package.FileNameWithoutExtension$	Nom sans extension du fichier de définition du package
$SharePoint.Package.Id$	ID unique SharePoint du package
$SharePoint.Feature.FileName$	Nom du fichier de définition d’une fonctionnalité
$SharePoint.Feature.FileNameWithoutExtension$	Nom du fichier de définition d’une fonctionnalité sans l’extension du nom de fichier
$SharePoint.Feature.Id$	ID unique SharePoint de la fonctionnalité
$SharePoint.Feature.DeploymentPath$	Nom du dossier de la fonctionnalité dans le package
$SharePoint.Project.FileName$	Nom du projet
$SharePoint.Project.FileNameWithoutExtension$	Nom du projet sans l’extension
$SharePoint.Project.AssemblyFullName$	Nom complet de l’assembly du projet
$SharePoint.Project.AssemblyFileName$	Nom de l’assembly du projet
$SharePoint.Project.AssemblyFileNameWithoutExtension$	Nom de l’assembly du projet sans l’extension
$SharePoint.Project.AssemblyPublicKeyToken$	PublicKeyToken de l’assembly
$SharePoint.ProjectItem.Name$	Nom de l’élément de projet
$SharePoint.Type.[GUID].AssemblyQualifiedName$	Nom qualifié de l’assembly
$SharePoint.Type.[GUID].FullName$	Nom complet de l’assembly

Microsoft précise également que l’on peut utiliser ces paramètres remplaçables dans les fichiers de type :

• XML
• ASPX
• ASCX
• WebPart
• DWP

Il est possible d’étendre ces possibilités en modifiant le fichier : Microsoft.VisualStudio.SharePoint.targets qui se trouve dans : …\<program files>\MSBuild\Microsoft\VisualStudio\v10.0\SharePointTools

On l’édite avec NotePad par exemple :

On ajoute des extensions de fichier supportées si besoin. Par contre, si on change de machine, on prendra cette configuration !!! Donc attention, ces paramètres ne seront plus remplacés.

En résumé, ces paramètres sont vraiment très pratiques, et on les utilise très souvent (Visual Studio en utilise lui aussi fréquemment lorsque l’on créé une page d’application par exemple).

Pensez-y !

[VSTO]–Mon premier VSTO pour Outlook 2013

Bonjour à tous.

Aujourd’hui un petit article qui sort des traditionnels posts autour de SharePoint, avec au programme un VSTO pour Outlook (2013 dans mon cas), Visual Studio 2012 et les modèles de projets pour Office 2013.

Mon cas est simple, il faut que j’ajoute aux catégories proposées en standard par Outlook des catégories personnalisées pour colorer les Rendez-vous du calendrier suivant le type :

• Absences (RTT, congés) : Rouge
• Production : Orange
• Formation : Mauve
• Avant-Vente : Vert
• Intercontrat (Le moins possible !!!) : Jaune

Je ne vais pas personnaliser le ruban dans cet exemple… peut être plus tard !

1/ La plateforme de développement

Dans le but de rentrer le plus vite dans le vif du sujet, ma plateforme de développement se compose de ma machine de travail quotidienne :

• Windows 8 Enterprise x64 en anglais
• Office Professional Plus 2013 x86 en anglais
• Visual Studio 2012 Ultimate en anglais

Pour pouvoir développer avec les modèles de projet Office 2013, la première chose à faire est de télécharger les extensions pour Visual Studio 2012 que vous trouverez ici : http://msdn.microsoft.com/en-us/office/apps/fp123627.aspx

Une fois l’exécutable téléchargé, lancez le. Il s’agit d’un WebInstaller de Microsoft qui téléchargera le nécessaire et l’installera sur votre poste. Attendez la fin de l’installation.

2/ Création du projet Visual Studio

Vous pourrez ensuite lancer Visual Studio 2012 :

Créez un nouveau projet en faisant : File > New > Project. L’assistant de création d’un projet se lance. Dans les modèles de projet, vous devriez trouver (dans la section C# dans mon cas) la section Office/SharePoint, puis Office Add-ins. Dans cette section vous trouverez tous les modèles pour Office 2013 : Word, Excel, PowerPoint et autres… :

On choisit ici “Outlook 2013 Add-In”, on nomme le projet (Demo.Outlook.Addin) et on le place dans le bon répertoire. Puis on clique sur OK.

Le projet est créé dans l’explorateur de solution :

Le projet se compose pour le moment d’un élément (une classe) ThisAddin avec deux évènements : ThisAddIn_Startup et ThisAddIn_Shutdown. Ces deux évènements sont appelés au chargement de l’Add-in (lancement d’Outlook ou activation de l’Add-in via le gestionnaire) ou au déchargement (fermeture d’Outlook ou désactivation de l’Add-In).

3 / Le code

Dans mon cas c’est plutôt simple. Pour ajouter des éléments dans les catégories existantes, je vais m’appuyer sur le modèle objet (Interop) d’Outlook pour ajouter dans la collection des catégories de nouveau éléments.

Pour cela, nous allons recourir au namespace : Microsoft.Office.Interop.Outlook en utilisant la classe Categories. Cette classe possède une méthode Add() prenant en paramètres :

• Un nom : string
• Une couleur : Microsoft.Office.Interop.Outlook.OlCategoryColor [Option]
• Un raccourci clavier : Microsoft.Office.Interop.Outlook.OlCategoryShortcutKey [Option]

Ce qui donne :

Application.Session.Categories.Add(“Absences”, Microsoft.Office.Interop.Outlook.OlCategoryColor.olCategoryColorRed, Microsoft.Office.Interop.Outlook.OlCategoryShortcutKey.olCategoryShortcutKeyCtrlF2);

Nous allons répéter cela pour toutes les catégories à ajouter :

Dans le souci de ne pas ajouter ces catégories à chaque activation de l’Add-In, j’ai ajouter une méthode CategoryExists() qui retourne True si la catégorie existe, False sinon :

private bool CategoryExists(string categoryName)
{
foreach (Microsoft.Office.Interop.Outlook.Category item in Application.Session.Categories)
{
if (item.Name == categoryName)
return true;
}
return false;
}

On vérifie pour cela que le nom n’apparaisse pas déjà dans les catégories existantes (on aurait pu vérifier la couleur, le raccourci etc.)

Le code étant ok, nous allons passer au debug.

3/ Debug

Pour tester, rien de plus simple ! On ferme toutes les instances d’Outlook ouvertes sur le poste de travail, et on utilise la touche F5 pour démarrer le débug. Visual Studio déploie le projet, lance Outlook… Et on a plus qu’à vérifier que tout fonctionne :

Nikel… Mais il manque quand même quelque chose… un projet pour déployer tout ça sur le poste des collègues !

4/ Projet de déploiement

Pour créer un projet de déploiement, avec Visual Studio 2012 vous pouvez utiliser InstallShield etc.

Mais dans mon cas, je voulais tester WIX depuis un moment… Vous pourrez télécharger le modèle de projet ici : http://wixtoolset.org/

WIX Toolset permet de créer des setup d’installation paramétrables et personnalisables à partir de fichiers XML. Il faut donc télécharger puis installer les modèles de projet et accessoirement redémarrer Visual Studio 2012.

Après avoir redémarré Visual Studio, nous allons commencer par réouvrir la solution VSTO. Puis nous allons faire un clic droit sur la solution, Add > New Project… :

Dans l’arborescence des modèles de projet disponibles, un nouveau regroupement est disponible : “Windows Installer XML”. Dans ce regroupement on sélectionnera “Setup Project” et bien sûr on nommera le projet (ici Demo.Outlook.Addin.Setup) et on clique sur OK :

Le nouveau projet est créé, il est composé principalement d’un fichier “Product.wxs” qui est en fait un fichier XML :

Ce fichier va décrire tout le processus de déploiement du VSTO sur les machines clientes. Nous allons parcourir le schéma pour ajouter les nœuds utiles. Je suis parti sur la base de cet article : http://www.add-in-express.com/creating-addins-blog/2012/11/13/wix-installation-vsto-office-addin/ pour décrire le processus de déploiement.

Première ligne, Product. Nous allons ici déclarer les attributs du produit à déployer. J’ai choisi de générer un GUID grâce à l’outil intégré à Visual Studio (Create GUID Tool) et de replacer l’attribut “Id”. Ensuite j’ai remplacé l’attribut Name avec le nom de mon VSTO, la langue par 1036 (Français, 1033 == Anglais) et le “Manufacturer” par Neos-SDI dans mon cas :

<Product Id=”E7F42E5E-7474-4E27-909B-D1E4A8A1B028″ Name=”Demo.Outlook.Addin” Language=”1036″ Version=”1.0.0.0″ Manufacturer=”Neos-SDI” UpgradeCode=”3786b23e-f5d5-4119-b0ef-0680416f6fae”>

Puis j’ai remplacé le MajorUpgrade par (en Français) :

<MajorUpgrade DowngradeErrorMessage=”Une version plus récente de [ProductName] est déjà installée.” />

NB : Toutes les sections suivantes seront ajoutées dans <Product>[…]</Product>

Ensuite, j’ai ajouté un “Property” & un “Condition” pour vérifier à l’installation si la bonne version des VSTO (Runtime version 4 pour Office 2013) est disponible sur la machine cliente (Recherche dans la base de registre de la machine). Pour cela on utilise :

<Property Id=”VSTORUNTIMEREDIST”>
<RegistrySearch
Id=”VSTORuntimeRedist”
Root=”HKLM”
Key=”SOFTWARE\Microsoft\VSTO Runtime Setup\v4R”
Name=”Version”
Type=”raw” />
</Property>

<Condition Message=”The Visual Studio 2010 Tools for Office Runtime is not installed. Please download and install from http://www.microsoft.com/en-us/download/details.aspx?id=20479.”>
<![CDATA[Installed OR VSTORUNTIMEREDIST>="10.0.30319"]]>
</Condition>

Cela affichera un message d’erreur si la version du Runtime n’est pas la bonne, proposant de la télécharger grâce au lien http fourni.

Nous allons également vérifier que le Framework 4.0 est bien installé sur la machine cliente. Pour cela, on utilise une “PropertyRef” et une “Condition” :

<PropertyRef Id=”NETFRAMEWORK40FULL”/>
<Condition Message=”This application requires .NET Framework 4.0.”>
<![CDATA[Installed OR NETFRAMEWORK40FULL]]>
</Condition>

Nous allons maintenant nous occuper des composants à déployer. Pour cela nous allons utiliser des “<Component>”, “<ComponentGroup>” et des “<Feature>”.

En dehors de la balise <Product> nous allons déclarer les composants à déployer puis les références avec une <Feature> dans <Product>.

Les fichiers à déployer sont situés dans le répertoire de sortie (output) du projet Visual Studio, dans mon cas Demo.Outlook.Addin/bin/debug :

Commençons par créer les ComponentGroup nécessaires. Il faut référencer les output produits par la compilation du projet VSTO par Visual Studio. Pour cela, il faut utiliser (après </Product>) :

<Fragment>
<ComponentGroup Id=”ProductComponents” Directory=”INSTALLFOLDER”>
<Component Id=”OutlookAddin1_vsto_Component”>
<File Id=”OutlookAddin1_vsto” KeyPath=”yes” Name=”Demo.Outlook.Addin.vsto” Source=”$(var.AddinFiles)” />
</Component>

<Component Id=”OutlookAddin1_dll_manifest_Component”>
<File Id=”OutlookAddin1_dll_manifest” KeyPath=”yes” Name=”Demo.Outlook.Addin.dll.manifest” Source=”$(var.AddinFiles)” />
</Component>

<Component Id=”MSOfficeToolsCommon_dll_Component”>
<File Id=”MSOfficeToolsCommon_dll” KeyPath=”yes” Name=”Microsoft.Office.Tools.Common.v4.0.Utilities.dll” Source=”$(var.AddinFiles)” />
</Component>
<Component Id=”MSOfficeToolsOutlook_dll_Component”>
<File Id=”MSOfficeToolsOutlook_dll” KeyPath=”yes” Name=”Microsoft.Office.Tools.Outlook.v4.0.Utilities.dll” Source=”$(var.AddinFiles)” />
</Component>
<Component Id=”OutlookAddIn1_dll_Component” >
<File Id=”OutlookAddIn1_dll” KeyPath=”yes” Name=”Demo.Outlook.Addin.dll” Source=”$(var.AddinFiles)” />
</Component>
</ComponentGroup>
</Fragment>

Nous référençons ici le fichier *.vsto produit avec (Demo.Outlook.Addin.vsto) :

<Component Id=”OutlookAddin1_vsto_Component”>
<File Id=”OutlookAddin1_vsto” KeyPath=”yes”      Name=”Demo.Outlook.Addin.vsto” Source=”$(var.AddinFiles)” />
</Component>

Puis le manifest produit (Demo.Outlook.Addin.dll.manifest) :

<Component Id=”OutlookAddin1_dll_manifest_Component”>
<File Id=”OutlookAddin1_dll_manifest” KeyPath=”yes” Name=”Demo.Outlook.Addin.dll.manifest” Source=”$(var.AddinFiles)” />
</Component>

Puis les DLL pour les VSTO (Common + Outlook) :

• Microsoft.Office.Tools.Common.v4.0.Utilities.dll
• Microsoft.Office.Tools.Outlook.v4.0.Utilities.dll

<Component Id=”MSOfficeToolsCommon_dll_Component”>
<File Id=”MSOfficeToolsCommon_dll” KeyPath=”yes” Name=”Microsoft.Office.Tools.Common.v4.0.Utilities.dll” Source=”$(var.AddinFiles)” />
</Component>
<Component Id=”MSOfficeToolsOutlook_dll_Component”>
<File Id=”MSOfficeToolsOutlook_dll” KeyPath=”yes” Name=”Microsoft.Office.Tools.Outlook.v4.0.Utilities.dll” Source=”$(var.AddinFiles)” />
</Component>

Et enfin la DLL du projet (Demo.Outlook.Addin.dll) :

<Component Id=”OutlookAddIn1_dll_Component” >
<File Id=”OutlookAddIn1_dll” KeyPath=”yes” Name=”Demo.Outlook.Addin.dll” Source=”$(var.AddinFiles)” />
</Component>

Pour que WIX prenne en compte ces demandes d’installation des vsto, dll et autres manifests, il faut lui indiquer dans la balise <Product></Product> qu’il doit prendre en compte ces Components. Pour cela on ajoute une balise Feature dans <Product></Product> :

<Feature Id=”ProductFeature” Title=”Demo.Outlook.Addin.Setup” Level=”1″>
<ComponentGroupRef Id=”ProductComponents” />
</Feature>

Il se peut que la balise apparaisse déjà et soit déjà ok…

Il faut maintenant indiquer à WIX que lorsque le produit sera installé, il apparaitra dans le menu Ajout/Suppression de Programmes en ajoutant des clés de registre. Pour cela on utilise à nouveau des Components de la manière suivante :

<Fragment>
<Directory Id=”TARGETDIR” Name=”SourceDir”>
<Directory Id=”ProgramFilesFolder”>
<Directory Id=”NeosFolder” Name=”Neos”>
<Directory Id=”INSTALLFOLDER” Name=”Planning Outlook Add-in” />
<Component Id=”Registry_FriendlyName”>
<RegistryValue Id=”RegKey_FriendlyName” Root=”HKCU” Key=”Software\Microsoft\Office\Outlook\AddIns\Demo.Outlook.Addin” Name=”FriendlyName” Value=”Demo.Outlook.Addin Add-in for Outlook” Type=”string” KeyPath=”yes” />
</Component>
<Component Id=”Registry_Description”>
<RegistryValue Id=”RegKey_Description” Root=”HKCU” Key=”Software\Microsoft\Office\Outlook\AddIns\Demo.Outlook.Addin” Name=”Description” Value=”Demo.Outlook.Addin Add-in for Outlook to manage Categories in Calendars and Inbox.” Type=”string” KeyPath=”yes” />
</Component>
<Component Id=”Registry_Manifest”>
<RegistryValue Id=”RegKey_Manifest” Root=”HKCU” Key=”Software\Microsoft\Office\Outlook\AddIns\Demo.Outlook.Addin” Name=”Manifest” Value=”[INSTALLFOLDER]Demo.Outlook.Addin.vsto|vstolocal” Type=”string” KeyPath=”yes” />
</Component>
<Component Id=”Registry_LoadBehavior”>
<RegistryValue Id=”RegKey_LoadBehavior” Root=”HKCU” Key=”Software\Microsoft\Office\Outlook\AddIns\Demo.Outlook.Addin” Name=”LoadBehavior” Value=”3″ Type=”integer” KeyPath=”yes” />
</Component>
</Directory>
</Directory>
</Directory>
</Fragment>

On indique ici le répertoire d’installation par défaut du projet. Ici ce sera dans C:\Program Files (x86)\Neos\Planning Outlook Add-in. On y placera l’intégralité des composants à déployer et on créera 4 clés de registre dans HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\AddIns\Demo :

• FriendlyName = Demo.Outlook.Addin Add-in for Outlook
• Description = Demo.Outlook.Addin Add-in for Outlook to manage Categories in Calendars and Inbox.
• Manifest = =[INSTALLFOLDER]Demo.Outlook.Addin.vsto|vstolocal
• LoadBehavior = 3

Il faut ensuite référencer ces components dans la <Feature> utilisée précédemment, ce qui donne :

<Feature Id=”ProductFeature” Title=”Neos.Planning Add-in for Outlook” Level=”1″>
<ComponentGroupRef Id=”ProductComponents” />
<ComponentRef Id=”Registry_FriendlyName” />
<ComponentRef Id=”Registry_Description” />
<ComponentRef Id=”Registry_Manifest” />
<ComponentRef Id=”Registry_LoadBehavior” />
</Feature>

Dernière étape, ajouter des composants utiles à WIX pour le manifest de licence produit (EULA.rtf) et à préciser le type d’interface à utiliser :

<UIRef Id=”WixUI_Minimal” />
<WixVariable Id=”WixUILicenseRtf” Value=”EULA.rtf” />

Ce fichier EULA.rtf doit être ajouté à la solution (WIX en fournit un de base sur leur site) :

Si vous compilez dès à présent. Vous obtiendrez une erreur :

Undefined preprocessor variable ‘$(var.AddinFiles)’.

C’est tout à fait normal ! En effet, dans les déclaration des chemins vers les fichiers, nous avons utilisé cette directive “$(var.AddinFiles)” sans la déclarer. Pour cela, il faut se rendre dans les propriétés du projet WIX :

Dans la section “Build” nous allons déclarer une “preprocessor variable” (il vous faudra modifier le nom du projet en gras ici) :

• AddinFiles=..\Demo.Outlook.Addin\bin\$(Configuration)\

On sauvegarde et on compile la solution.

De nouvelles erreurs apparaissent :

Rien de grave ici non plus, il manque seulement des références à des DLL utiles à la compilation. Nous allons faire un clic droit sur le répertoire References du projet WIX, puis “Add Reference” :

Une fenêtre d’ajout de références (pas celle de Visual Studio mais celle de WIX) apparait. On ajoute 2 références :

• WixNetFxExtension.dll
• WixUIExtension.dll

Et on recompile à nouveau ! Tout se passe bien :

5/ Tests

Il reste maintenant à tester le setup et que le projet fonctionne. Pour cela, rendez vous dans le répertoire de sortie du projet d’installation :

Lancer le .msi :

Le contenu apparaissant dans cette fenêtre est en fait le contenu du fichier EULA.rtf… On accepte les termes et on clique sur “Install”…

Puis on lance Outlook, les nouvelles catégories apparaissent !

Voila, le post s’achève… un merci tout particulier à Benoit Laut pour ses conseils et son aide ! A bientôt !

Télécharger le source : ici.

SP2010–Remplacer les formulaires–Part 2

Bonjour à tous.

Dans la partie précédente, nous avons vu comment créer trois modèles de listes SharePoint 2010 (fonctionnera également avec 2007 et 2013, Server ou Foundation). Avec ces modèles nous avons déployé pour chacun d’eux une instance : Pays, Villes et Commandes.

Le tout bien sûr “packagé” dans une solution SharePoint avec Visual Studio 2010. Ainsi nous avons utilisé une “Feature” pour déployer le tout qui, lorsqu’elle s’active, déploie les modèles, créée les instances de ces listes et remplit les listes Pays et Villes avec un ensemble de données.

Dans cette nouvelle partie, nous allons tenter de remplacer les formulaires standards :

• DispForm.aspx
• NewForm.aspx
• EditForm.aspx

Dans le but de surcharger leur comportement, principalement au niveau des listes déroulantes : la liste des villes disponibles sera filtrée en fonction du pays qui sera sélectionné.

Pour compléter, vous pourriez également faire appel à quelques projets CodePlex fournissant ces listes déroulantes liées par le biais de champs personnalisés (Custom Fields) qui sont réutilisables et en soit plus “propres”. Je vous propose une autre méthode, sans passer par ces fonctionnalités additionnelles, plus dans le cas d’un usage unique.

1/ Comprendre la structure – le pourquoi…

Avant d’entamer la phase technique du développement/déploiement, il est essentiel de comprendre comment fonctionnent les formulaires standards, où ils sont déployés, etc.

Vous pouvez utiliser SharePoint Manager 2010 ou SharePoint Designer 2010 pour explorer la structure utilisé par les listes pour rediriger l’utilisateur vers ces fameux formulaires lorsqu’il souhaitera ajouter/modifier/voir les propriétés d’un élément/document dans une liste/bibliothèque de documents SharePoint. La structure est plutôt simple. Elle se compose de :

• Un répertoire racine : RootFolder. Ce répertoire est créé par défaut.
• Des sous-répertoires créés par les utilisateurs
• Des items/documents créés par les utilisateurs
• Un répertoire particulier : “Forms” qui contient les formulaires en question pour les bibliothèques de documents
• Pour les listes, les formulaires en questions sont placés directement dans le RootFolder.

Il m’est arrivé, bien souvent, de reprendre des projets SharePoint, par les biais de missions de conseil, d’assistance et je vois assez régulièrement des développeurs ayant essayé de “surcharger” ces formulaires en créant leurs propres formulaires (par copier/coller)… ayant des nom différents. Et en général… :

• DispForm.aspx devient DisForm2.aspx
• NewForm.aspx devient NewForm2.aspx
• EditForm.aspx devient EditForm2.aspx

Et moi…. ça ne me convient pas ! En effet, les anciens formulaires restent disponibles, ils ne sont pas masqués… et restent donc accessible pour quelqu’un d’observateur qui saura assez rapidement appeler ces url et pourra donc se passer des règles de gestion que l’on souhaite imposer. Nous allons voir maintenant comment écraser ces fichiers standards en déployant notre solution SharePoint et les associer à nos listes Villes et Commandes.

2/ Déployer des Formulaires personnalisés

Reprenons notre solution. On remarque tout de suite que nous n’avons aucun fichier “aspx” dans les répertoires de la solution (répertoires des listes en particulier).

Première manipulation : utiliser SharePoint Designer 2010 pour récupérer les fichiers “aspx” originaux.

On commence donc par lancer SharePoint Designer 2010 (de préférence en 32bits ), on se connecte donc sur le site et utilise l’explorateur pour atteindre notre liste, Villes par exemple (via l’explorateur à gauche “All Files > Lists > Villes”) :

On remarque tout de suite la présence des fichiers qui nous intéressent. Manipulation assez simple, on ouvre chacun des fichiers (en mode Avancé : clic droit sur chaque fichier > Ouvrir en mode avancé) et on copie/colle le contenu de chacun dans un fichier (avec Notepad ou autre) le but étant de sauvegarder chacun de ces fichiers dans le répertoire de la solution, à l’intérieur du dossier concernant notre liste et bien sûr avec le nom qui va bien… :

On copie le contenu du fichier…

Dans un Notepad :

On sauvegarde dans les répertoires Windows des définitions des listes Villes et Commandes, puis on inclut les fichiers dans la solution SharePoint :

Les nouveaux fichiers sont inclus :

Il reste ensuite une dernière manipulation à faire, sur chacun de nos fichiers aspx ajoutés dans la solution, nous allons faire un clic-droit > Propriétés :

Et nous allons changer la propriété “Deployment Type” en “ElementFile” (on peut vérifier le répertoire de déploiement qui doit pointer vers le répertoire de sortie de la feature dans le répertoire 14 (SharePointRoot) :

On reproduit ceci sur chacun des fichiers aspx. Vous pouvez vérifier dans le fichier “SharePointProjectItem.spdata” (celui au niveau de la déclaration du modèle de liste) que les modifications ont bien été apportées :

Notre solution est donc enrichie avec ces nouvelles pages. Toutefois, si l’on déploie ces nouvelles pages aspx directement, l’instance déployée n’utilisera pas directement nos nouvelles pages. Pour cela, nous allons devoir modifier le fichier Schema.xml pour chacune de ces listes, au niveau du nœud “Forms” (tout à la fin du fichier) :

<Forms>
<Form Type=”DisplayForm” Url=”DispForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
<Form Type=”EditForm” Url=”EditForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
<Form Type=”NewForm” Url=”NewForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
</Forms>

Chaque formulaire/page est associé à notre liste SharePoint par le biais d’un nœud <Form />.

Nous allons modifier chacun de ces nœuds <Form /> pour indiquer à SharePoint qu’il doit utiliser nos pages et pas celles par défaut. Nous allons donc supprimer l’attribut SetupPath pour faire pointer chacun des formulaires vers nos pages custom.

Nous allons également ajouter quelques attributs :

• Path=”NewForm.aspx” => Chemin relatif vers le fichier NewForm.aspx dans notre solution
• Default=”TRUE” => Page par défaut
• UseDefaultListFormWebPart=”False” => Ne pas utiliser le WebPart Standard
• WebPartOrder=”1″ => Le WebPart sera placé en premier dans la zone de WebParts (il n’y en aura qu’un dans la page de toute manière)

Ce qui donne :

<Form Type=”NewForm” Url=”NewForm.aspx” Path=”NewForm.aspx” WebPartZoneID=”Main” Default=”TRUE” UseDefaultListFormWebPart=”False” WebPartOrder=”1″>

</Form>

Nous allons ensuite ajouter le WebPart de type ListFormWebPart dans la page NewForm.aspx pour afficher le formulaire standard. Il existe plusieurs méthodes que vous retrouverez sur Google, Bing ou autre.

Pour ma part, je vais choisir une méthode moins traditionnelle qui consiste à placer ce WebPart directement dans la déclaration de l’association du formulaire d’ajout d’élément et notre page custom (toutes les méthodes sont possible, celle-ci n’est pas meilleure !… juste différente). Nous allons ajouter un tag <WebParts> directement dans le <Form/> précédent, qui contiendra la déclaration du WebPart de type ListFormWebPart. Certains ont déjà du croiser ce type de déclaration, très utilisé lorsqu’on déploie des pages web avec des Modules. On obtiendra :

<Forms>
…
<Form Type=”NewForm” Url=”NewForm.aspx” Path=”NewForm.aspx” WebPartZoneID=”Main” Default=”TRUE” UseDefaultListFormWebPart=”False” WebPartOrder=”1″>
<WebParts>
<AllUsersWebPart WebPartZoneID=”Main” WebPartOrder=”1″>
<![CDATA[
<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
<Assembly>Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
<TypeName>Microsoft.SharePoint.WebPartPages.ListFormWebPart</TypeName>
<PageType>PAGE_NEWFORM</PageType>
</WebPart>]]>
</AllUsersWebPart>
</WebParts>
</Form>
</Forms>

On déclare ici un WebPart de type Microsoft.SharePoint.WebPartPages.ListFormWebPart dans la zone “Main”. Notez également le tag PageType qui a la valeur PAGE_NEWFORM indiquant qu’il s’agit bien de ce WebPart dans le mode de rendu “New” (nouvel élément). Vous trouverez ici les valeurs possibles pour cette énumération : http://msdn.microsoft.com/fr-fr/library/microsoft.sharepoint.pagetype(v=office.12).aspx

On reproduit cela pour chacun des formulaires, sur nos listes Villes et Commandes :

Mais me direz-vous, nous avons copié les pages NewForm, DispForm et EditForm avec SharePoint Designer et ce WebPart devrait être déjà présent dans les pages… Oui tout à fait, c’est pour cela que nous allons le supprimer !

On ouvre donc un à un chacun des fichiers NewForm.aspx, EditForm.aspx et DispForm.aspx (pour les listes Villes et Commandes) et on recherche :

<WebPartPages:ListFormWebPart runat=”server” __MarkupType=”xmlmarkup” ……… </WebPartPages:ListFormWebPart>

On sélectionne le tout et on supprime tout le contenu de cet élément (l’élément y compris) :

On sauvegarde le tout.

Pour préciser pourquoi on ne conserve pas ce WebPart dans les pages, vous avez peut être remarque qu’il possédait la propriété ListId. Malheureusement, cette propriété est valorisée avec un GUID qui représente l’identifiant unique de la liste… et qui sera différent à chaque redéploiement de notre Solution. Impossible donc de packager ce composant directement avec le bon GUID. Vous pourrez par contre utiliser l’attribut ListName valorisé avec l’url relative de la liste.

Il nous reste à compiler, déployer… Pour vérifier que les fichiers sont bien déployés et écrasent bien les fichiers natifs, il faut changer un peu le contenu de la page (le bon vieux test du TOTO dans la page )…

Pour cela, j’ai choisi le formulaire NewForm.aspx de la liste de Commandes. Dans le ContentPlaceHolder “PlaceHolderPageTitle”, j’ajoute un TOTO :

On compile avec Visual Studio et on déploie sur notre plateforme SharePoint. Une fois le tout déployé, je me dirige vers ma liste de Commandes dans le navigateur, je clique sur nouveau :

On retrouve bien le TOTO dans le titre de la fenêtre !!! (Bien sûr on supprime le TOTO et on redéploye).

Ca c’est fait.

3/ Modifier le comportement des pages

Nos pages étant maintenant déployées, nous allons modifier leur héritage natif pour les faire hériter de classes contenues dans notre propre assembly (DLL). Pour cela, nous allons créer une classe C# pour chacun des pages NewForm, DispForm & EditForm, et ce pour chacune de nos listes (donc 6 classes dans mon cas).

En général, je créé un répertoire Pages à la racine de mon projet (les pages sont compilées dans la DLL et le fichier .cs n’est pas déployé). Une fois le dossier créé, j’ajoute 6 classes :

Ensuite, nous allons faire hériter chacune de ces classes de “WebPartPage” et ajouter “using Microsoft.SharePoint.WebPartPages” :

Ensuite, dans chacune des pages aspx, nous allons :

• Ajouter tout au début :  <%@ Assembly Name=”$SharePoint.Project.AssemblyFullName$” %>
• Modifier le Inherits pour pointer vers notre assembly :

Inherits=”Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint, Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c”

devient

Inherits=”DEMO1.Pages.CommandesNewForm,$SharePoint.Project.AssemblyFullName$”

Où :

• DEMO1.Pages.CommandesNewForm = Namespace + nom de la classe
• $SharePoint.Project.AssemblyFullName$ : nom complet de l’Assembly, valorisé par Visual Studio avant le déploiement.

On recommence la manipulation sur chacune des 6 pages aspx:

On compile/déploie à nouveau le tout. Pour tester que le code-behind est bien appelé, on peut passer en debug sur la solution et vérifier que la méthode OnLoad() est bien appelée :

Et voilà !

Je me décide enfin à publier cet article…, je continuerai la suite un peu plus tard ! Au programme, personnalisation du comportement des formulaires !

Wait & see (pas trop longtemps j’espère ) !

[Kazoumoulox] – Statistiques de fin d’année 2012

La fin de l’année approche… elle est même déjà là !

Il est temps de faire une petite synthèse sur l’année 2012 :

• 32 posts
• 84 posts en 3 ans
• 80Mo d’images/captures d’écran
• Meilleur jour : 24 juillet 2012, 93 visites dans la journée
• Article le plus consulté ce jour là :  SP2013–UserProfile Active Directory Import
• Articles les plus consultés en 2012 :
  1. SP2010 – Créer le service de recherche par Powershell – Part 1
  2. SharePoint 2010 & Visual Studio 2012–Step 1–Installation de Visual Studio 2012
  3. SharePoint 2010 & Visual Studio 2012–Step 2–Nouveautés & Ma première définition de liste
  4. Installation de SharePoint Server 2013
  5. SP2010 – Configurer Search Server avec PowerShell – Part 2
• Au total : 15 618 vues
• 42 commentaires
• Vues par pays sur l’année 2012 :

1. France : 6966
2. Tunisie : 432
3. Suisse : 274
4. Canada : 256
5. Belgique : 218

Vous pouvez consulter le report annuel ici : http://kazoumoulox.wordpress.com/2012/annual-report/

Objectif pour 2013… Faire mieux !!!

Je vous souhaite de très bonnes fêtes à tous… see you next year !