GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Desarrollo de Web Parts en SharePoint 2010: Introducción


El desarrollo de las Web Parts en SharePoint 2010 es uno de los puntos más relevantes dentro del mundo del desarrollo de aplicaciones para SharePoint. El presente artículo realiza una breve introducción, en la que se intenta dar una explicación de qué son las Web Parts, así como se describen varios aspectos importantes del desarrollo de Web Parts en SharePoint 2010, e incluso se incluye un poco de código fuente de ejemplo.

Uno de los puntos más importantes en el desarrollo de aplicaciones para SharePoint 2010 es sin duda el desarrollo de Web Parts, por lo que en esta ocasión, vamos a aprovechar para crear un breve artículo de introducción, que sin mayor ambición, pueda servir de ayuda o de recordatorio a muchos de nosotros.

Introdución a las Web Parts en SharePoint 2010

Las Web Parts son controles ASP.NET del lado del Servidor que se ejecutan bajo el contexto de un Página de Web Parts (Web Part Page), las cuales tienen Zonas de Web Parts (Web Part Zones) que actúan como contenedores (Placeholders) y permiten a los usuarios editar y modificar los controles utilizando el navegador.

Dado que las Web Parts se ejecutan bajo el contexto de una página y bajo el contexto de seguridad del usuario que accede a la página, la misma Web Part puede mostrar distinta información en función del usuario que accede a la página, incluso accediendo a diferentes orígenes de datos externos (ej: Reporting Services, Analysis Services, etc) sin tener que volver a introducir las credenciales.

Cada página de Web Parts tiene:

  • Zonas de Web Parts (Web Part Zones), que son contenedores de controles que pueden hospedar ninguna, uno o varias Web Parts.
  • Web part manager, un objeto que lleva un registro de qué Web Parts han sido añadidas a cada Zona de Web Parts, y almacena información sobre cómo ha sido personalizada cada Web Part.

Podemos decir que SharePoint 2010 soporta dos tipos de Web Parts:

  • ASP.NET 2.0 Web Parts, que derivan de System.Web.UI.WebControls.WebParts.WebPart. Utilizan directamente las clases el ASP.NET WebPartManager y WebPartZones. Como regla general, siempre deberemos crear este tipo de Web Parts.
  • SharePoint web parts, que derivan de Microsoft.SharePoint.WebPartPages.WebPart. Utilizan las clases SPWebPartManager y SPWebPartZone, que heredan de las correspondientes clases de ASP.NET. Son proporcionadas con propósitos de compatibilidad hacia atrás y para algún caso excepcional. No está recomendado heredar de estas clases, excepto bajo ciertas circunstancias (ej: cross page connections, comunicación de web parts entre zonas, etc.).

Visual Web Parts para Soluciones de Granja (Farm Solutions)

Antes de continuar, es interesante recordar que en el pasado, no había una forma visual o gráfica de desarrollar Web Parts con Visual Studio, por lo que algunos desarrolladores creaban controles ASP.NET (es decir, ASP.NET Web User Controls, ficheros *.ascx) de forma visual con Visual Studio, para seguidamente construir un wrapper para utilizar los controles ASCX desde una Web Part, o bien utilizar un Wrapper existente como el conocido SmartPart for SharePoint (AKA Return of SmartPart).

Afortunadamente, con SharePoint 2010 todo esto es mucho más fácil, ya que Visual Studio 2010 introduce diseñadores gráficos para desarrollar Web Parts. Es decir, en un Proyecto de Visual Studio 2010 para SharePoint 2010, podremos agregar un nuevo Item de tipo Visual Web Part.

Visual Studio 2010 introduce diseñadores gráficos para desarrollar Web Parts. Es decir, en un Proyecto de Visual Studio 2010 para SharePoint 2010, podremos agregar un nuevo Item de tipo Visual Web Part

Realmente, lo que Visual Studio 2010 va a hacer por nosotros, es crear un ASP.NET Web User Control (*.ascx) sobre el cual tendremos la posibilidad de desarrollar de forma gráfica (añadir controles con el ratón, etc.) a la vez que creará automáticamente un Wrapper (en nuestro caso de ejemplo, la clase TestVisualWebPart) que heredará de la clase WebPart, por lo que no es necesario utilizar el SmartPart ni hacernos nosotros uno propio. Vamos, que una Visual Web Part es simplemente una Web Part que hospeda a un ASP.NET User Control.

Una Visual Web Part es simplemente una Web Part que hospeda a un ASP.NET User Control

Visual Studio desplegará el ASP.NET Web User Control por debajo de la carpeta 14 hive, tal y como se muestra en la siguiente pantalla capturada, por lo tanto una Visual Web Part sólo puede utilizarse en una Solución de tipo Granja (es decir, no es posible en una Solución Sandbox).

Una Visual Web Part sólo puede utilizarse en una Solución de tipo Granja

Visual Studio también nos creará una clase (en nuestro caso de ejemplo es el fichero TestVisualWebPart.cs), que heredará de System.Web.UI.WebControls.WebParts.WebPart. Esta es realmente nuestra Web Part, y en ella se sobrescribe el método CreateChildControls para cargar el ASP.NET Web User Control.

En nuestra Web Part se sobrescribe el método CreateChildControls para cargar el ASP.NET Web User Control

Igualmente, Visual Studio también nos creará un fichero *.webpart, en el cual podremos especificar información como el nombre y descripción de nuestra Web Part.

Visual Studio también nos creará un fichero *.webpart, en el cual podremos especificar información como el nombre y descripción de nuestra Web Part

En términos generales, podríamos decir que el desarrollo de una Visual Web Part es como el desarrollo de un ASP.NET Web User Control, es decir, ahora podemos dibujar nuestros controles con el diseñador, añadir los eventos que deseemos (ej: el OnClick de un botón), etc. Francamente sencillo.

Soluciones de Granja (Farm Solutions), Web Parts y Controles Seguros (Safe Controls)

Cuando desarrollamos una Web Part para desplegarla a nivel de Granja, necesitamos marcarla como un Control Seguro (Safe Control), es decir, debemos modificar el fichero Web.Config de la Aplicación Web de SharePoint en la que deseamos utilizar la Web Part, para añadir una entrada de tipo SafeControl. Afortunadamente, Visual Studio 2010 hace este trabajo por nosotros. Si seleccionamos nuestra Web Part en nuestra Solución de Visual Studio, y mostramos sus Propiedades (F4), podremos acceder a la opción Safe Control Entries.

Cuando desarrollamos una Web Part para desplegarla a nivel de Granja, necesitamos marcarla como un Control Seguro (Safe Control), es decir, debemos modificar el fichero Web.Config. Si seleccionamos nuestra Web Part en nuestra Solución de Visual Studio, y mostramos sus Propiedades (F4), podremos acceder a la opción Safe Control Entries.

Dentro de la opción Safe Control Entries, podremos ver que ya aparece una entrada correspondiente a nuestra Web Part, sin que nosotros tuviésemos que hacer nada especial previamente.

Dentro de la opción Safe Control Entries, podremos ver que ya aparece una entrada correspondiente a nuestra Web Part, sin que nosotros tuviésemos que hacer nada especial previamente

Además, si desplegamos nuestra Solución de Visual Studio, y tras esto editamos el fichero Web.Config, podremos ver que se ha añadido dicha línea al Web.Config.

Si desplegamos nuestra Solución de Visual Studio, y tras esto editamos el fichero Web.Config, podremos ver que se ha añadido dicha línea al Web.Config

De hecho, si eliminamos dicha línea del Web.Config e intentamos utilizar nuestra Web Part, obtendremos un error como el siguiente:

De hecho, si eliminamos dicha línea del Web.Config e intentamos utilizar nuestra Web Part, obtendremos un error como el siguiente

Utilizar configuraciones del Web.Config: secciones appSettings y connectionStrings

