PowerShell SharePoint pour automatiser les tâches

Le PowerShell SharePoint permet d’automatiser les tâches relatives à SharePoint : création de collections de sites, etc.

Les premières lignes des scripts PowerShell SharePoint débutent par une ligne ou deux qui ressemblent plus ou moins à :

Add-PSSnapin « Microsoft.SharePoint.PowerShell »

ou bien à:

[Reflection.Assembly]::LoadWithPartialName(« Microsoft.SharePoint »)

Notamment, ces deux instructions chargent les fonctions de l’assembly du PowerShell SharePoint.

Si vous êtes un développeur .Net, vous savez déjà ce qu’est un assembly. Pour un administrateur récemment converti au PowerShell SharePoint, c’est certainement moins évident.

L’objet de cet article est de présenter très succinctement le rôle et l’intérêt d’un assembly pour un public de débutant en matière de développement Net. En complément, vous pouvez lire l’article moins technique sur les commandes PowerShell SharePoint.

PowerShell SharePoint : principes généraux de l’assembly

Physiquement, un assembly est un fichier .DLL ou .EXE. L’idée derrière l’assembly est de mettre à disposition un code partageable entre différentes applications. C’est le même principe que pour les anciens fichiers DLL des systèmes d’exploitations Windows qui n’utilisent pas le Framework .Net.

Toutefois, la comparaison s’arrête là car les différences sont nombreuses.

En effet, les assemblies présentent de nombreux avantages supplémentaires notamment en matière de sécurité, fiabilité et robustesse. Des fonctionnalités supplémentaires, comme par exemple le déploiement côte-à-côte (vu plus bas), permettent aussi de pallier aux faiblesses des anciennes DLL.

Dans la plupart des cas, l’assembly est physiquement dans le Global Assembly Cache (GAC). Le rôle du GAC est de partager les assemblies entre les applications. Une assembly qui n’est pas présente dans le GAC peut fonctionner parfaitement pour une application donnée.

Si le développeur veut partager son travail, son assembly devra être dans le GAC afin de communiquer avec des applications d’autres domaines, d’autres processus ou d’autres ordinateurs.

Bien évidemment, l’assembly peut être appelé par un script PowerShell SharePoint, un programme écrit dans du code géré (C# ou VB Net), etc.

Common Language Runtime (CLR)

Cette communication est faite sous le contrôle du Common Language Runtime NET (CLR).

Nativement, l’explorateur Windows ne permet pas d’afficher les dossiers du GAC comme d’habitude. Pour avoir un affichage classique du contenu du GAC, ouvrez une invite de commande en tant qu’administrateur et tapez:

regsvr32 /u C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\shfusion.dll

Si shfusion.dll se trouve dans le dossier v2.0.50727 qui correspond à la version du socle .Net : c’est probablement le cas.

En particulier, une fois la commande exécutée avec succès, vous pouvez explorer les dossiers du GAC avec l’explorateur Windows classique. Les dossiers principaux du GAC sont:

  • C:Windows\assembly
  • C:Windows\Microsoft.NET

Puis, pour revenir ensuite à un affichage natif, tapez dans une invite de commande:

regsvr32 C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\shfusion.dll

Pour connaître la liste précise des assemblies chargées au moment de l’exécution d’une commande PowerShell, ouvrez une invite de commande PowerShell en tant qu’Administrateur puis tapez la commande:

[appdomain]::currentdomain.getassemblies()

Microsoft Intermediate Language (MSIL)

Un fichier d’assembly englobe des ressources. En particulier, le manifeste et le code Microsoft Intermediate Language (MSIL).

Notamment, le manifeste est un fichier qui décrit l’assembly à travers des métadonnées comme par exemple le nom de l’assembly, sa version, sa culture, les autorisations de sécurité sous lesquelles l’assembly doit s’exécuter ou la liste des assemblies dépendants.

En particulier, la culture concerne les usages en termes de formatage de dates, de monnaies, etc (http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.aspx).

Par ailleurs, un programme peut utiliser une version d’un assembly tandis qu’un autre programme peut s’appuyer sur une version différente du même assembly sur le même ordinateur. C’est le déploiement côte à côte.

Le code MSIL n’est pas directement exécutable par un système d’exploitation comme Windows. Il doit être compilé en code natif pour être compris par le système d’exploitation.

Cette compilation peut être faite au fur et à mesure de l’appel des méthodes grâce à un compilateur Jusi-In-Time (JIT) fourni par le Common Language Runtime NET (CLR).

Le code natif peut aussi être généré par anticipation en une fois afin d’améliorer les performances de l’application.

Code source C#

Voici un exemple d’un code source en C#. Bien évidemment, vous pouvez aussi prendre un script en PowerShell SharePoint.

PowerShell SharePoint
Hello World C#

Le résultat en MSIL (extrait):

PowerShell SharePoint
Hello World MSIL

Aller plus loin avec le Net et le PowerShell SharePoint

Il est difficile de faire un tri dans toutes les ressources proposées sur le socle Net tant elles sont nombreuses et bien faites.

Toutefois, vous trouverez, dans les pointeurs ci-dessous, des informations pour démarrer en douceur un développement Net mais sur des bases solides:

Pour mettre en pratique, vous pouvez aussi suivre notre tutoriel qui explique, pas à pas, comment créer un WebPart Hello World avec Visual Studio.

Vous pouvez aussi consulter l’article suivant qui est spécifique au PowerShell SharePoint Découvrir comment utiliser PowerShell avec SharePoint.

Pour aller plus loin

Notamment, découvrez Les commandes PowerShell de SharePoint 2013.

Commentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *