Archive

Posts Tagged ‘Web.Config’

Gestion du Web.config – Bonnes pratiques et pièges à retenir


En guise de conclusion à cette série de billet concernant la gestion du Web.config, voici quelques bonnes pratiques et pièges à éviter concernant la gestion du Web.config.

Bonnes pratiques

  1. Ne pas modifier le contenu du Web.config manuellement à moins d’y être forcé par une situation particulière (voir la partie 6);
  2. Pour ajouter un élément au Web.config de l’ensemble des applications Web, utilisez la technique présentée à la partie 2;
  3. Pour ajouter un élément au Web.config d’un seul application Webm utilisez la technique présentée à la partie 3;
  4. Pour ajouter un « safe control » ou une règle CAS, utiliser le manifest.xml de la solution Sharepoint tel que présentée à la partie 4;
  5. Pour les « AppSetting », dans la mesure du possible, utiliser une seule manière normalisée pour l’ensemble des paramètres des applications Web;

Pièges à retenir

L’utilisation de la classe SPWebConfigModification est sujet à quelques problèmes résumés ci-dessous et très bien expliqués dans l’article de Reza Alirezaei :

  1. La documentation est faible;
  2. Lorsqu’on applique un changement à l’aide de SPWebConfigModification, le changement s’applique sur l’ensemble des zones de l’application Web, Lorsqu’on retire le changement, ce dernier est retiré seulement sur la zone Defaut et il faut retirer les éléments à la main sur les autres zones;
  3. Il n’est pas possible de faire un changement sur une seule zone;
  4. Si on utilise EnsureSection, les changements ne seront pas retirés;
  5. SPWebConfigModification ne peut pas être utilisé pour ajouter certains éléments tel que : assemblyBinding;
  6. L’instruction
    SPFarm.Local.Services.GetValue<SPWebService>().ApplyWebConfigModifications(); ne fonctionne pas, il faut plutôt utilisé l’instruction webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

L’utilisation de la commande stsadm -o copyappbincontent effacera les modifications manuelles apportées au Web.config.

Publicités

Gestion du Web.config – partie 6


Dans les parties précédentes, je vous ai présenté différentes techniques pour modifier différents éléments du Web.config. Le point commun de ces techniques : le Web.config n’est jamais modifié à la main par un administrateur.

Malheureusement, dans certaines situations il n’est pas possible de faire autrement que d’apporter une modification manuelle au Web.config.

Supposons un site Web sous Sharepoint visible sur internet (Gestion de contenu Web). Ce site se matérialise dans Sharepoint par un application Web comportant 2 zones. La première (Défaut) sera utilisée pour l’administration de l’application Web. Cette zone est normalement accessible en mode authentifié (NTLM ou Kerberos par exemple). La seconde zone (Internet) sera accessible par l’internaute qui normalement est anonyme ou en mode « Forms ». Chaque zone est en fait un site Web différent dans IIS et possède son propre Web.config.

L’extrait suivant présente une partie du Web.config de la zone par défaut :

...
    <authentication mode="Windows" />
    <identity impersonate="true" />
    <authorization>
      <allow users="*" />
    </authorization>
...

Le second extrait présente une partie du Web.config de la zone internet :

...
    <authentication mode="Forms">
      <forms name=".ASPXAUTH" timeout="5" loginUrl="/GererAuthentification/FormulaireAuthentification.aspx" protection="All" slidingExpiration="true" />
    </authentication>
    <identity impersonate="false" />
    <authorization>
      <allow users="*" />
    </authorization>
...

Il n’est pas possible d’utiliser les techniques présentées dans les parties 2 et 3 car les modifications s’appliqueraient aux 2 zones. On doit donc se rabattre sur la modification manuelle. Il serait intéressant que Microsoft apporte des améliorations à la classe SPWebConfigModification dans un prochain service pack ou dans la prochaine version du produit pour répondre à cette situation.

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,

Gestion du Web.config – partie 5


Cette partie présente différentes réflexions concernant la paramètre de type « AppSetting ». À ma connaissance, pour ce qui est de ce type d’élement, on a le choix des solutions. Dépendant des circonstances, vous serez donc tenter de choisir entre les techniques présentées dans les billets précédents.

Il serait donc possible d’ajouter un « AppSetting » globalement à l’ensemble des applications Web au moyen de la technique présentée dans la partie 2. Par la suite, ajouter un autre « AppSetting » spécifique à un application Web au moyen de la technique présentée dans la partie 3. Par la suite, d’autres features pourraient aussi ajouter d’autres « AppSetting » au Web.config au gré de leurs activation. Vous voyez que ça risque de devenir rapidement un problème. 