Una forma bastante habitual de guardar configuraciones en aplicaciones de SharePoint, ya sea para ser utilizadas por Web Parts o bien por otros elementos que estemos desarrollando, es utilizando el fichero Web.Config, de forma similar a como se haría con cualquier otra aplicación ASP.NET. Esto tiene varias consideraciones:

  • Al modificar el fichero Web.Config, se descargará de memoria el App Pool, lo cual en algunas Granjas de SharePoint puede implicar que se produzca una indisponibilidad, más o menos prolongada en el tiempo.
  • Una Aplicación Web tiene un único Web.Config, por lo tanto, si tenemos varios Sites y necesitamos un valor de configuración diferente para cada Site, deberemos guardar una variable distinta en el Web.Config para cada Site, o bien, descartar el Web.Config y buscar otra alternativa para almacenar nuestras configuraciones.
  • El fichero Web.Config es un fichero XML, por lo que deberemos almacenar cifrada cualquier información sensible, como cadenas de conexión, usuarios y contraseñas, etc, evitando de este modo introducir nosotros mismos una vulnerabilidad en nuestros sistemas.
  • En las Soluciones Sandboxed no tenemos acceso al Web.Config, por lo que deberemos buscar otra alternativa para almacenar nuestras configuraciones.

Lo más común, es utilizar las secciones appSettings y/o connectionsStrings del Web.Config, aunque hay más formas de utilizar el Web.Config. En resumidas cuentas:

  • La sección appSettings (configuration -> appSettings) permite almacenar parejas de clave/valor, permitiendo almacenar cualquier configuración que deseemos.
  • La sección connectionStrings (configuration -> connectionStrings) se introdujo en .Net Framework 2.0 con la intención de ser utilizado únicamente para almacenar cadenas de conexión en el Web.Config, a diferencia de la sección appSettings que resulta mucho más general.

A continuación se muestra un ejemplo de uso de dichas secciones en un Web.Config:

Ejemplo de uso de las secciones appSettings y connectionsStrings en un Web.Config

Para poder consultar la sección connectionStrings desde el código fuente de nuestra Web Part, deberemos añadir una referencia al assembly System.Configuration (Project > Add Reference > Add System.Configuration). Además, es también recomendable importar los tipos definidos en el espacio de nombres System.Web.Configuration (ej: using System.Web.Configuration). Realizado esto, podremos consultar las secciones appSettings y connectionSettings utilizando la clase WebConfigurationManager (disponible desde .Net Framework 2.0), tal y como se muestra en el siguiente ejemplo:

Como leer valores de las secciones appSettings y connectionsStrings de un Web.Config desde nuestro código utilizando la clase WebConfigurationManager

En esto ejemplo, conseguiremos mostrar en dos etiquetas de una Web Part, el contenido de ambas configuraciones del Web.Config, tal y como podemos ver a continuación:

En esto ejemplo, conseguiremos mostrar en dos etiquetas de una Web Part, el contenido de ambas configuraciones del Web.Config

Otro tema a tratar es cómo modificar el Web.Config desde una Solución de Visual Studio, de tal modo, que podamos añadir al Web.Config las configuraciones que necesitan nuestras Web Parts antes de que las utilicen, evitando tener que realizar manualmente dichas modificaciones del Web.Config. Una forma de conseguirlo es por código, a través de un Event Receiver que se ejecute al Activar una Característica (FeatureActivated). De este modo, utilizando la colección WebConfigModifications, podemos añadir las modificaciones que deseamos realizar sobre el Web.Config, para seguidamente aplicarlas, es decir, que tomen efecto. Sería un trozo de código parecido al siguiente (ojo, la propiedad Owner es texto libre, podemos poner lo que queramos, y sirve que podamos hacer un tracking de nuestras modificaciones, frente a las modificaciones de otras aplicaciones):

Cómo modificar el Web.Config desde una Solución de Visual Studio. Una forma de conseguirlo es por código, a través de un Event Receiver que se ejecute al Activar una Característica (FeatureActivated). De este modo, utilizando la colección WebConfigModifications, podemos añadir las modificaciones que deseamos realizar sobre el Web.Config, para seguidamente aplicarlas

Hay un tema importante. El contenido de la colección WebConfigModifications es persistente y se almacena en la Base de Datos de Configuración, por lo tanto, cada vez que activemos la característica, estaremos añadiendo una nueva entrada a esta colección. Esto nos puede generar valores repetidos. He visto casos de varios miles en entornos de producción de clientes reales.

El contenido de la colección WebConfigModifications es persistente y se almacena en la Base de Datos de Configuración, por lo tanto, cada vez que activemos la característica, estaremos añadiendo una nueva entrada a esta colección, pudiendo crearse valores repetidos

Por ello, deberemos preocuparnos de eliminar nuestras entradas del Web.Config, del mismo modo que nos preocupamos de añadirlas. Por ejemplo, podemos utilizar un Event Receiver que se ejecute al desactivar la Característica (FeatureDeactivating), para eliminar de la colección WebConfigModifications las entradas del Web.Config que ya no necesitamos. Esto lo podíamos hacer con un código como el siguiente, pero ojo, ya que es posible que nos encontremos con el error de Access Denied al intentar modificar el Web.Config desde SharePoint 2010.

Podemos utilizar un Event Receiver que se ejecute al desactivar la Característica (FeatureDeactivating), para eliminar de la colección WebConfigModifications las entradas del Web.Config que ya no necesitamos

Antes de continuar con el resto del artículo, aprovecho para colgar varios enlaces de interés, para quien desee ampliar más información:

Crear Propiedades en una Visual Web Part

Las Propiedades de las Web Parts, son una de las principales formas que tenemos para poder personalizarlas, ya que de este modo, podemos permitir que los usuarios puedan editar dichas Propiedades y asignarles los valores que deseen, que nuestra Web Part podrá utilizar a nuestro antojo.

Para poder crear una Propiedad en nuestra Web Part, deberemos crear una propiedad pública en la clase de la Web Part con ciertos atributos (Personalizable, WebBrowsable, WebDisplayName, WebDescription, Category). Realizado esto, el problema es cómo poder utilizar el valor de esta propiedad definida en la Web Part desde el ASP.NET Web User Control, dado que se trata de dos clases independientes. Una forma de solucionar esta situación, es creando una nueva propiedad pública en el ASP.NET Web User Control y asignarle el valor deseado en su creación dentro del método CreateChildControls.

Esto implica que el código de nuestra Web Part (TestVisualWebPart.cs) quedaría algo como lo que se muestra en la siguiente pantalla capturada.

Esto implica que el código de nuestra Web Part (TestVisualWebPart.cs) quedaría algo como lo que se muestra en la siguiente pantalla capturada

Del mismo modo, el código de nuestro ASP.NET Web User Control (TestVisualWebPartUserControl.ascx.cs) quedaría algo como lo que se muestra en la siguiente pantalla capturada.

Del mismo modo, el código de nuestro ASP.NET Web User Control (TestVisualWebPartUserControl.ascx.cs) quedaría así.

Realizado todo esto, si desplegamos ahora nuestra Web Part, al editarla podremos observar la nueva propiedad que acabamos de crear.

Realizado todo esto, si desplegamos ahora nuestra Web Part, al editarla podremos observar la nueva propiedad que acabamos de crear

WebBrowsable vs Personalizable

Los atributos WebBrowsable y Personalizable, generan ciertas dudas en su uso, tratándose de dos atributos bien diferenciados:

  • WebBrowsable. Permite que la propiedad pueda ser editada por los usuarios, apareciendo en el Toolbox. Sin embargo, no hace nada en relación con la persistencia de su valor.
  • Personalizable. Permite que el valor de la propiedad debe ser persistente.

Aunque ambos atributos suelen usarse juntos en muchos casos, es posible también usarlos de forma completamente independiente.

Conexiones entre Web Parts

Cabe la posibilidad de conectar un par de Web Parts, de tal modo, que una de ellas actúe como el Proveedor de Datos y la otra como el Consumidor de Datos, formando una relación Padre-Hijo ó Maestro-Detalle entre ellas. Es decir, al seleccionar un elemento en el Web Part que actúa como Padre o Maestro, podremos filtrar automáticamente el contenido de la Web Part Hijo o Detalle.

Esta funcionalidad sólo está disponible en Soluciones de Granja, es decir, no la tenemos en Soluciones Sandboxed, por lo que podemos utilizar Visual Web Parts o las Web Parts tradicionales (sin diseñador gráfico ni ASP.Net User Control), como deseemos.

