Développement | SharePoint by Benoît Jester (Asipe)

MVA Live Events : Developing SharePoint Server 2013 Core Solutions Jump Start

octobre 17, 2013 spasipe Laisser un commentaire

Pour changer, un titre en anglais pour annoncer un « Live Event » dédié au développement d’applications sous SharePoint 2013.

Je vous résume le contenu de la page officielle :

for professional developers who develop solutions for SharePoint products and technologies
You’ll get some guidelines and best practices that will help you optimize your SharePoint applications. You’ll see some cool demos that will show you how to create an app, deploy it to a catalog, and install it.
This Jump Start will help you prepare for Exam 70-488

Des « cool demos », c’est bien, ce qui est moins cool … C’est la plage horaire, parceque le 25 octobre de 9h à 17h çà correspond pour nous à …

… 18h à 2h du mat’.

Un bon moyen de démarrer votre w-e du 25 octobre 2013 avec 1 litre de café dans le sang !

Catégories :Développement, SharePoint 2013 Étiquettes : 70-488, formation, MVA, SharePoint 2013

SharePoint 2013 : Préparer la migration des développements spécifiques

Mai 3, 2013 spasipe 1 commentaire

Cet article fait partie d’un ensemble d’articles traitant de la migration d’environnements SharePoint (2007 et 2010) vers SharePoint 2013.

La page d’accueil de cette série d’articles se trouve ici : Comment migrer sous SharePoint 2013 ?

Nous allons voir dans cet article comment se préparer à la migration des développements SharePoint, ou en tout cas voir quelques points intéressants dans le cadre d’une migration de développements spécifiques vers SharePoint 2013.

Introduction

Les migrations SharePoint – et celle vers 2013 n’échappe pas à la règle – sont l’occasion de passer un coup d’aspirateur à vos développements SharePoint : migration, adaptation, nettoyage ou suppression de parties du code, la présence de dévs spécifiques offre toujours son lot de « surprises ».

Les sujets traités dans cet article sont les suivants :

Suis-je préparé pour ces migrations ?
Quoi de neuf avec cette double structure 14/15 ?
Quoi de neuf concernant le GAC ?
Si je déploie un WSP développé pour SharePoint 2007, est-ce que çà fonctionne ?

Point 1 : Suis-je préparé pour ces migrations ?

La première question à se poser c’est: « Ai-je bien en ma possession tout ce qui va me permettre de préparer/modifier/réinstaller mes dévs sur ma ferme SharePoint 2013 » :

Documentation d’installation,
Sources des projets,
Descriptif du contenu des projets – Pour savoir si on utilise encore telle ou telle fonctionnalité, ou si elle peut être remplacée par une fonctionnalité « standard » de SharePoint 2013,
Et une question subsidiaire : suis-je certain que ce qui se trouve dans mon GAC et dans mon 12/14 provient bien du déploiement de mes WSP et non de copies effectuée « à la mano ».

Les points 2 et 4 sont probablement les plus « rigolos », surtout quand on se rend compte à la réinstallation que ce qui est déployé ne correspond pas aux sources, et on se retrouve à faire du Reflector pour comparer le code, voir même pour tenter de reconstruire le code quand on a pas les sources. Du bonheur.

Point 2 : Quoi de neuf avec cette double structure 14/15 ?

Comme vous le savez peut-être déjà, SharePoint 2013 supporte nativement SharePoint 2010 (voir l’article « SharePoint 2013 : Focus sur la coexistence avec SharePoint 2010« ).

Cette coexistence se traduit « physiquement » par la présence d’un répertoire « 14 » (SP2010) et d’un répertoire « 15 » (SP2013). Si cette fonctionnalité peut s’avérer bien pratique à l’usage, elle ne vas pas sans poser problème; en effet si vous jetez un n’oeil dans IIS, vous observez que des répertoires virtuels supplémentaires sont créés pour le « 15 » :

Le problème induit est que les références faites dans votre code à « /_layouts/…. » pointent sur l’arborescence de SharePoint 2010, et non celle de SharePoint 2013, que vous déployiez dans le le 14 ou dans le 15.

Toujours en rapport avec ces répertoires, si vous utilisez la méthode « SPUtility.GetGenericSetupPath », sachez que celle-ci est désormais obsolète :

Et doit être remplacée par « SPUtility.GetVersionedGenericSetupPath » dans le cadre de SharePoint 2013 :

Point 3 : Quoi de neuf concernant le GAC ?

Si vous savez déjà développé sous SharePoint, le mot « GAC » doit maintenant faire partie de votre vocabulaire courant. Avec cette nouvelle release de SharePoint, les choses changent concernant son utilisation, puisque du à l’utilisation de .Net 4 les assemblies sont désormais gérées en 2 endroits (dans 2 GAC).

Le GAC voit donc désormais double : un gére le CLR 2.0 (.NET 2.0 et 3.5) et un autre le CLR 4.0 (.Net 4 et +), ce mécanisme étant conçu pour éviter les conflits entre les 2.

Extrait de l’article Understanding The CLR Binder :

Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime

La localisation des dll se fait donc soit :

Dans « C:\Windows\Assembly » pour les assemblies basées sur une version de .net <= à 3.5

Dans « C:\Windows\Microsoft.NET\Assembly » pour les assemblies basées sur une version de .net > à 3.5 (SharePoint 2013, donc)

Point 4 : Si je déploie un WSP développé pour SharePoint 2007, est-ce que çà fonctionne ?

Pour cet exemple je génère un WSP depuis un serveur SharePoint 2007 à l’aide de Visual Studio 2008.

Le projet (simple) contient les éléments suivants :

Un texte qui affiche le résultat de « GetGenericSetupPath » sur le répertoire « TEMPLATE\IMAGES »,
Le déploiement d’une image dans le 14/15,
Une feature déployant une WebPart affichant cette image depuis le répertoire « _layouts/Images » ainsi que depuis le répertoire « _layouts/15/Images »,

Un EventReceiver qui se déclenche lorsqu’un item de liste est ajouté, et qui modifie son titre,

Une dll dans le GAC.

Dans un premier temps, j’ajoute et déploie le WSP via PowerShell mais sans préciser de paramètre « CompatibilityLevel », résultat : tout fonctionne, et c’est l’image du « 14 » qui est affichée.

La raison est que si vous ne précisez pas de « CompatibilityLevel », le déploiement va se baser sur le paramètre « SharePointProductVersion » (inexistant, 14 ou 15) présent dans le manifest de la solution.

Dans un deuxième temps, j’ajoute et déploie le WSP via PowerShell avec le paramètre « CompatibilityLevel » à « 15 », résultat : tout fonctionne, et c’est bien l’image du « 15 » qui est affichée.

Par contre, la dll est toujours dans le GAC « Old School » (C:\Windows\Assembly) – Ce qui est normal étant donné qu’elle a été compilée en .Net 2.0 et que ce n’est pas le paramètre « CompatibilityLevel » qui va y changer quoi que ce soit.

Conclusion

Nous avons vu dans cet article quelques-uns des (nombreux !) points à prendre en compte dans le cadre de migrations spécifiques vers SharePoint 2013.

Bien sûr, ces points sont triviaux en comparaison des migrations de code qui peuvent être … Bippppp