Category Archives: .NET

VSeWSS BIN Deployment and CAS Policy Issues

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:

Windows Server, IIS/SharePoint, and NULL SID ‘Audit Failure’ Security Errors

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

System.Configuration Namespace and Obsolete Functions

‘What Really Grinds My Gears’ (WRGMG) topic of the month:

Have you ever wondered why after adding System.Configuration namespace reference you see a link to System.configuration assembly (note a small ‘c’ instead of the capital one)?

And why calling obsolete functions in order to access your AppSettings through System.Configuration.ConfigurationSettings.AppSettings["myKey"] doesn’t require you adding any additional references, but using System.Configuration.ConfigurationManager.AppSettings["myKey"] requires you going to the project’s Add Reference dialog and adding System.Configuration explicitly?

The reason for that is unfortunately somewhat poor framework design, in particular backward compatibility implementation. In .NET versions starting from 2.0, class System.Configuration.ConfigurationSettings is actually stored in System.dll, and is basically a stub pointing to System.Configuration.ConfigurationManager, which exists in System.configuration.dll (note again small ‘c’).

Here is a good explanation in one of the older blog posts System.configuration.

However, as always the ultimate reference is good ole’ Reflector, which allows you to find exactly where each class is stored, and to peek inside implementation details. Such as delegated calls from deprecated stub class ConfigurationSettings (System.dll) to the new ConfigurationManager (System.configuration.dll).

How to Locate Assembly in GAC

Here is a simple step by step process of how to locate an assembly in GAC if you want to take a copy of it, or maybe add an additional debug information .pdb-file for remote debugging purposes.

  • open command prompt
  • change the current folder to c:\windows\assembly (%SystemRoot%\assembly)
  • navigate to GAC_MSIL folder – that is where most of the time you will find the assembly
    (the list of all other folders in Assembly, with explanation for some of them, is below)
  • find the folder name with your assembly name without extension and navigate to it
  • additionally navigate down one more folder with the version information, and your assembly should be in that folder

Structure of Assembly folder

Here are examples of what you might see in Assembly folder on different computers:

 Windows XP 32-bit workstation:
– GAC
– GAC_32
– GAC_MSIL
– NativeImages1_v1.1.4322
– NativeImages_v2.0.50727_32
– temp
– tmp

Windows Server 2008 64-bit server:
– GAC
– GAC_32
– GAC_64
– GAC_MSIL
– NativeImages_v2.0.50727_32
– NativeImages_v2.0.50727_64
– temp
– tmp

  • NativeImages… – folders used for native images, which are typically compiled by ngen.exe.
  • tmp folder used for installation assemblies to GAC
  • temp folder is for uninstallation from GAC

Here are some ‘under the hood’ details on GAC Temp and Tmp folders and Install and Uninstall of assemblies.

Opening GAC assemblies with .NET Reflector 

If you are using .NET Reflector there are two things you can do to look what’s inside that assembly from GAC:

  1. make a copy of your assembly from GAC folder to a local folder (the steps explained above) and open the assembly from that local folder
  2. edit your reflector settings file: reflector.cfg, and add the following GAC paths there, then you should be able to open assembly right from open menu:
    [AssemblyCache]

    “%SystemRoot%\Assembly”
    “%SystemRoot%\Assembly\GAC”
    “%SystemRoot%\Assembly\GAC_MSIL”
    “%SystemRoot%\Assembly\GAC_32”
    “%SystemRoot%\Assembly\GAC_64”