Wednesday, December 27, 2006

Configuring Code Access Security in SharePoint Solutions

Continuing my quest to explore all details of the new solution framework in Sharepoint v3 I stumbled on one issue of great importance: Code Access Security.

There are several options when it comes to configuring the CAS.

  1. Install the assembly in the GAC
  2. Set the trustlevel of the web application in web.config to Full
  3. Create a permission set with all permissions required by the assembly

This MSDN article describes the pros and cons of the above three options in detail. In essence the first two options are easy to implement, but may compromise security and potentially could lead to licensing issues. Microsoft's recommendation is to create permission set tailored to your application. No doubt this option is most time consuming and requires more configuration changes, nevertheless it is the most secure one.

The WSS solution framework allows the deployment of assemblies with custom CAS policy. The CAS policy definition however is different than declaring custom CAS policy for an ASP.NET web application. The snipped below shows the structure of the CAS policy definition in the WSS solution:

The first <Assembly> elements define the target location for our assemblies. The target location of the assembly is determined by the attribute DeploymentTarget="WebApplication" and in this case it is the bin directory in the root of the target web application. Since all WSS applications run by default with trust level WSS_Minimal, which does not give any permissions to our assemblies, we need to include the <CodeAccessSecurity> section in the solution manifest. This way WSS can create a new WSS_Custom trust level. This newly created trust level is based on WSS_Minimal and in addition it will include the specific permissions for our assemblies. WSS stores the definition of this trust level in "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_custom_wss_minimaltrust.config".

The assemblies included in this policy can be specified either individually by name or in a group by the public key blob.

The assemblies included in this policy can be specified either individually by name or in a group by the public key blob. To get the key blob you can use the Strong Name Tool (Sn.exe).

In the <PermissionSet> element add individual permission using the usual syntax. More about permissions and their syntax here and here . In this particular sample I included some of the commonly used permissions. After I compiled and deployed the solution I noticed that the web.config has been modified. A new trust level WSS_Custom has been created and the trust level has been set to this new level. If we look at the newly created file with our policy "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_custom_wss_minimaltrust.config" we'll notice that WSS created StrongNameMembershipCondition code group and a new <PermissionSet> element with a name made up of the solution file name and GUID.

I also tried to find out if there are ways to create UrlMembershipCondition code groups, so that I can include the target path for my assemblies and be done with it. Unfortunately it looks like this option is not available. Furthermore I was not able to create an unrestricted PermissionSet, so that I don't need to specify individual permissions. This leaves us with one option to specify all permissions required for the execution of our assemblies, which is not an easy task when working with third party assemblies and complex WSS applications. Luckily most of the time if a method fails because of missing permission the framework will throw an exception with appropriate error message.


Friday, December 01, 2006

SharePoint solution manifests inside and out

One of the major improvements in WSS 3 is the new solution framework, which allows the deployment of Web Parts, Features, assemblies and other files to SharePoint site or farm. The process of deploying a WSS solution has several stages: (1) Creating the solution contents; (2) Compiling the WSP (CAB) file; (3) Adding the solution to the SP site(s); (3) Deploying the solution to the target site(s).

The WSS SDK however does not explain in detail the target locations of the different types of files deployed on the server. In this post I am summarizing my observations that can help you understand what exactly happens during solution deployment.

I assume that WSS was installed in the default installation location, which for most WSS files is C:\Program Files\Common Files\Microsoft Shared\web server extensions\12 and for the virtual directories is C:\Inetpub\wwwroot\wss\VirtualDirectories\.


The Assemblies element contains a list of assemblies to be deployed to the SharePoint web server. These can be web parts, event handlers, web services or any other class that will be used in your application. The parameter DeplymentTarget determines whether to deploy the assembly to the GAC or to a directory (WebApplication).

With the GAC option assemblies are copied to C:\WINDOWS\assembly. With the WebApplication option the files are copied to C:\Inetpub\wwwroot\wss\VirtualDirectories\80\bin.

The SafeControl element is optional and if added SharePoint will put the assembly element to the SafeControls element in the web.config file of the target web application.


The Features element specifies files with feature definitions.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\

Template Files

This is where most files will be added, including images, themes, web pages etc.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\

Application Resources

In this section are listed resource files specific to the target web application.

Target Folder: C:\Inetpub\wwwroot\wss\VirtualDirectories\{virtual app port}\resources\

Global Resources

The resources list contains global resources available to all web applications.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\

Root Files

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\

Web Parts

To list the web parts to be deployed use the DwpFile(s) elements to specify the name of the file.

Target Folder: C:\Inetpub\wwwroot\wss\VirtualDirectories\80\wpcatalog\

Site Definitions

The SiteDefinitionManifests list contains descriptions of all site definition folders. The Location attribute defines the name of the folder that contains the site definition. This folder contains the ONET.xml and other components of the site definition.

Target Folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\


Friday, November 17, 2006

Windows Sharepoint Services 3.0 RTW is available for download

Today I installed the release version of WSS 3.0 and everything went smoothly. The install was a breeze, as expected. I noticed immediately one change that makes live easier. The folders for the virtual web sites under wwwroot\wss\VirtualDirectories are now named after the port the site is using not the GUID, which is much better to work with. Dovizhdane!

Wednesday, November 15, 2006


Today I did the Subversion demo for SCDNUG. Here is a link to supporting presentation. I used a VM on a laptop with 1GB and I really did not anticipate that it'll run so slow. I guess when you are in the spotlight all PCs go a bit slower than usual. Point well taken... Next time take a beefier machine or just don't run everything on VM and stick to the essential topics. Dovizhdane!

Thursday, November 09, 2006

SCDNUG November Meeting

At the November meeting of SCDNUG, which is next Wednesday 11/15/2006, I'll be speaking about Subversion. It has been a real pleasure to work on this project mostly because I really enjoy working with Subversion. Here is what I am going to talk about:

  • Review Subversion’s key features and advantages (speed, less maintenance, flexibility, low cost)
  • Compare Subversion with VSS
  • Instructions how to install and configure Subversion quickly
  • Review of Subversion clients (Windows and Visual Studio)
  • Close the cycle with MS Build integration
  • Migrating to Subversion

The session is both informative and practical. My goal is to give all tools, links and steps that will enable a developer to build a development environment in less than an hour.

Come and visit us at the Space Coast Credit Union 11/15 @ 6:30pm


Friday, October 27, 2006

Microsoft announced Express Upgrade to Windows Vista

Today Microsoft announced Express Upgrade to Windows Vista for purchases made between October 26, 2006 and March 15, 2007. It is really strange that many manufacturers and Microsoft made a lot of people feel warm and fuzzy with the Vista Capable PC label attached to most if not all new systems, but now they may cut off many of them. However if you purchased a Vista Capable PC before October 26, 2006 don't give up. You may still be able to get refund from the PC manufacturer. My personal experience was with HP, which offered me to either cancel the order and reorder, return the PC or get a refund comparable with the price of the Vista upgrade. Guess which one I picked... Dovizhdane!

Monday, October 16, 2006

SCDNUG October Meeting - Russ Nemhauser

October Meeting - Russ Nemhauser Ineta will be providing Russ Nemhauser to speak at our meeting October 18. The meeting will be held at the Space Coast Credit Union Corporate Headquarters Introduction to ASP.NET 2.0 Web Parts Web Parts offer ASP.NET 2.0 applications the ability to provide powerful personalization functionality. In this session, you'll learn how Web Parts are implemented in ASP.NET 2.0, how to get up and running with Web Parts quickly, and how to extend the Web Parts framework. You will also learn how Web Parts functionality ties into the built-in membership features.

Thursday, October 05, 2006

SharePoint Administraion User Interface for stsadm.exe (WSS v3 beta)

After couple of weeks playing with WSS v3 and MOSS 2007 features, solutions and their deployment, I realized how central stsadm.exe for all this operations is. One way to go is to use bat files, but since I always forget command line options, I decided to create a simple user interface that saves keystrokes and help lookups. The tool incorporates the stsadm's help, so it is very easy to figure out what parameter values to put where. In addition if you need to save a parameter value that is used in different contexts you can do so by clicking on the parameter name. One good example is the url of a frequently used site. Once you save the value for all occurrences of the parameter, this parameter will allow you to select value from a list or type new one for any other operation it is used. Each executed command line is saved in a history list for easy retrieval. Download the stsadm UI from here... The tool uses an XML config file and can be easily adapted to any command line tool. If somebody is interested to use the code or make modifications let me know. If you find the tool useful and you have suggestions send a note.

Thursday, September 21, 2006

Installing SharePoint Services 3 on virtual machine after NewSID

For those of us addicted to virtual machines Sysinternals' tool NewSID comes in handy every time we clone that CleanSomeOs.vhd file. It changes the SID of the virtual machine in a snap with its wizard interface and unlike sysprep you do not need to re-configure localization settings. However if you plan to install Windows SharePoint Services (WSS v3) or Microsoft Office SharePoint Server (MOSS 2007) Beta most likely you will encounter the following error after you run the configuration wizard: System.InvalidOperationException ...

After a little research I found this MSDN article, which describes similar issue with WSS when installing TFS.

