January 2007 - Posts

• The ClassResourcePath for custom webparts in MOSS 2007

  At Macaw we've been using standard project templates for most of our development projects for years. In the project template for custom webparts for SharePoint 2003 we've had a basewebpart. All custom webparts for SharePoint 2003 inherit from the basewebpart. On of the things the basewebpart takes care of is determining the ClassResourcePath. Custom web parts can be deployed to the wwwroot/bin directory or to the global assembly cache (GAC). The deployment location also affects the location where resources (for instance usercontrols and images) that are required by the web part are stored. For GAC deployments, the directory is mapped to /_wpresources/[assembly_name]. For bin directory deployments, the directory is mapped to /wpresources/[assembly_name]. In order to determine the resource path at runtime you use the ClassResourcePath of Microsoft.SharePoint.WebPartPages.WebPart. For SharePoint 2007 Microsoft recommends inheriting custom webparts from System.Web.UI.WebControls.WebParts.WebPart. Unfortunately this class doesn't contain an equivelant of the ClassResourcePath. However if you're building a basewebpart that will be used by a lot of custom web parts you do want to be able to determine the path where the resources are stored at runtime, since you don't beforehand know whether a web part will be deployed in the bin or in the GAC. In order to be able to do this I've used SPWebPartManager.GetClassResourcePath. You can use this class, that is inherited from Microsoft.SharePoint.WebPartPages and at the same time inherit the web part itself from System.Web.UI.WebControls.WebParts.WebPart in order to comply with Microsoft recommendations. The code getting the resource path will look like this: SPWeb currentWeb = SPControl.GetContextWeb(Context); Type currentType = BaseWebPart.GetType(); string classResourcePath = SPWebPartManager.GetClassResourcePath(currentWeb, currentType); Posted Jan 17 2007, 08:53 PM by Mirjam with 5 comment(s) Filed under: Development, Web Parts

• MOSS 2007 Performance guidelines

  In order to keep your MOSS 2007 solution fast and scalable you should take the following guidelines at heart: http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true If you look at the "Guidelines for acceptable performance" the first thing you should be aware of is that Microsoft makes a distinction between "web sites" and "sub sites". Where web sites are actually the first sub sites under a site collection, and sub sites are the sites under the web sites. The total number of web sites and sub sites together in one site collection should be 250.000. So if you've got less web sites, you can have more sub sites. Keep in mind never to use more than 2000 sub sites per web site. Another number that stands out and causes some confusion is the number of 2000 security principales per web site. Security principales are users and SharePoint groups. I asume that the maximum number of 2000 is per site collection since all groups are cross site groups in MOSS. The last thing you need to be aware of is that a content database can store several site sollections, but that one site collection will always be stored within one content database. In order to be able to do a database backup and restore in a reasonable amount of time you should keep the size of your database limited. I always aim for about 50Gb maximum. This means you have to think about how much storage your site collections will use in order to determine the maximum number of site collections per content database. You can set the maximum number of site collections per content database in the Central Administration. Go to Application Management and click Content Databases here you can set the "Maximum number of sites that can be created in this database". Posted Jan 03 2007, 12:04 PM by Mirjam with 1 comment(s) Filed under: Performance, Guidelines, Architecture