Por lo que he leído (yo no llego a estos detalles), hay dos tipos de conexiones que pueden ser utilizadas entre las Web Parts:

  • Conexiones Estáticas. Requiere codificar una Web Part no-ASP.Net, es decir, que derive de la clase Microsoft.SharePoint.WebPartPages.WebPart. Su caso de uso típico es cuando al menos una de las Web Parts no reside en una Web Part Zone, algo que quizás no es muy habitual pero que podría ocurrir, o también cuando se desea establecer la información de la conexión entre ambas Web Parts en el código HTML/ASPX de la Página.
  • Conexiones Dinámicas. Pueden ser codificadas con Web Parts ASP.Net, y en este caso, ambas Web Parts residen en alguna Web Part Zone. Quizás es el caso más habitual, en el cual, un usuario puede de forma gráfica editar una Web Part y conectarla con otra Web Part, de forma dinámica.

A continuación, vamos a presentar un ejemplo del desarrollo de un par de Web Parts ASP.Net conectables entre sí, en particular de un par de Visual Web Parts, con sus correspondientes ASP.Net User Controls.

Lo primero que deberemos crear es una Interfaz (IMasterProvider) con una Propiedad de sólo lectura (MasterID), que será implementada por el Proveedor de Datos (la Web Part que actúa como Padre o Master) y usada por el Consumidor de Datos (la Web Part que actúa como Hijo o Detalle).

Lo primero que deberemos crear es una Interfaz (IMasterProvider) con una Propiedad de sólo lectura (MasterID), que será implementada por el Proveedor de Datos

Seguidamente deberemos crear una Visual Web Part que actúe como Web Part Padre o Master (VisualMasterWP), el Proveedor de Datos. Esta Web Part debe implementar la anterior Interfaz (IMasterProvider). Contiene el correspondiente ASP.Net User Control (VisualMasterWPUserControl), con un DropDownList configurado con la propiedad AutoPostBack a True. Otro detalle, es que la clase de la Web Part (VisualMasterWP) debe incluir un método que devuelve el anterior Interfaz (y en su interior un simple return this) etiquetado con la propiedad/atributo ConnectionProvider, para que SharePoint detecte el rol de esta Web Part en la conexión, especificando como parámetro el texto que queremos que muestre SharePoint en la Conexión (ver más abajo, el pantallazo cuando probamos las Web Parts). En consecuencia, el código de la Web Part (VisualMasterWP) quedaría algo así.

Seguidamente deberemos crear una Visual Web Part que actúe como Web Part Padre o Master (VisualMasterWP), el Proveedor de Datos

Del mismo modo, el código del ASP.Net User Control de la Web Part (VisualMasterWPUserControl) quedaría algo así.

Del mismo modo, el código del ASP.Net User Control de la Web Part (VisualMasterWPUserControl) quedaría algo así

Una Visual Web Part que actúe como Web Part Hijo o Detalle (VisualDetailWP), el Consumidor de Datos. Esta Web Part debe usar la anterior Interfaz (IMasterProvider). Contiene el correspondiente ASP.Net User Control (VisualDetailWPUserControl), con una etiqueta (Label) en la que actualizar su contenido en función del valor seleccionado en el Combo de la Web Part que actúa como Padre. La clase de la Web Part (VisualDetailWP) debe incluir un método que espera como parámetro un objeto que implemente la anterior Interfaz (IMasterProvider) etiquetado con la propiedad/atributo ConnectionConsumer, para que SharePoint detecte el rol de esta Web Part en la conexión, especificando como parámetro el texto que queremos que muestre SharePoint en la Conexión (ver más abajo, el pantallazo cuando probamos las Web Parts). Este es el mecanismo para intercambiar información entre ambas Web Parts, junto con el evento OnPreRender de la Web Part (este método se ejecuta después del método CreateChildControls), que sobrescribiremos para conseguir actualizar el valor de la Etiqueta (Label) de nuestra Web Part Hijo. En consecuencia, el código de la Web Part (VisualDetailWP) quedaría algo así.

Una Visual Web Part que actúe como Web Part Hijo o Detalle (VisualDetailWP), el Consumidor de Datos

Del mismo modo, el código del ASP.Net User Control de la Web Part (VisualDetailWPUserControl) quedaría algo así.

