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:

Merging VMware Fusion/Workstation Virtual Split Disk into a Single VMDK

Every time you create a new virtual machine in VMware Fusion/Workstation, it is always created with a virtual disk (VMDK) split up into 2Gb files. One of the main reasons for that, I guess would be a limitation of FAT-32 file system – maximum file size of 2Gb. However, if you are no longer using FAT file system and would like to convert the default vmdk into one single pre-allocated file, here is what you can do.

In order to convert the existing virtual disk to a single .vmdk file you would need to use a console application ‘VMware Virtual Disk Manager’ located in '/Library/Application Support/VMWare Fusion' folder.

Follow these two steps:

– open your Mac terminal console (Applications -> Utilities -> Terminal) and navigate to the folder with your VMware disk image

– from that folder run the following command (typing VMware’s diskmanager path with backslash prefixes for space):

/Library/Application\ Support/VMWare\ Fusion/vmware-diskmanager -r originalSplitDisk.vmdk -t 0 targetSingleDisk.vmdk

If you are running VMware Workstation on Windows, you can use the same command with the only difference that vmware-vdiskmanager.exe would be located in a folder where VMware Workstation was installed, e.g.: C:\Program Files\VMware\VMware Workstation.

Documentation and other examples for VMware Virtual Disk Manager use: