SP2010 contains a built-in library of Web Parts, modules to accomplish common tasks from picture galleries to scheduling meetings allowing non-coders to build a functional business solution and coders to apply their skills to something other than a new wheel, maybe just new rims or run-flat tread. There are two development classes for custom Web Parts, those developed in SharePoint and those created as ASP.NET, while the first is still supported the second is recommended. Although SP2010 uses ASP.NET you can't simply drop your .NET code into the relevant SP2010 directory and have it run, its definition must be exported as a .webpart file and then import it into a SP2010 foundation site. Many advantages are inherent in SP2010's use of the ASP.NET infrastructure including ASP.NET developers being able to draw on their current knowledge of that programming model, the fact that compiled parts run faster than scripts, the ability to build a library of Web Parts by creating a base class, cloaking your source code, interacting with other web parts, controlling Web Part cache and secure access control.
Created Web Parts don't get to run willy nilly and play in their favorite Web Parts Zone playground, there is a WebPartManager class in the ASP.NET Web Part infrastructure that manages Web Part instances at run time. From this class an ASP.NET page using Web Part controls draws at least two objects including a WebPartManager object that tracks which zone Web Parts are in, connections and customizations made to them, as well as an object to specifically place the Web Part within a Web Part Zone. This page must be present within your application for the Web Parts to run unless your page links to the v4.master, which already contains an instance of the WebPartManager class. Summarily, the WebPartManager class controls serialization, storage and retrieval for the Web Part and both it and a WebPartZone control are both required to persist your Web Part control's data. For and even broader view of Web Part classes search MSDN for, "Microsoft.SharePoint.WebPartPages Namespace "
To deploy your Web Part control it must either be a default control that is listed in the SafeControl list or a new control may be added to that list in the web.config file of your Web Application root as an XML declaration. Web Part assemblies need to be digitally signed using the Strong Naming [sn.exe] tool provided in SharePoint Foundation and the public key provided in the tool will have to be used to register your control in the SafeControl list noted above. This is one small aspect of the Code Access Security [CAS] model that is intended to keep the core functionality of SharePoint Server safe from poorly built or malicious code. You must select one of three locations to deploy the Web Part to: the Solution Gallery, the GAC or a local bin directory specific to your web application. Factors bearing on that selection are listed here.
Web Parts standardized connection interfaces mean that they link to each other by your development effort on the back end, or by a front-end approach through SharePoint Designer or a browser.
Upgrading Web Parts is a programming task that is handled differently depending on how the Web Part was originally created and what type of Web Part it is. For a detailed reference search MSDN for "Upgrading Web Parts."Return to www.sqlsolver.com