artykul8

There is a bug in Visual Studio Extensions for WSS (including VSeWSS 1.3) – if you are targeting your web part deployment into BIN instead of GAC, you are in for an upleasant surprise, when you realize that you custom access policy is not working.

The reason for this is incorrect assembly reference in manifest.xml, which results in invalid URL for IMembershipCondition element, where binary name has an extra .dll suffix in CAS policy file, just like in the file excerpt below:

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\CONFIG\wss_custom_wss_mediumtrust_guid.config

   ...
  <CodeGroup version="1" PermissionSetName="mycustomwebpart.wsp-12345678-90AB-1234-5678-90ABC3456-1">
    <IMembershipCondition version="1" Name="MyCustomWebPart" Url="$AppDirUrl$/bin/MyCustomWebPart.dll.dll" />
  </CodeGroup>


The solution for this problem is relatively simple:

- in your Visual Studio open WSP View pane, click Refresh button to update solution files

- open manifest.xml and in <Assembly> element remove extension ‘.dll’ from Assembly Name attribute:

<Solution ...>
  ...
  <CodeAccessSecurity>
    <PolicyItem xmlns="http://schemas.microsoft.com/sharepoint/">
      ...
      <Assemblies>
        <Assembly Name="MyCustomWebPart" />
      </Assemblies>
    </PolicyItem>
</Solution>


Additionally, while editing manifest.xml if you like to grant your web part additional security privileges you might need to add a few lines to PermissionSet element. In particular, if you are using MOSS Search or Search Server functionality, such as KeywordQuery or FullTextSqlQuery classes you would need RegistryPermission and FileIOPermission lines.

<PermissionSet class="NamedPermissionSet" version="1" Description="Example">
...
<IPermission class="System.Security.Permissions.RegistryPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
<IPermission class="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"version="1" Unrestricted="true" PathDiscovery="*AllFiles*" />
</PermissionSet>


Additional resources:

• MSDN: Administrator and Developer Guide to Code Access Security in SharePoint Server 2007
• MSDN: Solution Schema
• MSDN: Securing Web Parts in Windows SharePoint Services
• BlueDog Limited post: Code Access Security policies within SharePoint v3

This already became a somewhat old topic, since Microsoft released a proper SharePoint Server 2007 slipstream edition with SP2.

Nonetheless, it is important to remember that if you are planning to install SharePoint Server 2007 or Windows SharePoint Services 3.0, it has to be at least SP2, anything before that is not supported on Windows Server 2008 R2. SharePoint Team Blog: Install SharePoint Server 2007 on Windows Server 2008 R2

There was a bit of confusion/frustration raised over this topic, because WSS 3.0 slipstream with SP2 came out long ago (April 2009), but MOSS 2007 was for some reasons left behind, and MSDN subscribers saw slipstream SP2 edition only in January 2010.

WSS 3.0 with SP2:
x86: http://www.microsoft.com/downloads/details.aspx?FamilyId=EF93E453-75F1-45DF-8C6F-4565E8549C2A&displaylang=en
x64: http://www.microsoft.com/downloads/details.aspx?familyid=9FB41E51-CB03-4B47-B89A-396786492CBA&displaylang=en

MOSS 2007 with SP2 (trial):
x86: http://www.microsoft.com/downloads/details.aspx?FamilyID=2e6e5a9c-ebf6-4f7f-8467-f4de6bd6b831&displaylang=en
x64: http://www.microsoft.com/downloads/details.aspx?FamilyID=3015fde4-85f6-4cbc-812d-55701fbfb563&displaylang=en

I stumbled across this issue, while troubleshooting errors accessing host-named SharePoint sites locally from within a web server (sites with specified host headers different from local server name).
While I had no problems accessing the same site from another computer, I could not login and access any pages locally. I was constantly prompted for user name and password receiving access errors, while my Security event log was getting filled with ‘Audit Failure’ log messages about NULL SID: “An account failed to log on. Security ID: NULL SID”.

After eliminating all possible causes – NLB, SharePoint site configuration, IIS security and settings – it turned out that it wasn’t even IIS- or SharePoint-related issue at all. Starting with Windows Server 2003 SP1 and higher (Windows Server 2008 and R2 editions in that list as well), as a security measure Microsoft introduced a loopback check to prevent man-in-the-middle (MITM) attack, when a malicious application (such as spyware) can try to eavesdrop communication with a remote server by introducing itself locally as a remote host. Please note: loopback check happens only when host headers do not match local computer name.

The symptoms and solutions are described in Microsoft KB article: http://support.microsoft.com/kb/896861
Additionally a few other related issues (accessing network shares, etc) are outlined in two more KB articles: http://support.microsoft.com/kb/887993 and http://support.microsoft.com/kb/926642.

To deal with this issue you have two options: either explicitly specify all host headers in the registry (the most secure, but also the most cumbersome solution), or disable loopback check entirely.

If you decide to opt for completely disabling loopback check (on a development or test server), here is one command line you can achieve it through. Please remember to restart your server after changing the registry!

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /t REG_DWORD /d 1

This one is the biggest pet peeve about SharePoint development for me right now.

Microsoft SharePoint product team is blowing all bells and whistles, announcing SharePoint 2010, and how important it is to switch to 64-bit environment, while poor SharePoint 2007 left in the dust and crippled with the only development extension working on 64-bit, which is still in CTP phase Visual Studio Extensions 1.3 (March 2009 CTP).

VSeWSS 1.3 was promised almost half a year ago to become a final release in the spring of 2009, and later on in one of the dev blogs mentioned July 2009 release date, but up to this date there hasn’t been any final version announcement or releases yet.

Also, if you are looking for more information and code snippets, you may still find useful referring to the samples that come with Visual Studio Extensions 1.1 for Visual Studio 2005 User Guide, which have been removed from 1.3 release.

I’m keeping my fingers crossed for the new release to come soon, while blaming it all for the recession…