services - sharepoint web api
Desarrollar elementos web de SharePoint en ASP.NET (10)
¿Hay algún motivo en particular por el cual los controles de usuario se deben implementar como elementos web? Es perfectamente factible implementar controles de usuario directamente en sitios Sharepoint a través de la carpeta CONTROLTEMPLATES en la sección 12 o en una ubicación en el directorio virtual de la aplicación web, que luego puede hacer referencia desde páginas web utilizando Sharepoint Designer.
Sin embargo, si el requisito de la parte web es crucial, recomiendo Smartpart para Sharepoint como ya se mencionó.
Se me ha pedido que desarrolle algunos controles de usuario en ASP.NET que luego se incluirán en un sitio de SharePoint como elementos web. Soy nuevo en SharePoint y no tendré acceso a un servidor de SharePoint durante el tiempo que necesito prototipar estas partes.
¿Alguien sabe de alguna razón por la cual este enfoque no funcionará? Si no se recomienda este enfoque, ¿qué otras opciones serían? ¿Alguna sugerencia sobre un recurso / tutorial sobre qué considerar al desarrollar un elemento web ASP.NET con SharePoint en mente?
Gracias
Editar: 31/12/2008 Finalmente marqué una respuesta a esta. Me tomó un tiempo darme cuenta de que ir por la ruta de SharePoint de inmediato, aunque doloroso al principio, es la mejor manera de hacerlo. La imagen de VPC gratuita hace que la configuración se desarrolle de manera relativamente indolora.
Mientras que usted puede, como lo hice, desarrollar elementos web en ASP.NET sin SharePoint, cuando se trata de desarrollar y desplegar aplicaciones de SharePoint, no ha aprendido nada, solo aleja la curva de aprendizaje en un momento en que cree que ha terminado , (y probablemente hayan informado a las partes interesadas a tal efecto). Retrasar la curva de aprendizaje de SharePoint no le favorece a usted ni a su proyecto, y su producto final será mejor para la experiencia que gane en el camino.
Configurar mi máquina para desarrollar para Sharepoint me llevó un par de días.
Ver http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
Cree y pruebe el control como lo haría para un sitio web .net típico. Solución 1 = los controles Solución 2 = sitio web ficticio para alojar los controles.
Despliegue en Sharepoint:
Deberá firmar los controles.
Coloque la DLL firmada en el GAC en el servidor de SharePoint (Windows / ensamblado)
Marque el control como seguro en la raíz del servidor virtual web.config en el sitio sharepoint.
es decir
<SafeControl Assembly="MyControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=975cc42deafbee31" Namespace="MyNamespace" TypeName="*" Safe="True" AllowRemoteDesigner="True" />
Registre el componente en su página sharepoint:
<%@ Register Namespace="MyNamespace" Assembly="MyControl, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=975cc42deafbee31" TagPrefix="XXXX" %>
Usa el control:
<XXXX:ClassName runat="server" Field1="Value1" Field2="Value2" ....></XXXX:Classname>
Si necesita reemplazar el control con el mismo número de versión, deberá reciclar el grupo de aplicaciones para volver a cargarlo.
En realidad, los elementos web siempre deben desplegarse en la carpeta bin de Sharepoint debido a su naturaleza "abusiva". Siempre despliegue las partes web en el contenedor si es posible y escriba su propio CAS e inclúyalo en su manifiesto.
Los elementos web ASP.NET funcionan en SharePoint de la misma manera que funcionan en ASP.NET. Esa es la ruta que tomaría (control personalizado que deriva de la clase de elemento web ASP.NET ). Esto aliviará cualquier requisito para desarrollar realmente en un servidor de SharePoint.
El único problema con el que se encontrará es que no podrá aprovechar el marco de SharePoint. Si está haciendo algo avanzado en SharePoint, esto es un gran problema. Sin embargo, SharePoint es ASP.NET más alguna funcionalidad adicional, por lo que cualquier cosa que pueda desarrollar utilizando la clase System.Web.UI.WebControls.WebPart debería funcionar de maravilla en SharePoint.
Algunas consideraciones que le ayudarán a aliviar su dolor a medida que pasa de pura ASP.NET a SharePoint:
- Si puede poner todo dentro de un solo ensamblaje, la implementación será más fácil
- intente poner todo lo que necesita en las DLL que se implementan en SharePoint
- utilice los recursos de ensamblaje para incrustar JS, CSS y archivos de imagen si es necesario
- Nombre fuerte la asamblea que estás construyendo
- La mayoría de las implementaciones de SharePoint terminan en el GAC y se requerirá un nombre seguro
Aquí hay una publicación de blog relevante; Desarrollo de elementos web básicos en SharePoint 2007
No necesita SharePoint para desarrollar WebParts. Puede desarrollar partes web heredando desde System.Web.UI.WebControls.WebParts. Y esta es la forma preferible de crear elementos web a menos que desee las siguientes características, como
* Connections between web parts that are outside of a Web Part zone
* Cross page connections
* A data caching infrastructure that allows caching to the content database
* Client-side connections (Web Part Page Services Component)
En ese caso, debe desarrollar las partes web heredando de Microsoft.SharePoint.WebPartpages.WebPart. Puedes encontrar más información útil aquí
Si no necesita hacer nada específico de SharePoint (es decir, acceder a listas, otras partes web, etc.), entonces puede compilar su Webpart como un elemento web normal (derivado de la clase System.Web.UI.WebControls.WebParts.WebPart) y Funcionará cuando se agregue a un sitio de SharePoint.
Si se trata de algo a muy corto plazo, Microsoft tiene una imagen VPC de evaluación de WSS por tiempo limitado:
WSS3 SP1 Developer Evaluation VPC image
Eso lo ayudará a comenzar si no tiene tiempo ni recursos para configurar su propia imagen de VPC en este momento.
Supongo que la forma más fácil es usar SmartPart for SharePoint desde CodePlex. La descripción del proyecto dice "El elemento web de SharePoint que puede alojar cualquier control de usuario web ASP.NET . ¡Cree sus elementos web sin escribir código!", Que supongo que es exactamente lo que quiere hacer.
necesita tener acceso a un servidor sharepoint porque no puede simular su webpart sin él, tiene que implementarlo en su sitio sharepoint para probar si está funcionando. la depuración también sería un dolor. o puede usar SmartPart, es un elemento web que actúa como un contenedor para que los controles de su usuario se muestren en un sitio sharepoint.