One way to go is to install a brand new OS on the VM, but this seemed like a lot of work especially if I needed to install WSS repeatedly and play with it. The suggested solution in the MSDN article did not work for me either. It is possible that my clean installation VHD has already been "tainted" by NewSID, so using sysprep meant going back to square one and installing fresh OS. After a bit more searching I found this blog, which addresses the issue in more suitable way. So all boils down to two major issues: 1. LOCAL SERVICE and NETWORK SERVICE have to members of the local group WSS_WPG and they are not. 2. Multiple registry keys related to WSS have corrupted permissions. The above article describes very well how to fix most of the registry keys. Nevertheless my system had additional entries corrupted in similar way and I had to dig in the log file and fix them. In addition I noticed that there is no need to assign privileges to registry entries.

I found the following corrupted registry entries HCR\AppID\{6002D29F-1366-4523-88C1-56D59BFEF8CB} and HCR\AppID\{58F1D482-A132-4297-9B8A-F8E4E600CDF6} . In addition the whole branch HLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0 seems to be with corrupted permissions, so instead of fixing the underlying registry keys one by one I simply deleted the rouge permission entries for the whole branch.

All of the above registry keys have the same issue. They have duplicate permission entries for the same users and groups. One entry inherited from the branch above and the other was "non inherited" . To fix this I deleted all entries with "non inherited" and selected "Replace permissions..." to populate the changes to the whole branch.

If after all this you still get similar errors. Click on the link to the log file and search for "InvalidOperation".

When you find the error line, browse couple of lines above and look for "The name of the registry to be secured...". This will give you the registry key with corrupted permissions. Fix it and try again.


Wednesday, September 20, 2006

Johnathan Goodyear of ASPSoft talks about MasterPages in ASP.NET v2.0

Tonight at the SCDNUG meeting Jon Goodyear from ASPSoft gave an excellent demo on some tricks with MasterPages. The examples were original and useful. If you use or are about to use MasterPages in your projects I highly recommend this presentation/demo. Jon will be speaking next in Orlando, Thursday October 26, 2006 7:00 PM. For more information visit ONETUG. Dovizhdane!

Monday, September 18, 2006

Deploying SharePoint WebParts in development environment.

Developing SharePoint WebParts with generic controls is a straight forward task. For such WebParts we can always use a development Web site in our Visual Studio environment to work on the details and then deploy the control to WSS. With complex WepParts using specific WSS features this is not the case. The control has to be deployed to the WSS server after each and every change. Once you register the control in web.cofig and in your Web site (for more information click here), I found it very convenient to deploy the WebPart directly to the _app_bin folder of the Web site. This would work fine only if IIS did not lock your DLL. To work around this I created a Pre-build and Post-build tasks in the VisualStudio project file. Place the script files in your project folder and specify the server name. StopAppPool.vbs
strComputer = "[server name]" Set objIIS = GetObject _ ("IIS://" & strComputer & "/W3SVC/AppPools/SharePoint (80)") objIIS.Stop
strComputer = "[server name]" Set objIIS = GetObject _ ("IIS://" & strComputer & "/W3SVC/AppPools/SharePoint (80)") objIIS.Start

Both tasks execute VBScript that stops and then starts the application pool of the Web site once the newly built DLL is copied over and your developer life gets a bit simpler. Dovizhdane!

Sunday, September 17, 2006

Using Subversion in Windows development environment

Recently I was asked to research the features of Subversion as a replacement of MS SourceSafe. At the time Subversion sounded Chinese to me, but I kept an open mind and knowing some of the limitations of SourceSafe started looking into this open source SCM. And what a great surprise it was. The product has excellent features, it is very scalable and it is documented very well. In addition the pool of community uploads about it is growing as we speak. The main issue with many open source projects however is that to build a system, which meets your criteria, you need to solve a little puzzle of other software modules, script run-times and UI interfaces. The first one for Subversion is how to run the application: as a share, in server mode or as Web server with Apache. In addition it is important to try out most of the less known modules and determine which one fits your personal and team preferences best. After a week or two of playing around I prepared a short presentation for my team at Global 360. To address some of their comments and suggestions I created windows based migration tool (instead of using some of the available scripts), which proved to be very useful. Some of the main issues I address are: - Creating a process that consistently migrates VSS to SVN - Preserving file and folder history with accurate date/time - Creating an incremental export feature from VSS to SVN - Creating VSS shared files pre processing, for easier transformation of this feature not available in SubVersion. At the same time my colleagues from SCDNUG were looking for meeting topics, which are both engaging for the .Net developers, but not necessarily a Microsoft marketing effort. I immediately decided to put together my notes into a short presentation/tutorial. The goal is "to install Subversion in server mode with authentication and Windows integration within YY minutes". The value in this tutorial is that it concentrates specifically on Windows environment and creating a full featured development environment with automated build based on Subversion in short time. For those of you in the Space Coast area the SCDNUG meeting is at the Space Coast Credit Union Headquarters. Wednesday, November 15, 2006 6:00 PM - 8:00 PM Everybody else interested in this material will be able to download it from this blog soon. Dovizhdane!