none
PageLayout cambia al desplegarse desde VS2010 - Sharepoint 2010 RRS feed

  • Pregunta

  • Hola a todos,

    Estoy desplegando un PageLayout desde VS, pero luego de desplegarlo, voy a revisarlo y el marcado es diferente al que tengo en el VS2010, no entiendo porque pasa esto, pense que a lo mejor habia un problema en mi archivo aspx, he eliminado todo el contenido y aun asi, al desplegarse, voy a revisarlo en designer y ha agregado muchas cosas que en mi archivo aspx de VS no tengo, alguien sabe cual puede ser el problema?

    Mi aspx en VS esta asi:

    codigo de mi archivo aspx en VS2010

    Luego de desplegarlo voy a revisar en Designer y el marcado ahora es el siguiente:

    Se me ocurre que el problema esta en el Elements, pero logro detectarlo

    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
      <Module Name="PageLayouts" Url="_catalogs/masterpage">
        <File Path="PageLayouts\TestHomeLayout.aspx" Url="TestHomeLayout.aspx" Type="GhostableInLibrary" >
          <Property Name="Title" Value="Test home layout"/>
          <Property Name="MasterPageDescription" Value="Diseño de pagina home" />
          <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;" />
          <Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/DefaultPageLayout.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/DefaultPageLayout.png"/>
          <Property Name="PublishingAssociatedContentType" Value=";#$Resources:cmscore,contenttype_welcomepage_name;;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4;#"/>
        </File>
      </Module>
    </Elements>

    No entiendo porque pasa este comportamiento, a alguien le ha pasado? es que puedo estarme equivocando?

    Un saludo.


    • Editado Maikrhode jueves, 17 de octubre de 2013 17:55
    jueves, 17 de octubre de 2013 17:53

