Assembly du PowerShell SharePoint et développement .Net

Les premières lignes des scripts PowerShell relatifs à 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 »)

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, 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.

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.

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:WINDOWSMicrosoft.NETFrameworkv2.0.50727shfusion.dll

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

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:Windowsassembly
  • C:WindowsMicrosoft.NET

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

regsvr32 C:WINDOWSMicrosoft.NETFrameworkv2.0.50727shfusion.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()

Fonctionnement de l’assembly

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

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.

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).

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 2008 R2. 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.

Exemple d’un code source en C#

hello-world-c#

Le résultat en MSIL (extrait):

hello-world-il

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

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 2010.

Laisser un commentaire

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