Recientemente en mi proyecto actual que ya está en fase de producción, nos hemos visto en la necesidad de realizar cambios sobre la página maestra y sobre los layouts.
En nuestro proyecto las páginas maestras y los layouts los desplegamos mediante una feature que entre otras muchas cosas carga en la librería de páginas maestras, nuestros layouts y páginas maestras personalizadas.
Ante la posibilidad de desplegar de nuevo nuestra feature en producción cuando todo está funcionando debidamente, Enrique Blanco me comentaba que modificando nuestra página maestra, que desplegamos mediante una feature, en la carpeta
12/features/nombrefeature/Mi.master
Y haciendo un “iisreset”, los cambios se verían reflejados en MOSS, yo no creía que esto fuese a funcionar, pero ya ves, una vez mas MOSS me quitó la razón.
Es decir yo mediante una feature desplego mi página maestra y una serie de layouts, que se almacenan en la librería de páginas maestras, y realizando una modificación directamente sobre los ficheros de la feature y reiniciando ISS, la librería de páginas maestras se actualiza a partir de los ficheros contenidos en la carpeta de la feature.
Yo siempre pensé que esto lo almacenaba en BBDD, que cuando tu mediante una feature generabas un nuevo elemento en, por ejemplo, la librería de páginas maestras, este nuevo elemento lo almacenaba en BBDD, pero bueno así se demuestra que al arrancar el ISS, MOSS tiene en cuenta los elementos de la librería de páginas maestras y genera una estructura en memoria teniendo en cuenta el origen de cada elemento que esté Ghosted y actualizándolos con respecto a su origen físico en vez de respecto a BBDD que serían los elementos UnGhosted.
Ya investigando un poco más fruto de mi cabezonería ante las cosas que no se comportan como yo creo, me he dado cuenta que la forma en que aprovisionamos archivos mediante una feature, la única que yo conozco, esta es la forma en que nuestra feature los despliega:
<Module Name="AddMasters" Url="_catalogs/MasterPage" RootWebOnly="TRUE">
<File Url=”[Mi.master]" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE" >
<Property Name="ContentType" Value="[tipoContendio ]" />
<Property Name="PublishingPreviewImage" Value="" />
<Property Name="MasterPageDescription" Value="[descripcion]" />
</File>
</Module>
Al especificar que el tipo de archivo es GhostableInLibrary, especificamos que este archivo existe físicamente, por lo tanto es lógico que los cambios realizados sobre el archivo físico se vean reflejados en la estructura de MOSS.
Evidentemente cuando cargamos elementos en la librería de páginas maestras, todos esos elementos deben ser GhostableInLibrary ya que los aprovisionamos mediante un fichero.
Es más si borramos la carpeta de la feature que contiene nuestra master, MOSS muestra un error y el fichero de log:
w3wp.exe (0x1310) 0x0D64 Windows SharePoint Services General 72ks Medium Cannot get ghost document: Features\NombreFeature\NuevoLayout.aspx
w3wp.exe (0x1310) 0x0D64 Windows SharePoint Services General 8e2s Medium Unknown SPRequest error occurred. More information: 0x80070002
En el que indica que se ha producido un error al acceder al elemento “Ghosted”, en este caso mi layout, en la ruta de la carpeta que lo despliega.
Moraleja: hay que tener bien clarito que implica que algo esté Ghosted o Unghosted :
Y de propina otra hablando acerca del rendimiento de las páginas Ghosted y Unghosted de Mario Cortés:
(EDITADO)Y otro enlace mas: