SharePoint 2007 : Et si on intégrait une vraie application ASP.Net dedans ?
C'est un peu la question de ma journée dans la WygTeam.
Imaginer que vous vouliez installer et deployer une belle application ASP.Net dans un site SharePoitn 2007, WSS v3 ou MOSS 2007 d'ailleurs ?
L'idée générale étant de pouvoir partager l'adresse du serveur web collaboratif ainsi que son DNS lors de Démo/Présentation
Mais ce scenario irait trés bien aussi dans des problématiques d'intégration de plus haut niveau entre un Portail Communeautaire MOSS et une appli CRM ou de eTV.
Sous SharePoint 2007, l'ajout d'un "virtual folder" sous IIS ne pose plus de soucis vu aue le filtre ISAPI a laisser la place à de sympathiques HTTPHandler et HTTPModule.
SharePoitn 2007 étant désormais une VRAI application ASP.Net 3.0
Donc, il suffit :
- ouvrir la console IIS
- créer un "virtual folder" dans le site We b SharePoint correspondant
- lui donner un pool applicatif personnel (ou celui par défaut)
Et voila, votre site ASP.Net simple est en ligne
Genre, une petite page avec un peu de code inline fonctionne à merveille.
Mais ce ne seras pas le cas d'une application un peu plus "Advance" genre.
- Membership
- WebPart
- Ajax Extender
- Skinning
- ASP.Net 2
- Custom Section
- ...
(Oui je sais, il y a des codeurs bien furieux dans le team)
Et oui, la, ca coince car le site SharePoint risque de vous bloquer !!!
A vrai dire, il ne bloque pas mais le Web.config de racine du site IIS fait un </Clear> de certaines noeuds comme les Httpmodules. Style, pas d'accés au Session.
Dés lors, plus de soucis, il vous suffit de les rajouter en reprenant par exemple les configurations par défaut du framework (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG)
<httpModules>
<add name="OutputCache" type="System.Web.Caching.OutputCacheModule" />
<add name="Session" type="System.Web.SessionState.SessionStateModule" />
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<add name="PassportAuthentication" type="System.Web.Security.PassportAuthenticationModule" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule" />
<add name="AnonymousIdentification" type="System.Web.Security.AnonymousIdentificationModule" />
<add name="Profile" type="System.Web.Profile.ProfileModule" />
<add name="ErrorHandlerModule" type="System.Web.Mobile.ErrorHandlerModule, System.Web.Mobile, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<add name="ServiceModel" type="System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</httpModules>
Et voila, seulement, il reste encore une étape
>>> la couche de sécurité peut aussi bloquer certaines couches d'exécution (ahhh le CAS)
Donc penser bien à rajouter des régles de CAS pour vos appels SQL ou tout autre namespace bien utile sinon votre application bloquera !
(remarque : pour les plus pressé, augmenter juste le niveau de Trust à Full, ca marche trés bien mais c'est moins propre/best practice)
Ensuite, tout reviens en ordre 
.
Renaud Comte aka TheMit (Comment ca ??? SP il résiste, mais non, il s'impose, c'est pas pareil)
Member of WygTeam
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
