Design-Time Rendering of Web Parts
When you add Web Parts to a page directly in Microsoft® Visual Studio® .NET or Microsoft Office FrontPage® 2003, the part is not rendered in the standard way; it does not go through the standard set of ASP.NET events.
Following are issues to consider when rendering Web Parts in design mode.
Note For more information about implementing a simple Web Forms control designer, see the .NET Framework Developer's Guide on MSDN®.
In Visual Studio .NET
Because Web Parts are at their core Web server controls, they can take advantage of the same alternative rendering as Web server controls when they are used in Visual Studio .NET. A Web Part author, like a Web server control author, can create an object derived from System.Web.UI.ControlDesigner and associate it with the Web Part, which Visual Studio .NET uses as a designer.
Visual Studio .NET requires an object on the client computer (the computer running Visual Studio .NET) and not just on the server. For this reason, Microsoft Windows® SharePoint™ Services and the Web Part being used must be installed on the developer's computer.
Asynchronous events do not work in design mode, and script is not available while working in Visual Studio .NET. If a Web Part developer does provide a designer, the developer must use the GetDesignTimeHeader and GetDesignTimeFooter methods of the WebPart class to render the frame around the part.
In FrontPage
By default, a Web Part does not implement the IDesignTimeHtmlProvider interface. In this case, a default rendering is shown in FrontPage. For a Web Part to do something different in FrontPage, up to and including providing a full-fidelity rendering, the Web Part must implement IDesignTimeHtmlProvider.GetDesignTimeHtml.
The GetDesignTimeHtml method can be called multiple times during the lifetime of a Web Part, unlike the RenderWebPart method. Additionally, asynchronous events do not work in design mode, and a Web Part may need to do a synchronous implementation when the GetDesignTimeHtml method is called.
The Web Part, when edited in FrontPage, is not a live object on the client. Instead, the server sends a rendering of the part to FrontPage when the page is requested (and subsequently whenever changes are made to the page—for example, during property changes). The Web Part infrastructure handles this; no special work is required to enable use in FrontPage.
Script is not available while working in FrontPage. Also, parts are not connected (using part-to-part communications) while in FrontPage. Connections can be authored in FrontPage, but the result of the connection is not seen until it is requested by a browser.