Une manière unique de procéder serait préférable. Pour ce faire, je vous recommande de jeter un coup d’oeil sur le Sharepoint Config Store publié sur CodePlex par Chris O’brien.

Sur certains projets, j’ai vu des systèmes de gestions de paramètres corporatif. Ce genre de système s’applique à l’ensemble des applications de l’entreprise. Lorsque placé dans une situtation semblable, c’est évidemment une bonne idée d’utiliser le système en place car cela comporte de nombreux avantages pour le projet et l’organisation.

Ce n’est ni blanc, ni noir pour les éléments « AppSetting » et encore une fois Sharepoint nous offre plusieurs façons différentes pour arriver à notre fin. Une bonne réflexion s’impose lors des travaux d’implantation du produit pour définir les façons de faire de l’organisation.

Ne vous gêner surtout pas pour commenter si vous avez des éléments intéressants à ajouter. Je serai le premier intéressé à les lire et la communauté aussi par la suite.

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,

Gestion du Web.config – partie 4


Dans cette partie, je vous présente comment enregistrer un assembly en tant que « safe control » dans le Web.Config.

Certains parlent d’ajouter manuellement les lignes nécessaires dans le Web.Config. D’autres parlent d’utiliser SpWebConfigModification tel que discuter dans la partie 3 de cette série d’article. Ces deux propositions feront le travail mais nécessitent plus d’efforts que la technique que je vous présente ici.

La meilleure façon d’enregistrer un assembly en tant que que « safe control » dans le Web.Config est d’inscrire les instructions nécessaires dans le fichier manifest.xml de la solution Sharepoint (.wsp) qui sera utilisée pour déployer votre assembly.

Voici un exemple très simple d’un manifest.xml qui ne fait que déployer un assembly dans l’application Web et enregistrer ce dernier en tant que « safe control ».

<Solution SolutionId="{d718f72f-567f-4b15-bed4-140b18daf58f}" xmlns="http://schemas.microsoft.com/sharepoint/">
	<Assemblies>
		<Assembly DeploymentTarget="WebApplication" Location="nom_assembly.dll">
			<SafeControls>
				<SafeControl Assembly="nom_assembly, Version=1.0.0.0, Culture=neutral,
				PublicKeyToken=151c9ce4fd83003a" namespace="nom_du_namespace" TypeName="*" Safe="True" />
			</SafeControls>
		</Assembly>
	</Assemblies>
</Solution>

 La documentation relative au fichier manifeste est disponible à l’adresse suivante : http://msdn.microsoft.com/fr-ca/library/ms442108.aspx. La documentation relative au solution Sharepoint (wsp) est disponible à l’adresse suivante : http://msdn.microsoft.com/fr-ca/library/ms413687.aspx.

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,

Gestion du Web.config – Partie 3


Pour modifier le contenu du Web.config d’un application Web, la meilleure technique consiste à utiliser le modèle objet et d’ajouter les modifications dans la collection WebConfigModifications de l’objet SPWebApplication.

Pour ce faire, je recommande de créer un feature de scope : WebApplication. Ceux qui ne sont pas familier avec le concept de feature peuvent retrouver la documentation dans l’aide en ligne de MSDN à l’adresse suivante : http://msdn.microsoft.com/en-us/library/ms460318.aspx

Le fichier feature.xml ci-dessous vous présente une exemple simple d’un feature de scope WebApplication.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="{DF82E481-709B-4918-A8A8-0CB65C37A297}"
         Scope="WebApplication"
         Title="FeatureFullTrust"
         Description="Modification au Web.Config de l'application Web pour changer le trust level à Full."
         Hidden="FALSE"
         AlwaysForceInstall="TRUE"
         ActivateOnDefault="FALSE"
         ReceiverAssembly="ProjetFulltrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ec016fc89f371d43"
         ReceiverClass="ProjetFulltrust.FeatureFullTrust">
</Feature>

Ce feature, possède un ReceiverAssembly qui est dans le GAC. Dans le cas qui nous occupe, l’assembly est constitué d’une seule classe FeatureFullTrust. Cette classe implémente SPFeatureReceiver tel que présenté ci-dessous.

Imports Microsoft.SharePoint
Imports Microsoft.SharePoint.Administration

