Up to last week I used the simple “next, next, finish” single server installations for my developer workstation for SharePoint 2010. Everything including the sandbox worked fine and development went pretty smooth. Last week however I started developing on a new image with a more advanced installation of SharePoint 2010 in which Windows 2008 was setup as a domain controller.

When I launched Visual Studio for the first time to create  a simple Sandboxed WebPart and pressed <F5> to start debugging, I received an error stating that the SPUserCodeV4 service was not running:

The error above was a quite obvious one and easy to fix by just starting this service from the “Services on Server” screen in Central Administrion:

So, I thought I was ready to press <F5> again but now another error appeared stating that Visual Studio was unable to attach to the SPUCWorkerProcess. My first thought was that this was probably some beta issue or an issue caused by not running Visual Studio as an administrator or something like that. My Solution was deployed to the solution gallery anyway so I planned to contiue placing my webpart on the page and attaching the debugger manually if needed. Placing the WebPart on the page however resulted in well ehh…nothing.

In order to confirm I was not doing anything not allowed in my code I changed the WebPart’s functionality to do nothing more then the  classical “Hello, World!”. That didn’t work either which meant I had to dig deeper. After binging around for a while, I found a blogpost by Jie Li in which he describes a PowerShell script to be run on computers that were setup as a domain controller (like mine). After running the PowerShell script below, everything worked fine!

$acl = Get-Acl HKLM:\System\CurrentControlSet\Control\ComputerName
$person = [System.Security.Principal.NTAccount]"Users"
$access = [System.Security.AccessControl.RegistryRights]::FullControl
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]::None
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person, $access, $inheritance, $propagation, $type)
$acl.AddAccessRule($rule)
Set-Acl HKLM:\System\CurrentControlSet\Control\ComputerName $acl

Tags: #SP2010NL

There are many cases in which you want to retrieve a SPList object. In some cases you can’t just assume the list exists so before referencing it, you’d want to check this first. Within the WSS v3 object model there was no neat way to check for the existence of a list. Indexing into a SPListCollection based on for example the name of a non-existing list resulted in a System.NullReferenceException. For this reason, it was quite common to check for the existence of a SPList whitin a try-catch block.

In SharePoint 2010’s object model the SPListCollection Class has a new method called “TryGetList”. This method does exactly what the name suspects. Within the SPListCollection is being searched to a SPList with the specified name. If the list does not exist, a null reference is returned

SPSite currentSite = SPContext.Current.Site;
SPList mySPList = currentSite.RootWeb.Lists.TryGetList("VoorbeeldLijst");

if (mySPList != null)
{
  ...
  ...
}


Tags: #SP2010NL