- Unless you intend to use your WebPart on SharePoint 2003 site inherit your WebPart class from System.Web.UI.WebControls.WebParts.WebPart
- Deploy WebPart dll to bin folder instead of GAC [full trust] if possible
Remember to add [assembly: AllowPartiallyTrustedCallers()] to allow the strong named assembly to run from the bin - Remember to change trust level in web.config from "WSS_Minimal" to "WSS_Medium" or create your own policy if your WebPart uses Object Model
Tuesday, September 8, 2009
Tips for WebPart Development
Introduction to Web Parts
Web Parts are server-side controls that run inside the context of special pages (that is, Web Part Pages) within an ASP.NET application or a Windows SharePoint Services site. They are the "building blocks" of pages in Windows SharePoint Services.
There are now two different Web Part styles in Windows SharePoint Services 3.0. Both are supported, but the ASP.NET 2.0 Web Part is the recommended style for your new projects.
SharePoint-based Web Parts — The older style Web Parts have a dependency on Microsoft.SharePoint.dll and must inherit from the WebPart base class in the Microsoft.SharePoint.WebPartPages namespace. These Web Parts can only be used in SharePoint Web sites. Yet in Windows SharePoint Services 3.0, the Microsoft.SharePoint.dll was changed so that Web Parts written in the older style would be compatible with the Windows SharePoint Services 3.0 runtime.
ASP.NET 2.0 Web Parts — These Web Parts are built on top of the ASP.NET Web Part infrastructure. The newer ASP.NET-style Web Parts have a dependency on System.Web.dll and must inherit from a different base class named WebPart in the System.Web.UI.WebControls.WebParts namespace. These Web Parts can be used in Windows SharePoint Services applications whether Windows SharePoint Services is involved or not, making them highly reusable. If you are creating your Web Part specifically for a SharePoint site, and it will consume the Windows SharePoint Services object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.
The Windows SharePoint Services 3.0 Web Part infrastructure is built on top of a control named SPWebPartManager that is derived from the ASP.NET 2.0 WebPartManager control. The SPWebPartManager control overrides the standard behavior of the WebPartManager control to persist Web Part data inside the Windows SharePoint Services content database instead of in the ASP.NET services database. In most cases, you don not have to worry about dealing directly with the SPWebPartManager control because the one and only required instance is already defined in default.master. When you create a content page that links to default.master, the SPWebPartManager control is already there.
When you create a Web Part Page for a standard ASP.NET 2.0 application, you need to add logic that interacts with the WebPartManager control to manage the Web Part display mode, and generally you also need to explicitly add editor parts and catalog parts to the page along with the HTML layout to accommodate them. Fortunately, you do not have to perform these changes when creating content pages for a Windows SharePoint Services 3.0 site. Instead, you inherit from the WebPartPage class that is defined inside the Microsoft.SharePoint.WebPartPages namespace and it does all the work behind the scenes for you.
Custom Web Parts provide developers with a method to create user interface elements that support both customization and personalization. The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them.
There are now two different Web Part styles in Windows SharePoint Services 3.0. Both are supported, but the ASP.NET 2.0 Web Part is the recommended style for your new projects.
SharePoint-based Web Parts — The older style Web Parts have a dependency on Microsoft.SharePoint.dll and must inherit from the WebPart base class in the Microsoft.SharePoint.WebPartPages namespace. These Web Parts can only be used in SharePoint Web sites. Yet in Windows SharePoint Services 3.0, the Microsoft.SharePoint.dll was changed so that Web Parts written in the older style would be compatible with the Windows SharePoint Services 3.0 runtime.
ASP.NET 2.0 Web Parts — These Web Parts are built on top of the ASP.NET Web Part infrastructure. The newer ASP.NET-style Web Parts have a dependency on System.Web.dll and must inherit from a different base class named WebPart in the System.Web.UI.WebControls.WebParts namespace. These Web Parts can be used in Windows SharePoint Services applications whether Windows SharePoint Services is involved or not, making them highly reusable. If you are creating your Web Part specifically for a SharePoint site, and it will consume the Windows SharePoint Services object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.
The Windows SharePoint Services 3.0 Web Part infrastructure is built on top of a control named SPWebPartManager that is derived from the ASP.NET 2.0 WebPartManager control. The SPWebPartManager control overrides the standard behavior of the WebPartManager control to persist Web Part data inside the Windows SharePoint Services content database instead of in the ASP.NET services database. In most cases, you don not have to worry about dealing directly with the SPWebPartManager control because the one and only required instance is already defined in default.master. When you create a content page that links to default.master, the SPWebPartManager control is already there.
When you create a Web Part Page for a standard ASP.NET 2.0 application, you need to add logic that interacts with the WebPartManager control to manage the Web Part display mode, and generally you also need to explicitly add editor parts and catalog parts to the page along with the HTML layout to accommodate them. Fortunately, you do not have to perform these changes when creating content pages for a Windows SharePoint Services 3.0 site. Instead, you inherit from the WebPartPage class that is defined inside the Microsoft.SharePoint.WebPartPages namespace and it does all the work behind the scenes for you.
Custom Web Parts provide developers with a method to create user interface elements that support both customization and personalization. The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them.
Developing First Three Web Parts for SharePoint
Note : In order to follow these steps we need Visual Studio 2005 (.NET 2.0) or later. we will also need network access to a Windows 2003/8 server with SharePoint 2007 (WSS or MOSS). Also we need to have administration rights on our SharePoint server and also administration rights in our target SharePoint web application.
The steps to create a simple Web Part that prints "Hello World!" to the screen.
1. In Visual Studio, create a new class library
2. Add a reference to System.Web.
3. Create a class that inherits from the WebPart class in System.Web.UI.WebControls.WebParts. 4. In order to control the rendering of the Web Part one overrides the Render method. An HtmlTextWriter instance is passed into the Render method and can then be used to write markup to the page output.
using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
namespace ExampleWebPartLibrary
{
public class MyWebPart : WebPart
{
protected override void Render(HtmlTextWriter writer)
{
writer.Write("Hello World!");
}
}
}
5. OPTIONAL Add the code statements using System.Security; and [assembly: AllowPartiallyTrustedCallers] to our AssemblyInfo.cs file.
6. Specify proper Assembly Name and Namespace properties for the class library project by opening the project property page
7. OPTIONAL Specify the Signing parameters in the project property page
8. Build the assembly frequent
9. Copy the newly created assembly from bin\Release or bin\Debug folder and paste it in the bin directory of the sharepoint web application OR In our class library properties, set the build output path to the bin directory of our SharePoint development web application.
10. OPTIONAL copy the assembly into C:\Windows\Assembly (GAC), REight click select properies to find its public key
11. In the web.config file of the sharepoint web application, add the assembly as a safe control.
Namespace="ExampleWebPartLibrary"
TypeName="*" Safe="True" AllowRemoteDesigner="True" />
12. We can now add the web part library to your SharePoint site. To do this, log in as an administrator and go to the settings page. Click on "Web Part Gallery" under the "Galleries" section. Click "New" and we should see our web part in a list. Select our web part and click "populate gallery".
13. We can give your web part a friendly title and control its permissions using the edit button in the web part gallery. I have chosen to call the Web Part "My Web Part".
14. Finally we can add the web part to a web part page and we should see the web part's hard coded "Hello World!" message.
Adding ASP.NET controls in our web part
1. Repeat the steps 1-3 of first example.
2. Controls should be declared as member variables and then initialised and configured within an override of the CreateChildControls method. I usually create a separate method to setup each control and then invoke that method from CreateChildControls. It is important to add the created controls to the list of Web Part controls. If a control is not added to this list then it's events won't be raised on post back.
private Button btnDemo;
private void createBtnDemo()
{
btnDemo = new Button();
btnDemo.Text = "Click me";
btnDemo.Click += new EventHandler(btnDemo_Click);
// This line of code is required to trigger the click eventControls.Add(btnDemo);
}
protected override void CreateChildControls()
{
base.CreateChildControls();
createBtnDemo();
createLblHelloWorld();
}
3. The controls are rendered inside the Render method override. This method can be used to layout the web part it's controls. The HtmlTextWriter has many useful methods to help out, including WriteBreak() which writes a "
".
protected override void Render(HtmlTextWriter writer)
{
writer.WriteBreak();
lblHelloWorld.RenderControl(writer);
writer.WriteBreak();
writer.WriteBreak();
btnDemo.RenderControl(writer);
}
4. Perform the steps from 5 (of first example) to deploy the web part
Accessing SharePoint data in our web part
1. Repeat the steps 1-3 of first example.
2. Reference Microsoft.SharePoint.dll by browsing to the directory "[Program Files]\Common Files\Microsoft Shared\web server extensions\12\ISAPI".
3. To take care of the code access security for our web part by setting the target SharePoint site's trust level to "Full". This level of trust is generally acceptable in an Intranet environment. Find the following in our site's web.config file:
change this to:
4. Write some code to access SharePoint data. Here I show a simple web part that displays the name of the presently logged in user:
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
namespace ExampleWebPartLibrary
{
public class HelloUser : WebPart
{
protected override void Render(System.Web.UI.HtmlTextWriter writer)
{
// Get a contextual reference to the current SPWeb
SPWeb currentWeb = SPContext.Current.Web;
// Write a message to the current user
writer.Write("Hello " + currentWeb.CurrentUser.LoginName);
}
}
}
Note : SPContext.Current.Web is the starting point for accessing SharePoint data. For example we can use it to access data in lists and document libraries.
5. Perform the steps from 5 (of first example) to deploy the web part
The steps to create a simple Web Part that prints "Hello World!" to the screen.
1. In Visual Studio, create a new class library
2. Add a reference to System.Web.
3. Create a class that inherits from the WebPart class in System.Web.UI.WebControls.WebParts. 4. In order to control the rendering of the Web Part one overrides the Render method. An HtmlTextWriter instance is passed into the Render method and can then be used to write markup to the page output.
using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
namespace ExampleWebPartLibrary
{
public class MyWebPart : WebPart
{
protected override void Render(HtmlTextWriter writer)
{
writer.Write("Hello World!");
}
}
}
5. OPTIONAL Add the code statements using System.Security; and [assembly: AllowPartiallyTrustedCallers] to our AssemblyInfo.cs file.
6. Specify proper Assembly Name and Namespace properties for the class library project by opening the project property page
7. OPTIONAL Specify the Signing parameters in the project property page
8. Build the assembly frequent
9. Copy the newly created assembly from bin\Release or bin\Debug folder and paste it in the bin directory of the sharepoint web application OR In our class library properties, set the build output path to the bin directory of our SharePoint development web application.
10. OPTIONAL copy the assembly into C:\Windows\Assembly (GAC), REight click select properies to find its public key
11. In the web.config file of the sharepoint web application, add the assembly as a safe control.
Namespace="ExampleWebPartLibrary"
TypeName="*" Safe="True" AllowRemoteDesigner="True" />
12. We can now add the web part library to your SharePoint site. To do this, log in as an administrator and go to the settings page. Click on "Web Part Gallery" under the "Galleries" section. Click "New" and we should see our web part in a list. Select our web part and click "populate gallery".
13. We can give your web part a friendly title and control its permissions using the edit button in the web part gallery. I have chosen to call the Web Part "My Web Part".
14. Finally we can add the web part to a web part page and we should see the web part's hard coded "Hello World!" message.
Adding ASP.NET controls in our web part
1. Repeat the steps 1-3 of first example.
2. Controls should be declared as member variables and then initialised and configured within an override of the CreateChildControls method. I usually create a separate method to setup each control and then invoke that method from CreateChildControls. It is important to add the created controls to the list of Web Part controls. If a control is not added to this list then it's events won't be raised on post back.
private Button btnDemo;
private void createBtnDemo()
{
btnDemo = new Button();
btnDemo.Text = "Click me";
btnDemo.Click += new EventHandler(btnDemo_Click);
// This line of code is required to trigger the click eventControls.Add(btnDemo);
}
protected override void CreateChildControls()
{
base.CreateChildControls();
createBtnDemo();
createLblHelloWorld();
}
3. The controls are rendered inside the Render method override. This method can be used to layout the web part it's controls. The HtmlTextWriter has many useful methods to help out, including WriteBreak() which writes a "
".
protected override void Render(HtmlTextWriter writer)
{
writer.WriteBreak();
lblHelloWorld.RenderControl(writer);
writer.WriteBreak();
writer.WriteBreak();
btnDemo.RenderControl(writer);
}
4. Perform the steps from 5 (of first example) to deploy the web part
Accessing SharePoint data in our web part
1. Repeat the steps 1-3 of first example.
2. Reference Microsoft.SharePoint.dll by browsing to the directory "[Program Files]\Common Files\Microsoft Shared\web server extensions\12\ISAPI".
3. To take care of the code access security for our web part by setting the target SharePoint site's trust level to "Full". This level of trust is generally acceptable in an Intranet environment. Find the following in our site's web.config file:
change this to:
4. Write some code to access SharePoint data. Here I show a simple web part that displays the name of the presently logged in user:
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
namespace ExampleWebPartLibrary
{
public class HelloUser : WebPart
{
protected override void Render(System.Web.UI.HtmlTextWriter writer)
{
// Get a contextual reference to the current SPWeb
SPWeb currentWeb = SPContext.Current.Web;
// Write a message to the current user
writer.Write("Hello " + currentWeb.CurrentUser.LoginName);
}
}
}
Note : SPContext.Current.Web is the starting point for accessing SharePoint data. For example we can use it to access data in lists and document libraries.
5. Perform the steps from 5 (of first example) to deploy the web part
WebPart Deployment
Within a SharePoint site, we can deploy a Web Part assembly in any of the following locations.
bin directory — The bin directory is a folder stored in your Web application root directory. For most installations, this is located in the %SYSTEMDRIVE%\inetpub\wwwroot\wss\VirtualDirectories\\bin directory.
Global Assembly Cache (GAC) — The GAC enables you to share assemblies across numerous applications. Components are typically installed in the %SYSTEMDRIVE%\WINDOWS\Assembly directory.
Note that the recommended practice is to deploy assemblies to the bin directory.
Windows SharePoint Services provides a SafeControls list to prevent users from arbitrarily adding server-side code within ASPX pages. The SafeControls list is a list of approved controls and Web Parts that are specific to the SharePoint site that we have designated as safe for invocation on any ASPX page within our site. This list is contained in the web.config file in your Web application root. The local path contains the physical location of the web.config file.
Web Parts are designed to be distributed over the Internet or an intranet. For security reasons, when we create a custom Web Part, we should give it a strong name to ensure that the Web Part can be trusted by our users.
By default, the trust level for a server will be WSS_Minimal, which does not allow access to the Windows SharePoint Services object model. In order to perform such actions, we must perform one of the following three actions:
Create a custom policy file for your assembly,
Install your assembly in the GAC global assembly cache
Increase the trust level for the entire virtual server. Eg: increase the default trust from WSS_Minimal to WSS_Medium in the web.config file.
bin directory — The bin directory is a folder stored in your Web application root directory. For most installations, this is located in the %SYSTEMDRIVE%\inetpub\wwwroot\wss\VirtualDirectories\
Global Assembly Cache (GAC) — The GAC enables you to share assemblies across numerous applications. Components are typically installed in the %SYSTEMDRIVE%\WINDOWS\Assembly directory.
Note that the recommended practice is to deploy assemblies to the bin directory.
Windows SharePoint Services provides a SafeControls list to prevent users from arbitrarily adding server-side code within ASPX pages. The SafeControls list is a list of approved controls and Web Parts that are specific to the SharePoint site that we have designated as safe for invocation on any ASPX page within our site. This list is contained in the web.config file in your Web application root. The local path contains the physical location of the web.config file.
Web Parts are designed to be distributed over the Internet or an intranet. For security reasons, when we create a custom Web Part, we should give it a strong name to ensure that the Web Part can be trusted by our users.
By default, the trust level for a server will be WSS_Minimal, which does not allow access to the Windows SharePoint Services object model. In order to perform such actions, we must perform one of the following three actions:
Create a custom policy file for your assembly,
Install your assembly in the GAC global assembly cache
Increase the trust level for the entire virtual server. Eg: increase the default trust from WSS_Minimal to WSS_Medium in the web.config file.
Sunday, August 16, 2009
Windows XP Mode for Windows 7
Windows XP Mode for Windows 7 makes it easy to install and run your Windows XP applications directly from your Windows 7-based PC. It utilizes virtualization technology such as Windows Virtual PC to provide a Virtual Windows XP environment for Windows 7.
Windows XP Mode provides you with the flexibility to run many older productivity applications in a Virtual Windows XP environment on a Windows 7-based PC.
All you need to do is install these applications directly in your Virtual Windows XP environment and they will be published on your Windows 7 desktop. Now you can run many older applications, including older versions of the same application you are already running on Windows 7.
Designed for Small and Medium Businesses
Windows XP Mode was designed for the small and medium business user who doesn’t have a lot of resources to spend on IT or on revamping important software.Windows XP Mode extends the lifecycle of many older Windows XP applications to continue providing business value.With just one click, the business user can run many Windows XP applications from a Windows 7 desktop just as if it were a Windows 7 application. There’s no need to retrain the user, or to re-learn the application.
Easy to Set Up Windows XP Mode
Once you’ve installed both Windows Virtual PC and the Virtual Windows XP environment, Windows Virtual PC provides a simple wizard to set up the Windows XP Mode with just a few clicks. It’s that easy!
New Cool Windows Virtual PC Features
Here are some of the exciting new Windows Virtual PC features that make it easy to use, and to run many of your older Windows XP applications from your Windows 7 desktop:
• Seamless Applications—publish and launch applications installed on Virtual Windows XP directly from the Windows 7 desktop, as if they were installed on the Windows 7 host itself.
• Folder Integration between host and guest—access your Windows 7 Known Folders, such as My Documents, Pictures, Desktop, Music, Video, from inside the Virtual Windows XP environment.
• Clipboard Sharing—cut and paste between your Windows 7 host and any virtual machine.
• Printer Redirection—print directly to your attached printer from your seamless application or virtual machine.
• USB Support—users can access USB devices attached to the host directly from Virtual Windows XP. These devices include Printers and Scanners, Flash Memory/Sticks and External Hard Drives, Digital Cameras, and more.
PC Requirements for Windows Virtual PC:
• 1 GHz 32bit or 64bit processor or better
• CPU w/ AMD-VTM or Intel VT features turned on
• 2 GB of memory recommended
• Additional 15GB of hard disk space per virtual Windows environment recommended
Note: Beta version of Windows Virtual PC is now available for download in the following Microsoft URL.
http://www.microsoft.com/windows/virtual-pc/download.aspx
References
http://www.microsoft.com/virtual-pc
http://www.microsoft.com/windows/windows-7/
http://www.microsoft.com/virtual-pc/support
If you have any suggestions / comments about this post, please feel free to contact me at arulkumar.sps@gmail.com or post your comments here!
Windows XP Mode provides you with the flexibility to run many older productivity applications in a Virtual Windows XP environment on a Windows 7-based PC.
All you need to do is install these applications directly in your Virtual Windows XP environment and they will be published on your Windows 7 desktop. Now you can run many older applications, including older versions of the same application you are already running on Windows 7.
Designed for Small and Medium Businesses
Windows XP Mode was designed for the small and medium business user who doesn’t have a lot of resources to spend on IT or on revamping important software.Windows XP Mode extends the lifecycle of many older Windows XP applications to continue providing business value.With just one click, the business user can run many Windows XP applications from a Windows 7 desktop just as if it were a Windows 7 application. There’s no need to retrain the user, or to re-learn the application.
Easy to Set Up Windows XP Mode
Once you’ve installed both Windows Virtual PC and the Virtual Windows XP environment, Windows Virtual PC provides a simple wizard to set up the Windows XP Mode with just a few clicks. It’s that easy!
New Cool Windows Virtual PC Features
Here are some of the exciting new Windows Virtual PC features that make it easy to use, and to run many of your older Windows XP applications from your Windows 7 desktop:
• Seamless Applications—publish and launch applications installed on Virtual Windows XP directly from the Windows 7 desktop, as if they were installed on the Windows 7 host itself.
• Folder Integration between host and guest—access your Windows 7 Known Folders, such as My Documents, Pictures, Desktop, Music, Video, from inside the Virtual Windows XP environment.
• Clipboard Sharing—cut and paste between your Windows 7 host and any virtual machine.
• Printer Redirection—print directly to your attached printer from your seamless application or virtual machine.
• USB Support—users can access USB devices attached to the host directly from Virtual Windows XP. These devices include Printers and Scanners, Flash Memory/Sticks and External Hard Drives, Digital Cameras, and more.
PC Requirements for Windows Virtual PC:
• 1 GHz 32bit or 64bit processor or better
• CPU w/ AMD-VTM or Intel VT features turned on
• 2 GB of memory recommended
• Additional 15GB of hard disk space per virtual Windows environment recommended
Note: Beta version of Windows Virtual PC is now available for download in the following Microsoft URL.
http://www.microsoft.com/windows/virtual-pc/download.aspx
References
http://www.microsoft.com/virtual-pc
http://www.microsoft.com/windows/windows-7/
http://www.microsoft.com/virtual-pc/support
If you have any suggestions / comments about this post, please feel free to contact me at arulkumar.sps@gmail.com or post your comments here!
Subscribe to:
Posts (Atom)