Del mismo modo, el código del ASP.Net User Control de la Web Part (VisualDetailWPUserControl) quedaría algo así.

Realizado todo esto, estaremos en situación de compilar y desplegar nuestra Solución de Visual Studio en nuestra Granja de SharePoint 2010, para a continuación añadir ambas Web Parts a una Página de SharePoint, y conectarlas.

Realizado todo esto, estaremos en situación de compilar y desplegar nuestra Solución de Visual Studio en nuestra Granja de SharePoint 2010

Una vez conectadas ambas Web Parts, podremos comprobar su funcionamiento. En nuestro caso de ejemplo, al seleccionar un elemento en el Combo de la Web Part que actúa como Padre o Master (VisualMasterWP), se actualizará el contenido de la etiqueta que tenemos en la Web Part que actúa como Hijo o Detalle (VisualDetailWP).

Una vez conectadas ambas Web Parts, podremos comprobar su funcionamiento. En nuestro caso de ejemplo, al seleccionar un elemento en el Combo de la Web Part que actúa como Padre o Master (VisualMasterWP), se actualizará el contenido de la etiqueta que tenemos en la Web Part que actúa como Hijo o Detalle (VisualDetailWP).

Las Visual Web Parts y las Soluciones Sandbox (Sandboxed Solutions)

Como acabamos de ver, una Visual Web Part no la podremos utilizar en una Solución Sandbox. Por lo tanto, si tenemos una Solución Sandbox y necesitamos añadir una Web Part ¿qué podemos hacer? En este caso, podemos utilizar Web Parts de sólo código (Code-Only Web Part), que si bien no ofrece la comodidad de un diseñador gráfico (tendremos que hacerlo todo por código, ya que en esta ocasión no tenemos un ASP.NET Web User Control embebido en la Web Part), por el contrario, podremos incluirla en una Solución Sandbox. De hecho, una Code-Only Web Part la podremos utilizar tanto en una Farm Solution como en una Sandboxed Solution.

Una Solución Sandbox (Sandboxed Solution) se ejecuta en un proceso aislado, por lo tanto, utilizando este tipo de Soluciones en lugar de las antiguas Soluciones de Granja (Farm Solutions), la Granja de SharePoint está expuesta a un menor riesgo, y además son compatibles con SharePoint OnLine (Office 365). Sin embargo, las Soluciones Sandbox (Sandboxed Solutions) tienen algunas limitaciones, como por ejemplo:

  • Las llamadas a Servicios Web (Web Services) no están soportadas.
  • No están disponibles todos los objetos, propiedades y métodos disponibles en el modelo de objetos. El IntelliSense puede ayudarnos ocultarnos los objetos, propiedades y métodos no disponibles, pero en cualquier caso, Visual Studio no lo comprobará hasta en tiempo de ejecución.
  • Sólo está permitido el acceso a los objetos SharePoint del mismo Site en el que está ejecutándose la Solución Sandboxed.

No obstante, existen algunas soluciones de terceros, que nos pueden facilitar el desarrollo visual de las Web Parts. Por ejemplo, podemos utilizar las Visual Studio 2010 SharePoint Power Tools disponible de forma gratuita en CodePlex, que nos añadirá una nueva Plantilla a Visual Studio 2010 denominada Visual Web Part (Sandboxed).

Web Parts de sólo código para Soluciones Sandbox (Sandboxed Solutions)

En este caso, al crear una Web Part de sólo código, no tendremos un ASP.NET Web User Control, por lo tanto, aunque igualmente deberemos sobrescribir el método CreateChildControls (ojo, aunque también sería posible sobrescribir los métodos Render y RenderContents, como norma general deberemos evitar utilizarlos), en esta ocasión utilizaremos dicho método para crear por código los Controles que deseamos que tenga nuestra Web Part, así como sus Eventos (Event Handlers).

En una Web Part de sólo código, no tendremos un ASP.NET Web User Control

Además, para los Eventos (Event Handlers) deberemos crear los correspondientes métodos capaces de responder a dichos eventos con el comportamiento que deseamos. Téngase en cuenta que podemos utilizar la colección Controls para acceder a los Controles de nuestra Web Part, y de este modo, obtener el valor de la propiedad Text de nuestras cajas de texto (TextBox), o lo que necesitemos. Igualmente, podemos ejecutar consultas CAML, y muchas cosas más.

Para los Eventos (Event Handlers) deberemos crear los correspondientes métodos. Téngase en cuenta que podemos utilizar la colección Controls para acceder a los Controles de nuestra Web Part

Realizada esta codificación, podremos desplegar nuestra Web Part, y comprobar su funcionamiento.

Realizada esta codificación, podremos desplegar nuestra Web Part, y comprobar su funcionamiento

Despliegue de las Web Parts en SharePoint 2010

Tenemos diferentes opciones para realizar el despliegue de las Web Parts en SharePoint 2010, las cuales pueden variar en función del tipo de Solución que estemos desarrollando (Sandboxed ó Farm).

Para las Soluciones Sandboxed deberemos subir nuestra solución a la Galería de Soluciones (Solution Gallery) de la Colección de Sitios en la que desees utilizarla.

Para las Soluciones Sandboxed deberemos subir nuestra solución a la Galería de Soluciones (Solution Gallery)

Para las Soluciones de Granja (Farm Solutions) podremos realizar el despliegue en dos ubicaciones distintas, lo cual, el relevante sobre el nivel de permisos bajo el que se ejecutará el assembly (DLL) y también indicará si se desplegará sobre toda la Granja o sobre un Aplicación Web en particular. Entrando en un poco más de detalle:

  • Global Assembly Cache (GAC). Es la opción por defecto en Visual Studio 2010. Al realizar el despliegue de este modo, la Solución estará disponible para todas las Aplicaciones Web de la Granja de SharePoint, ya que la DLL de la Solución será desplegada en la GAC, y por lo tanto, se ejecutará en modo Full Trust (algunas empresas no permiten que se desplieguen DLLs en la GAC, por motivos de seguridad).
  • Directorio BIN de la Aplicación Web. De este modo podemos realizar el despliegue sólo en las Aplicaciones Web en las que activemos la Característica (Feature) de nuestra Web Part, de tal modo, que la DLL será desplegada únicacamente a la Aplicación Web que deseemos, y además, por defecto se ejecutará en modo Minimal Trust (WSS_Minimal).

Muy importante tener en cuenta las políticas de CAS (Code Access Security), es decir, el nivel de permisos bajo el que se ejecuta un assembly, o dicho de otro modo, qué es lo que puede o no hacer nuestra Web Part. Por defecto, el Web.Config de una Aplicación Web de SharePoint indica que todo el código se debe ejecutar en modo Minimal Trust (WSS_Minimal) excepto los assemblies desplegados en la GAC (que se ejecutarán en modo Full Trust, es decir, barra libre de permisos). Este comportamiento se puede cambiar modificando el Web.Config. Recordemos que ASP.Net define los modos Full, High, Medium, Low y Minimal, a lo que SharePoint añade otros dos modos más: WSS_Minimal y WSS_Medium. Para más info, puede resultar interesante consultar el siguiente post de Luis Mañez (muy bueno): Trust Levels en ASP.NET y Sharepoint. También sería posible crear un nivel personalizado (ver Code Access Security in SharePoint), aunque es bastante habitual configurar el Web Config para utilizar el modo Full Trust (incluso aunque no sea la opción más recomendable).

Es en las Propiedades de nuestro Proyecto de Visual Studio 2010, donde podremos cambiar las opciones de despliegue de nuestra Solución.

Es en las Propiedades de nuestro Proyecto de Visual Studio 2010, donde podremos cambiar las opciones de despliegue de nuestra Solución

Despedida y Cierre

Hasta aquí llega el presente artículo, en el cual, hemos intentado realizar una introducción general del desarrollo de Web Parts para SharePoint 2010 con Visual Studio 2010, sin duda, una de las tareas más relevantes en el desarrollo de aplicaciones para SharePoint.

Por último, antes de acabar, tan sólo queda colgar un poco de código fuente para quien desee probarlo por sí mismo con Visual Studio 2010.

Descargar código de ejemplo en Visual Studio 2010 (Visual Web Part y Sandboxed Web Part)

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.

 


[Fecha del Artículo (UTC): 25/04/2014]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas