Archive for July, 2012

VirtualBox and Multiple Monitors

Thursday, July 26th, 2012

As a SharePoint consultant, I really enjoy having a local copy of a full SharePoint server on my laptop. As I am patiently waiting for Windows 8 to release with Client Hyper-V, I’m continuing to use Oracle’s VirtualBox software to host my SharePoint development environments.

With my current engagement, I find myself in my client’s offices Monday through Thursday and at my office on Friday. At my office, I have an external monitor that I use in addition to my laptop’s screen. At my client’s offices, I just have my laptop’s screen to use. Whenever I’m able to have a secondary monitor connected, I like to use VirtualBox’s multiple monitor support to show my VM on both of my screens. VirtualBox achieves this look by opening two windows – each window meant to be maximized on one of the two monitors.

On Fridays I get to use two monitors with two VirtualBox windows. However, come Monday, I typically forget to reset the virtual machine back to one monitor. Even though I’m only using one monitor, VirtualBox still opens two windows for me! With only one monitor, this makes the VM very tough to use. The only remedy is to shut down the VM, reconfigure the setting, and restart the machine; a process that can be quite lengthy on a server with SharePoint 2010 and SQL installed!

I turned to PowerShell to help ease my Monday morning woes. I developed the script below and put a link in my Startup folder so that, each morning when I boot my laptop, all of my VirtualBox VMs will be automatically configured to use the number of monitors that I currently have connected to my laptop.

Fair warning – this was a quick script just for my personal use. While it should work for you, it does not have any error handling to report if things go awry. See the comments in the script for details.

Extracting Zip Files using PowerShell

Tuesday, July 17th, 2012

To help troubleshoot some SharePoint issues, I had a need to analyze some log files that were contained in multiple zip files; one log file per zip file. Since there were several hundred zip files to extract, I figured PowerShell could help! There are several posts I found with example scripts for how to perform this operation. I took pieces from many posts, added some COM object clean-up code, and wrapped this in a function. I hope it helps you in your scripting activities!

The code below is the function I’m using to extract a single zip file. It leverages the Windows Shell COM object (i.e. Windows Explorer) to extract the files by exploiting the fact that Windows Explorer treats zip files as folders. Therefore, the operation can leverage existing file copy methods between two folders.

Latest Code Not Working Quite Right?

Tuesday, July 3rd, 2012

I’m going to start this post with an example. See if you have ever found yourself in this situation when working on developing updates for previously deployed code; most often in a test and/or development environment:

1. I start out with an existing feature receiver that uses a web-scoped feature. The feature is already deployed to my development environment. To make this example very simple to illustrate the issue – this feature receiver will set the web’s title to an arbitrary value. The title will be reset back to its original state when the feature is deactivated.

2. Activating the feature on my test site reveals the following site title change.

3. Now I’m going to illustrate a change to my previously deployed code. Let’s say for example that I wanted the title to be changed to “*** NEW WEB TITLE ***” instead of “EXISTING WEB TITLE”. I’ll make the change on Line 16 of the code above and create a new WSP for deployment.

4. I then open a new PowerShell window and execute the following six PowerShell commands using the same window. These commands will deploy the latest code and reactivate the feature on my test site so I can see the latest change.

5. I will then visit the site to see the change…

What happened? The title didn’t change?! What is wrong?

The problem occurred during Step 4. When the first command deactivated the feature, that cmdlet called the SharePoint DLLs which in turn called the SMayes.SharePoint assembly. This loaded the assembly in the PowerShell.exe process. Once the assembly is loaded, it will not be unloaded.

That’s the issue here: Once a DLL is loaded in a .NET process, it will not and cannot be unloaded!

So what? This means that when I executed the Enable-SPFeature cmdlet, PowerShell was still referring to my old code that was loaded earlier and therefore was not using my updated code! Opening a new PowerShell instance and executing the activation in that instance will cause the latest code to be used since the new process will be getting the updated DLL from the GAC.

In summary: Whenever you are deploying code updates, the proper way to execute the redeployment would include closing the current PowerShell process and opening a new PowerShell process as soon as new assemblies are deployed. This will ensure that further commands, such as feature activations, will not use outdated code.

Note that while the issue I described above pertains specifically to a feature receiver, it would also equally pertain to an event receiver, timer job, or other piece of code within a deployed assembly called by the SharePoint API. This issue is also a general issue across the board whenever a process (PowerShell, W3WP, OWSTimer, etc.) is using a custom-built assembly. This is why, when deploying new assemblies, W3WP is typically recycled. Also ensure that OWSTimer is recycled if there are any timer jobs being deployed.

Happy coding!