Domanda

Mi è stato chiesto di sviluppare alcuni controlli utente in ASP.NET che verranno successivamente inseriti in un sito di SharePoint come web part. Sono nuovo di SharePoint e non avrò accesso a un server SharePoint durante il periodo in cui ho bisogno di prototipare queste parti.

Qualcuno sa delle ragioni per cui questo approccio non funzionerà? Se questo approccio non fosse raccomandato, quali sarebbero le altre opzioni? Qualche suggerimento su una risorsa / tutorial su cosa considerare quando si sviluppa una web part ASP.NET pensando a SharePoint?

Grazie

Modifica: 31/12/2008 Alla fine ho segnato una risposta a questa. Mi ci è voluto un po 'di tempo per capire che percorrere subito la strada di SharePoint, sebbene inizialmente dolorosa, è il modo migliore di procedere. L'immagine VPC gratuita rende l'impostazione per lo sviluppo relativamente indolore.

Mentre puoi, come ho fatto io, sviluppare web part in ASP.NET senza SharePoint, quando si tratta di sviluppare e distribuire applicazioni di SharePoint non hai imparato nulla, hai solo spinto la curva di apprendimento in un momento in cui pensi avete finito (e probabilmente avete informato le parti interessate in tal senso). Ritardare la curva di apprendimento di SharePoint non fa alcun favore a te o al tuo progetto e il tuo prodotto finale migliorerà per l'esperienza acquisita lungo la strada.

È stato utile?

Soluzione

Se è una cosa a breve termine, Microsoft ha un'immagine VPC di valutazione WSS a tempo limitato:

WSS3 SP1 Valutazione sviluppatore VPC immagine

Questo ti farà iniziare se non hai tempo / risorse per configurare la tua immagine VPC in questo momento.

Altri suggerimenti

Le web part ASP.NET funzionano in SharePoint esattamente come in ASP.NET. Questo è il percorso che prenderei (controllo personalizzato che deriva dalla Web part ASP.NET ). Ciò allevierà qualsiasi requisito per lo sviluppo effettivo su un server SharePoint.

L'unico problema che incontrerai è che non sarai in grado di sfruttare il framework di SharePoint. Se stai facendo qualcosa di avanzato in SharePoint, questo è un grosso problema. Tuttavia, SharePoint è ASP.NET oltre ad alcune funzionalità aggiuntive, quindi tutto ciò che puoi sviluppare usando La classe System.Web.UI.WebControls.WebPart dovrebbe funzionare perfettamente in SharePoint.

Alcune considerazioni che ti aiuteranno ad alleviare il dolore mentre passi da ASP.NET puro a SharePoint:

  • Se puoi mettere tutto all'interno di un singolo assieme, la distribuzione sarà più semplice
    • prova a mettere tutto il necessario nelle DLL distribuite a SharePoint
    • utilizzare le risorse di assembly per incorporare file JS, CSS e di immagine, se necessario
  • Nome sicuro dell'assembly che stai costruendo
    • La maggior parte delle distribuzioni di SharePoint finiscono nel GAC e sarà richiesto un nome sicuro

Ecco un post di blog pertinente; Developing Basic Web part in SharePoint 2007

Immagino che il modo più semplice sia usare SmartPart per SharePoint di CodePlex. La descrizione del progetto dice " La web part di SharePoint che può ospitare qualsiasi controllo utente web ASP.NET . Crea le tue web part senza scrivere il codice! & Quot ;, che immagino sia esattamente quello che vuoi fare.

L'impostazione della mia macchina per lo sviluppo di Sharepoint mi ha richiesto un paio di giorni.

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

Costruisci e testa il controllo come faresti per un tipico sito web .net. Soluzione 1 = i controlli Soluzione 2 = sito Web fittizio per ospitare i controlli.

Distribuzione su Sharepoint:

Dovrai firmare i controlli.

Rilascia la DLL firmata nel GAC sul server sharepoint (Windows / assembly)

Contrassegna il controllo come sicuro nel root web.config del server virtuale sul sito sharepoint.

cioè.

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

Registra il componente nella tua pagina sharepoint:

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

Usa il controllo:

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

Se è necessario sostituire il controllo utilizzando lo stesso numero di versione, è necessario riciclare il pool di app per ricaricare.

Se non è necessario eseguire operazioni specifiche di SharePoint (ad es. accedere a elenchi, altre webpart, ecc.), è possibile creare la web part come una normale web part (derivata da System.Web.UI.WebControls.WebParts.WebPart classe) e funzionerà quando aggiunto a un sito di SharePoint.

devi avere accesso a un server sharepoint perché non puoi simulare la tua webpart senza di essa, devi distribuirla sul tuo sito sharepoint per verificare se funziona. il debug sarebbe anche un dolore. oppure puoi usare SmartPart, è una webpart che si comporta come un wrapper per i controlli utente da visualizzare in un sito sharepoint.

Non è necessario SharePoint per sviluppare WebParts. È possibile sviluppare webpart ereditando da System.Web.UI.WebControls.WebParts. E questo è il modo preferibile di creare web part a meno che tu non voglia le seguenti funzionalità come

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

Nel qual caso è necessario sviluppare webpart ereditando da Microsoft.SharePoint.WebPartpages.WebPart. Puoi trovare ulteriori informazioni utili qui

Esiste un motivo particolare per cui i controlli utente devono essere distribuiti come web part? È perfettamente possibile distribuire i controlli utente direttamente sui siti di Sharepoint tramite la cartella CONTROLTEMPLATES nell'alveare 12 o in una posizione nella directory virtuale dell'app Web, a cui è possibile fare riferimento dalle pagine Web utilizzando Sharepoint Designer.

Se tuttavia il requisito della web part è fondamentale, allora consiglio Smartpart per Sharepoint come già menzionato.

In realtà, le web part dovrebbero sempre essere distribuite nella cartella bin dello sharepoint a causa della loro natura "abusiva". Distribuire sempre web part nel cestino, se possibile, scrivere il proprio CAS e includerlo nel manifest.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top