Now a Part of the Software AG Family

After three and a half years at JackBe I begin a new stage in my career at Software AG as a senior software engineer continuing to enhance JackBe's real-time operational intelligence offering for SharePoint. The public announcement just went out that we have been acquired by Software AG and I am very excited to be a part of the Software AG family. 

Fixed: Debugger Unable to Attach to Working Process in Visual Studio 2010 for SharePoint

After years of working on SharePoint you think I would have learned certain things by now such as, don't rename a solution and deploy it to a SharePoint farm as the same solution with the original name. Nooooo.

In case you're wondering what happened after accomplishing such a brilliant feat my debugger was not able to attach to the infamous w3sp.exe worker process. Instead I received the following error:

"Unable to start debugging on the web server. The debugger is not properly installed..."

After defaulting to blaming SharePoint (as most us are guilty of) I then did the obvious and searched online for a possible solution. Coming up empty handed I noticed that I had two solutions in the farm that were from the same code base but with different names (hand slaps forehead). Removing both solutions manually and re-deploying the renamed solution fixed the problem.

Lessons Learned Using the SharePoint Service Locator Pattern

Having wrestled with maintaining separate code bases for both SharePoint 2007 and 2010 I finally got to the point where I had some time to rethink strategy and that's when I came across Sohel's blog which explained a solution using the SharePoint Service Locator Pattern. Having just finished implementing this pattern I now can see some of the *huge* benefits, this approach provides. Here are a few:

• Creating loose decoupling of code that is modular which enables a developer to make changes to dependencies without needing to recompile the existing code base. 
• Easy write mocks and stubs for unit tests due to the dependency injection provided by the Service Locator 
• Consolidation of repetitive code into a single code base 

After implementing this solution I wanted to list out some issues (work in progress) that I came across and how I fixed them:

Issue #1
SharePointServiceLocator.GetCurrent() threw a null reference exception

Solution to Issue #1
I was making calls to SharePointServiceLocator.GetCurrent() within the constructor of my application pages in SharePoint. For example, if I have a class named: MyClass, the constructor would look like:

public MyClass()
{
  SharePointServiceLocator.GetCurrent();
}

Moving the call, SharePointServiceLocator.GetCurrent(), to another location outside the constructor fixed the problem. Apparently the ServiceLocator instance is not instantiated until later in the page load cycle.

Issue #2
"Access Denied" error when registering mappings

Solution to Issue #2
This can happen when adding mappings at the Farm level (default setting for SP 2010 and the only option for SP 2007) in the SPWeb context. The solution is to create a Farm scoped feature and add register the mappings within the 'FeatureInstalled" event handler.

Issue #3
Type mappings are cleared from cache at the site collection level but not at the Farm level

Solution to Issue #3
Chris Keyser discussed this issue and a work around here: http://blogs.msdn.com/b/chriskeyser/archive/2011/01/20/handling-sharepointservicelocator-failures-due-to-caching.aspx

Managing Exceptions Using Delegates

Now that you have perfect code that follows Microsoft's Exception Management Practices for SharePoint ;) you may be wondering..."Is there a way I can get rid of all the *extra* try / catch / finally blocks?" Well this post is to help provide an option that I recently implemented (as a side note if you have other options please feel free to comment below).

Don't let this example steer you toward catching general exceptions as the norm. This example is mainly to help provide some guidance on abstracting exception handling but not at the risk of generalizing exception management.

-The first step is to become familiar with Delegates in C# (if you are not already familiar). 

-Next you will need to create a class with at least two methods that will serve as the Exception Manager. Each method will receive a Delegate, as a parameter, that points to the Routine that is being wrapped. The first method will only handle exceptions for Actions (nothing is returned by the Routine). The second method will handle exceptions for Functions (something is returned by the Routine)

-Finally you will need to wrap a Routine call using a Delegate pointer to that routine and pass it to either method in the Exception Manager class.

You can see the result in the following example. You can also download a code sample from my SkyDrive.

Before:

 try  
 {  
  DoSomething();  
 }  
 catch(Exception ex)  
 {  
  //Handle Exception  
 }  
 finally  
 {  
 //Continue...  
 }  

After:

 ExceptionManager.ProcessFunc(() => DoSomething());  

SharePoint 2010 Web Part Feature Clean Up

Reading through "Inside Microsoft SharePoint 2010" I came across a section on page 192 titled, "Deleting Web Part Template Files at Feature Deactivation". I thought the suggestion to remove the .webpart template file from the Web Part gallery was worth writing about. In case you never tried this use case, attaching a SharePoint Web Part to a feature in SharePoint only supports adding a .webpart template file to the Web Part gallery upon feature activation. Deactivating the feature doesn't remove the .webpart template file which is why I recommend adding a feature event handler that removes this file from the gallery when deactivating your Web Part feature.  Here is the sample code segment taken from the book referenced above to remove the template file:

public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {



      SPSite siteCollection = (SPSite)properties.Feature.Parent;

      SPWeb site = siteCollection.RootWeb;



      List<SPFile> FilesToDelete = new List<SPFile>();

      // figure out which Web Part template files need to be deleted

      SPList WebPartGallery = site.Lists["Web Part Gallery"];

      foreach (SPListItem WebPartTemplateFile in WebPartGallery.Items) {

        if (WebPartTemplateFile.File.Name.Contains("put your .webpart file title here")) {

          FilesToDelete.Add(WebPartTemplateFile.File);

        }

      }



      // delete Web Part template files 

      foreach (SPFile file in FilesToDelete) {

        file.Delete();

      }



    }

As a developer in training I welcome any constructive feedback. Please feel free to comment below. Thanks.

Expanding VMWare Hard Disk with VMWare Player 4.0 Installed

After I finished setting up my VMWare hard disk using VMWare Player 4.0 I was down to less than 1 GB of hard disk space left on the player. The instructions to expand the disk only went up to version 3.x and I was unable to locate vmware-vdiskmanager to perform the operation. Here are the steps you need to take to expand your hard disk with VMWare Player 4.0:

1) Download and install VMware Virtual Disk Development Kit

2) Browse to the VVDDK bin directory and run: vmware-vdiskmanager -x 60Gb vm.vmdk

   - Adjust the size of the disk from 60 Gb to whatever suits you

   - Be sure to update the path of your VMDK file

3) Go here to update the guest operating system so it knows the new disk size if it is partitioned

Including Mapped Folders External to the SharePoint Solution

Recently I was refactoring a SharePoint project and wanted to be able to move the Resources mapped folder to a location external to my SharePoint project. In case you're wondering the reason, I'm working with both SharePoint 2007 and 2010 and I'd like to be able to consolidate as much code as possible.

Here are the steps I took:

1) Add the mapped folder to the SharePoint solution
2) Move the folder to the new, external, location
3) Create a symbolic link to the mapped folder and point it at the original location of the mapped folder using mklink (http://technet.microsoft.com/en-us/library/cc753194%28WS.10%29.aspx)

After these steps the Resources folder should still show up in your SharePoint solution package even though it's actually located outside the solution.