mylifeinaminute.com

I’ve posted an updated version of the C# project template for solution packages (.wsp) here.

Changes:

• Altered CreateCabDDF.vbs to use short directory names to fix errors with directories being too many characters.

Accessing web parts from a SharePoint web part can be a challenge when attempting to do things “the right way”. “The right way” includes deployment to a virtual directory “bin” folder instead of the GAC. The challenge is that your web part will not have rights to access any web services due to restricted permission level (you don’t run into this when your dll is deployed to the GAC since your web part is then running in a Full Trust situation). So, how do you overcome this obstacle? With CAS (or Code Access Security) policies.

Steps:

1. Create a new/custom trust policy file. It is recommended that you start with “wss_minimaltrust.config”. The current policy files can be found at %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\CONFIG. You can copy the previously mentioned “wss_minimaltrust.config” file as a starting point and rename to fit your needs (i.e. WSS_CustomTrust.config).
2. Under the <PermissionSets> node of the XML file, create a new permission set.

   1. <PermissionSet class="NamedPermissionSet" version="1" Description="Web Part Custom Permissions" Name="WebPartCustomPermissions">
      <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
      <IPermission class="SecurityPermission" version="1" Flags="Execution" />
      <IPermission version="1" Unrestricted="True" class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Unrestricted="True" version="1">
      <ConnectAccess>
      <URI uri="$OriginHost$" />
      <URI uri="http://www\.microsoft\.com/.*" />
      </ConnectAccess>
      </IPermission>
      </PermissionSet>
      

3. Under the <CodeGroup> node of the XML file, create a new code group node.

   1. <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="WebPartCustomPermissions">
      <IMembershipCondition
      version="1"
      Name="CustomWebPart"
      class="StrongNameMembershipCondition"
      PublicKeyBlob="hex truncated"
      AssemblyVersion="1.0.0.0" />
      </CodeGroup>
      

   2. To determine the value for the PublicKeyBlob attribute, use the secutil.exe program from the command prompt.

      
      secutil.exe -hex -s MyAssemblyName.dll
      

4. In the web.config for your web application, you then add a reference under the <securityPolicy> node as follows:

   
   <trustLevel name="WSS_Custom" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\WSS_CustomTrust.config" />
   

5. Update your web.config to use the newly referenced custom policy:

   
   <trust level="WSS_Custom" originUrl="" />
   

6. Finally, reset your web application with a quick iisreset.exe from the command line.

Now, to answer the question of why we should go through the hurdles of a custom security policy when we could just deploy to the GAC and be done with it.

In some situations, a GAC deployment does make sense. You own the server, it’s used internally and not accessed by the outside world, etc.. If on the hand your are in some type of shared environment, or are developing web parts for distribution, having your custom web parts packaged correctly will be a boon to your end users. Administrators don’t have to worry about a malicious library going into the GAC, and your code will be guaranteed to work across a number of configurations as you have defined the security.

TechNet has a decent primer on the configuration of SharePoint Server 2007 (MOSS) and ISA Server 2006. Check it out here.

As an alternative to the good ‘ol three finger salute (CTL-ALT-DELETE), you can use CTL-ALT-END. This can be especially handy in an environment other than your local desktop, such as a Terminal Services session.