Public Class FeatureFullTrust
    Inherits SPFeatureReceiver

    ''' <summary>
    ''' Modification du noeud Trust du Web.Config de la WebApp pour y changer la valeur pour "Full"
    ''' </summary>
    Public Overrides Sub FeatureActivated(ByVal properties As Microsoft.SharePoint.SPFeatureReceiverProperties)
        Dim webApp As SPWebApplication = DirectCast(properties.Feature.Parent, SPWebApplication)
        Dim modif As SPWebConfigModification = New SPWebConfigModification("level", "configuration/system.web/trust")
        modif.Owner = "FeatureFullTrust"
        modif.Sequence = 0
        modif.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute
        modif.Value = "Full"

        webApp.WebConfigModifications.Add(modif)
        webApp.Farm.Services.GetValue(Of SPWebService)().ApplyWebConfigModifications()
        webApp.Update()

    End Sub

    ''' <summary>
    ''' Retrait de la modification sur le noeud Trust du Web.Config de la WebApp
    ''' </summary>
    Public Overrides Sub FeatureDeactivating(ByVal properties As Microsoft.SharePoint.SPFeatureReceiverProperties)

        Dim webApp As SPWebApplication = DirectCast(properties.Feature.Parent, SPWebApplication)

        For Each modif As SPWebConfigModification In webApp.WebConfigModifications
            If modif.Owner = "FeatureFullTrust" AndAlso modif.Name = "level" Then
                webApp.WebConfigModifications.Remove(modif)
                webApp.Update()
                webApp.Farm.Services.GetValue(Of SPWebService)().ApplyWebConfigModifications()
            End If
        Next

    End Sub

    Public Overrides Sub FeatureInstalled(ByVal properties As Microsoft.SharePoint.SPFeatureReceiverProperties)
    End Sub

    Public Overrides Sub FeatureUninstalling(ByVal properties As Microsoft.SharePoint.SPFeatureReceiverProperties)
    End Sub

End Class

Il ne reste qu’à empaqueter notre feature en solution, la déployer dans la ferme et activer la feature pour l’application Web désirée. Sharepoint se chargera de mettre à jour le Web.config sur tous les serveurs de la ferme.

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,

Gestion du Web.Config – partie 2


Pour appliquer une modification à tous les Web.config de l’ensemble des applications Web Sharepoint, il existe deux techniques.

La première consiste à créer un fichier XML dans le répertoire C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\config.  Le fichier doit se nommer webconfig.[partie_descriptive].xml. Le fichier doit être déposé sur chaque serveur de la ferme. L’image ci-dessous vous présente les fichiers qui se trouve de base dans le répertoire de Sharepoint.

repertoire_12_config

Voici un exemple très simple qui modifie le trust level à Full.

<?xml version="1.0" encoding="utf-8" ?>
<actions>
<update path="configuration/system.web">
<trust level="Full" originUrl="" />
</update>
</actions>

Il est aussi possible d’ajouter (add) et d’enlever (remove) des éléments du Web.config. Notez que pour le add et le remove, il est fortement suggérer d’ajouter un id tel que présenter dans l’exemple ci-dessous. L’id est utilisé par Sharepoint pour qu’il ne fasse pas les modifications en double dans le Web.config

 <add path="configuration" id="{de21698f-16f3-46a1-879c-d00acd7b5678}">
  <appSettings />
 </add>

Lors de la création d’un application Web, le Web.config contiendra automatiquement vos ajustements. Pour les applications Web existantes, il faut lancer la commande stsadm -o copyappbincontent sur chaque serveur de la ferme.

Vous trouverez d’autres exemples dans les fichiers qui viennent de base avec le produit et sur le net notamment dans le blog de Gaëtan Bouveret (en français).

La seconde technique consiste à utiliser le modèle objet et d’ajouter les modifications dans la collection WebConfigModifications de l’objet SpWebService. Vous trouverez un exemple complet dans l’aide en ligne de MSDN à l’adresse suivante : http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,

Gestion du Web.Config – Partie 1


Après 3 semaines de vacances, je suis de retour reposé et prêt à continuer la diffusion de connaissances relatives à Sharepoint.

Débutons donc avec un sujet qui fait souvent jaser.  En effet sur les projets, on se pose souvent la question suivante : « Comment on fait pour modifier ou ajouter un élément dans le fichier Web.Config de l’application Web ».

Les prochains billets qui seront mis en ligne graduellement dans les prochains jours expliqueront donc comment faire lorsqu’on rencontre les situations suivantes :

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,
%d blogueurs aiment cette page :