Développer des composants WebPart SharePoint dans ASP.NET [fermé]

Question

On m'a demandé de développer des contrôles utilisateur dans ASP.NET qui seront ultérieurement insérés dans un site SharePoint en tant que composants WebPart. Je suis nouveau dans SharePoint et je n’aurai pas accès à un serveur SharePoint tant que je devrai prototyper ces pièces.

Est-ce que quelqu'un connaît des raisons pour lesquelles cette approche ne fonctionnera pas? Si cette approche n'est pas recommandée, quelles seraient les autres options? Des suggestions sur une ressource ou un didacticiel sur les éléments à prendre en compte lors du développement d’un composant WebPart ASP.NET avec SharePoint en tête?

Merci

Modification: 31/12/2008 J'ai finalement marqué une réponse à celle-ci. Il m'a fallu un certain temps pour comprendre que choisir immédiatement la voie SharePoint, bien que pénible au début, était la meilleure façon de s'y prendre. L’image VPC gratuite rend la mise en place relativement facile à développer.

Vous pouvez, comme je l'ai fait, développer des composants WebPart dans ASP.NET sans SharePoint, mais lorsqu'il s'agit de développer et de déployer des applications SharePoint, vous n'avez rien appris. vous avez terminé (et avez probablement informé les parties prenantes à cet effet). Retarder la courbe d'apprentissage de SharePoint ne fait pas de cadeau à votre projet, et votre produit final sera meilleur pour l'expertise que vous acquerrez en cours de route.

Answer 1

S'il s'agit d'une solution à très court terme, Microsoft dispose d'une image VPC d'évaluation WSS limitée dans le temps:

Développeur WSS3 SP1 VPC image

Cela vous permettra de démarrer si vous n'avez pas le temps / les ressources nécessaires pour configurer votre propre image VPC maintenant.

Answer 2

Les composants WebPart ASP.NET fonctionnent dans SharePoint de la même manière qu’ils fonctionnent dans ASP.NET. C’est la voie que je choisirais (contrôle personnalisé dérivé de la composant WebPart ASP.NET. classe). Cela réduira toute nécessité de développer réellement sur un serveur SharePoint.

Le seul problème que vous allez rencontrer est que vous ne pourrez pas tirer parti du cadre SharePoint. Si vous faites quelque chose de avancé dans SharePoint, c'est un gros problème. Cependant, SharePoint est ASP.NET avec quelques fonctionnalités supplémentaires. Vous pouvez donc développer tout ce que vous pouvez développer à l'aide de La classe System.Web.UI.WebControls.WebPart devrait bien fonctionner dans SharePoint.

Certaines considérations vous aideront à vous soulager lorsque vous passerez d'ASP.NET pur à SharePoint:

• Si vous pouvez tout mettre dans un même assemblage, le déploiement en sera facilité
  • essayez de mettre tout ce dont vous avez besoin dans les DLL déployées sur SharePoint
  • utiliser les ressources d'assemblage pour incorporer des fichiers JS, CSS et des images si nécessaire
• Nom fort de l'assemblage que vous construisez
  • La plupart des déploiements SharePoint aboutissent dans le GAC et un nom fort sera requis

Voici un article de blog pertinent; Développement de base Composants WebPart dans SharePoint 2007

Answer 3

Je suppose que le moyen le plus simple consiste à utiliser la SmartPart pour SharePoint de CodePlex. La description du projet indique "Le composant WebPart SharePoint qui peut héberger n’importe quel contrôle utilisateur Web ASP.NET . Créez vos composants WebPart sans écrire de code! & Quot ;, ce qui, je suppose, est exactement ce que vous souhaitez faire.

Answer 4

La configuration de ma machine à développer pour Sharepoint m'a pris quelques jours.

Voir http: //weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx

Answer 5

Générez et testez le contrôle comme vous le feriez pour un site Web .net typique. Solution 1 = les contrôles Solution 2 = site Web factice pour héberger les contrôles.

Déploiement sur Sharepoint:

Vous devrez signer les contrôles.

Déposez la DLL signée dans le GAC sur le serveur de point de partage (Windows / assembly)

Marquez le contrôle comme étant sécurisé dans la racine du serveur virtuel web.config sur le site du point de partage.

c'est-à-dire

<SafeControl Assembly="MyControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=975cc42deafbee31" Namespace="MyNamespace" TypeName="*" Safe="True" AllowRemoteDesigner="True" />

Enregistrez le composant dans votre page SharePoint:

<%@ Register Namespace="MyNamespace" Assembly="MyControl, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=975cc42deafbee31" TagPrefix="XXXX" %>

Utilisez le contrôle:

<XXXX:ClassName runat="server" Field1="Value1" Field2="Value2" ....></XXXX:Classname>

Si vous devez remplacer le contrôle par le même numéro de version, vous devez recycler le pool d'applications pour le recharger.

Answer 6

Si vous n'avez pas besoin de faire quelque chose de spécifique à SharePoint (c.-à-d. accéder à des listes, à d'autres sites Web, etc.), vous pouvez créer votre Webpart comme un site Web classique (dérivé de System.Web.UI.WebControls.WebParts.WebPart classe) et cela fonctionnera lorsqu’il sera ajouté à un site SharePoint.

Answer 7

vous devez avoir accès à un serveur SharePoint car vous ne pouvez pas simuler votre WebPart sans celui-ci. Vous devez le déployer sur votre site SharePoint pour vérifier s'il fonctionne. le débogage serait également une douleur. ou vous pouvez utiliser SmartPart, il s’agit d’un composant WebPart qui agit comme un wrapper pour que vos contrôles utilisateur s’affiche dans un site SharePoint.

Answer 8

Vous n’avez pas besoin de SharePoint pour développer WebParts. Vous pouvez développer des composants Webpar héritant de System.Web.UI.WebControls.WebParts. Et c’est le meilleur moyen de créer des composants WebPart, sauf si vous souhaitez utiliser les fonctionnalités suivantes, telles que

* 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)

Dans ce cas, vous devez développer des pièces Web en héritant de Microsoft.SharePoint.WebPartpages.WebPart. Vous pouvez trouver des informations plus utiles ici

Answer 9

Existe-t-il une raison particulière pour laquelle vos contrôles utilisateur doivent être déployés en tant que composants WebPart? Il est parfaitement possible de déployer des contrôles utilisateur directement sur les sites Sharepoint, soit via le dossier CONTROLTEMPLATES de la ruche 12, soit vers un emplacement du répertoire virtuel de l'application Web, que vous pouvez ensuite référencer à partir de pages Web à l'aide de Sharepoint Designer.

Si, toutefois, l'exigence du WebPart est cruciale, je recommande Smartpart pour Sharepoint comme déjà mentionné.

Answer 10

En fait, les composants WebPart doivent toujours être déployés dans le dossier bin du point de partage en raison de leur nature "abusive". Si possible, déployez toujours les composants WebPart dans le bac, écrivez votre propre CAS et incluez-le dans votre manifeste.