Respuestas

  • Hola Marikr86,

    El tema de los PageLayout es uno de los aspectos más delicados y más si los llevamos a la hora de despliegues. Te cuento un poco mi experiencia, si lo que realizas es estas desarrollando y continuamente despliegas tu solución encontraras continuos errores porque porque por ejemplo si asignas un pagelayout a una pagina, en el momento de retirar tu solución ya no lo puedes hacer debido a que esta asignada a una página. De la misma forma en la que haces cuando lo realizas de forma manual.

    Ahora bien como poder trabajar de una forma "mantenible" con el tema de los PageLayouts, pues la primera de todas es empaquetarlos una vez los tienes implementados tal y como toca. Y para posterior modificaciones sobre el mismo hacer uso de comandos PowerShell para realizar estas modificaciones, o bien realizarlas mediante Designer en caso de tener un solo entorno. 

    En caso de trabajar con SharePoint 2013 tiene una herramienta que realiza esta labor por ti y es que extrae todos los paquetes de diseño, aunque hay que andarse con mucho ojo dependiendo lo que se esta haciendo porque no es tan maravilloso como parece. Esta muy bien y es mucho mejor que no tener nada.

    Saludos,

     


    MCPD SharePoint 2010 Mi blog: http://blogs.encamina.com/desarrollandosobresharepoint Twitter: @AdrianDiaz81

    sábado, 19 de octubre de 2013 15:09
  • Hola Maikr86.

    No deberías preocuparte por los elementos añadidos ya que por lo que veo, lo que te ha puesto de más son elementos para compatibilidad con versiones anteriores de SharePoint.

    Si te funciona correctamente, no le des muchas vueltas y, si no quieres tenerlo de esa forma, edita directamente el archivo en SharePoint después de desplegarlo.


    "En los momentos de crisis, sólo la imaginación es más importante que el conocimiento"
    MCTS | SharePoint 2010, Application Development
    MCTS | SharePoint 2010, Configuring
    MS | Programming in HTML5 with JavaScript and CSS3 (MS), Developing ASP.NET MVC 4 Web Applications
    Twitter | @saintwukong

    viernes, 15 de noviembre de 2013 0:19
    Moderador
  • Muy buenas Maikr86.

    Creo que lo que te está pasando es lo siguiente. Cuando despliegas un diseño de página o una página maestra desde Visual Studio, éste se guarda físicamente en el sistema de archivos de SharePoint, es decir, bajo la carpeta 14 ó 15 según se trate de SharePoint 2010 ó 2013. Y en la base de datos de la colección de sitios lo que se guarda es una referencia hacia donde se encuentra físicamente guardado el archivo, pero no el archivo en sí. Es lo que se conoce como archivos "uncostumized". Hasta aquí todo correcto. Lo que ocurre, es que si una de estas páginas maestras o de diseño la editas después con SharePoint Designer (o bien subes un archivo que la "machaca" por tener el mismo nombre desde la interfaz de usuario), la página maestra o de diseño, pasa a guardarse completamente en la base de datos de la colección de sitios, y no el "puntero" hacia donde está el archivo.  Es lo que se conoce como archivos "customized".

    Cuando ASP.NET recibe una petición del archivo, este por definición busca primero en base de datos. Es por ello, que siempre te traerá el archivo "customized", si existe. Y es por ello, que los cambios que hagas volviendo a publicar el diseño de página, o página maestra desde Visual Studio, no los va a ver, por que una vez que pasas el archivo al estado "customized" este digamos que tiene preferencia por ser el "camino más corto". SharePoint te está mostrando el archivo que está en base de datos, no el que está en el sistema de archivos. Y eso es lo que te está pasando a ti.

    De hecho SharePoint Designer te avisa y te pide confirmación cuando vas a editar un archivo en estado "uncostomized", y posteriormente indica que ha pasado a estado "customized" con una bolita azul, al lado del nombre del archivo. Para volver el archivo al estado "uncostomized", si no recuerdo mal, desde Designer, botón derecho sobre el archivo en sí, tienes la opción "Reset to site Definition". Pero importante, perderías los cambios que hayas hecho desde Designer, y te trearía el archivo tal cual está en el sistema de archivos.

    La buena práctica, por cuestiones de rendimiento y demás, es tener páginas maestras y demás, en el sistema de archivos. El problema que tiene esto, es que por cada cambio que se quiera hacer, ya no puedes recurrir a Designer, si no que tienes que volver a desplegar el paquete entero.

    Si quieres más información al respecto, quizá te interesen los siguientes enlaces:

    http://tinyurl.com/cef55o3

    http://www.slideshare.net/SolidQ/branding-en-sharepoint-2010-trucos-y-buenas-prcticas

    http://msdn.microsoft.com/en-us/library/cc406685(v=office.12).aspx

    Espero que haya sido de ayuda. Un saludo.

    miércoles, 27 de noviembre de 2013 13:03

Todas las respuestas

  • He cambiado el nombre del archivo aspx, y ahora despliega bien, pero si realizo cambios sobre mi ASPX y vuelvo a desplegar desde VS, los cambios no se actualizan, es como que el deploy de VS no hace check out y check in sobre la pagina aspx, entonces que pasa si quiero modificar mi layout? xq VS no me lo actualiza?

    jueves, 17 de octubre de 2013 18:52
  • Hola Marikr86,

    El tema de los PageLayout es uno de los aspectos más delicados y más si los llevamos a la hora de despliegues. Te cuento un poco mi experiencia, si lo que realizas es estas desarrollando y continuamente despliegas tu solución encontraras continuos errores porque porque por ejemplo si asignas un pagelayout a una pagina, en el momento de retirar tu solución ya no lo puedes hacer debido a que esta asignada a una página. De la misma forma en la que haces cuando lo realizas de forma manual.

    Ahora bien como poder trabajar de una forma "mantenible" con el tema de los PageLayouts, pues la primera de todas es empaquetarlos una vez los tienes implementados tal y como toca. Y para posterior modificaciones sobre el mismo hacer uso de comandos PowerShell para realizar estas modificaciones, o bien realizarlas mediante Designer en caso de tener un solo entorno. 

    En caso de trabajar con SharePoint 2013 tiene una herramienta que realiza esta labor por ti y es que extrae todos los paquetes de diseño, aunque hay que andarse con mucho ojo dependiendo lo que se esta haciendo porque no es tan maravilloso como parece. Esta muy bien y es mucho mejor que no tener nada.

    Saludos,

     


    MCPD SharePoint 2010 Mi blog: http://blogs.encamina.com/desarrollandosobresharepoint Twitter: @AdrianDiaz81

    sábado, 19 de octubre de 2013 15:09
  • Hola Maikr86.

    No deberías preocuparte por los elementos añadidos ya que por lo que veo, lo que te ha puesto de más son elementos para compatibilidad con versiones anteriores de SharePoint.

    Si te funciona correctamente, no le des muchas vueltas y, si no quieres tenerlo de esa forma, edita directamente el archivo en SharePoint después de desplegarlo.


    "En los momentos de crisis, sólo la imaginación es más importante que el conocimiento"
    MCTS | SharePoint 2010, Application Development
    MCTS | SharePoint 2010, Configuring
    MS | Programming in HTML5 with JavaScript and CSS3 (MS), Developing ASP.NET MVC 4 Web Applications
    Twitter | @saintwukong

    viernes, 15 de noviembre de 2013 0:19
    Moderador
  • Muy buenas Maikr86.

    Creo que lo que te está pasando es lo siguiente. Cuando despliegas un diseño de página o una página maestra desde Visual Studio, éste se guarda físicamente en el sistema de archivos de SharePoint, es decir, bajo la carpeta 14 ó 15 según se trate de SharePoint 2010 ó 2013. Y en la base de datos de la colección de sitios lo que se guarda es una referencia hacia donde se encuentra físicamente guardado el archivo, pero no el archivo en sí. Es lo que se conoce como archivos "uncostumized". Hasta aquí todo correcto. Lo que ocurre, es que si una de estas páginas maestras o de diseño la editas después con SharePoint Designer (o bien subes un archivo que la "machaca" por tener el mismo nombre desde la interfaz de usuario), la página maestra o de diseño, pasa a guardarse completamente en la base de datos de la colección de sitios, y no el "puntero" hacia donde está el archivo.  Es lo que se conoce como archivos "customized".

    Cuando ASP.NET recibe una petición del archivo, este por definición busca primero en base de datos. Es por ello, que siempre te traerá el archivo "customized", si existe. Y es por ello, que los cambios que hagas volviendo a publicar el diseño de página, o página maestra desde Visual Studio, no los va a ver, por que una vez que pasas el archivo al estado "customized" este digamos que tiene preferencia por ser el "camino más corto". SharePoint te está mostrando el archivo que está en base de datos, no el que está en el sistema de archivos. Y eso es lo que te está pasando a ti.

    De hecho SharePoint Designer te avisa y te pide confirmación cuando vas a editar un archivo en estado "uncostomized", y posteriormente indica que ha pasado a estado "customized" con una bolita azul, al lado del nombre del archivo. Para volver el archivo al estado "uncostomized", si no recuerdo mal, desde Designer, botón derecho sobre el archivo en sí, tienes la opción "Reset to site Definition". Pero importante, perderías los cambios que hayas hecho desde Designer, y te trearía el archivo tal cual está en el sistema de archivos.

    La buena práctica, por cuestiones de rendimiento y demás, es tener páginas maestras y demás, en el sistema de archivos. El problema que tiene esto, es que por cada cambio que se quiera hacer, ya no puedes recurrir a Designer, si no que tienes que volver a desplegar el paquete entero.

    Si quieres más información al respecto, quizá te interesen los siguientes enlaces:

    http://tinyurl.com/cef55o3

    http://www.slideshare.net/SolidQ/branding-en-sharepoint-2010-trucos-y-buenas-prcticas

    http://msdn.microsoft.com/en-us/library/cc406685(v=office.12).aspx

    Espero que haya sido de ayuda. Un saludo.

    miércoles, 27 de noviembre de 2013 13:03