Here’s the deal, sometimes when you write SharePoint code on your dev machine, it deploys just fine. When you package it and deploy it on another server, it doesn’t always work so hot. Furthermore, you might sometimes experience this exception on dev box:

Error occurred in deployment step ‘Add Solution’: Failed to load receiver assembly “…”.
System.IO.FileNotFoundException: Could not load file or assembly ‘…’ or one of its dependencies. The system cannot find the file specified.
at …
at …
at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject()

So what’s going on here? Well, it’s quite simple, and yet, it is almost haunting. The fact is, Visual Studio doesn’t always pick up your changes when it builds your solution. It seems to think that that if you haven’t changed the code, when you build your solution it shouldn’t compile a new DLL. That annoys me because sometimes I actually need it to rebuild that DLL for me. If I tell VS to build, I’m thinking it’s going to recompile all of the DLLs for me (note to self: build != recompile). As my friend James S. says, “There’s your problem.” In other words, “stop thinking; start doing.”

So, I’ve been paranoid about packaging my code. First, I intend to clean up my dev box and run a test deployment on it as an ITPro would on his/her Test environment. Second, I deploy to a Test farm. So the goal in VS is to get a fully compiled .sln file. To confidently get that, I perform a manual clean, build, package, and then test it.

Here are my steps:
1. Right-click the project and Retract
2. Verify the feature is gone from the filesystem, the DLLs are no longer in the GAC, etc.
3. In Visual Studio’s Solution Explorer window, click Show all files
4. Control-click bin, obj, pkj, pkjobj
5. Delete and confirm delete
6. Right-click the project and Build
7. Right-click the project and Package

Now I know for sure that everything in the package is using the latest code, settings, etc.
And yes, I realize there is a Clean function. I don’t trust it. Do you?


Deploying Custom Help with SharePoint 2010

Custom help in SharePoint 2010 is not difficult to install, once you’ve been through it. I found some helpful blogs for using the SharePoint utility HCInstall. However, I didn’t want to use a command-line utility on a FeatureActivated receiver. So I decided to dig into it and see if I couldn’t just do in code what it does. If you intend to install help thru an install script, use the utility provided by Microsoft. If you intend to install help thru features (ie, install help on demand as needed), then this post is for you.

If you haven’t used HcInstal, no worries. I’d like to walk thru what the HCInstal.exe code does. It’s not a lot, actually. You can use it as a stand-alone utility. Or, you can drop it in your project with a Reference.

By doing so, you’ll need a using declarative, namely Microsoft.SharePoint.Help.HcInstaller.


Hcinstall has one public class (HcInstaller_Main) and one internal (HiGovernor). Here’s an adjusted view from Reflector.

The real work is done in ParseArgs and StartIt().

* ParseArgs() does just that, parses the command line arguements, or your arguements if you’ve referenced the EXE in your project and utilized the HcInstaller_Main class’ Main() method.

* StartIt() then uses the SharePoint help object model. Did you know that it existed? In the online SharePoint 2010 SDK, found on MSDN here SharePoint help, there is little reference to it. [Notice it’s found in the Administration section. However, the namespace is not within the Administration namespace, and the dll containing the namespace is not the Admin dll, either, it’s just the Microsoft.SharePoint.dll.  Back to our work…]  So StartIt() then does the work based on the arguments. If you chose to install a help file, then it calls the Microsoft.SharePoint.Help.SPHelpMerge() method. The SDK content is here, SPHelpMerge. Notice there is no SP2010 version of this SDK helpfile, which is a bummer. But that’s okay, it appears that nothing has changed in it.

The SPHelpMerge class has 4 main methods.

  1. InstallOneHelpCollection
  2. InstallAllHelpCollections
  3. UninstallOneHelpCollection
  4. UninstallAllHelpCollections

In my current testing, I have not found UninstallOneHelpCollection to work. So, on my vm, I’m using UninstallAllHelpCollections for removing the help collections. I’ve noticed this carries thru to hcinstal.exe ( hcinstal.exe /act uninstallonehelpcollection) as well. If anyone has any info on this, I’d appreciate it.

For now, however, I’m using the SPHelpMerge.InstallOneHelpCollection() and it’s working great. If you need a sample help collection to install, you can start with this one from Code Project

Using the SPHelpMerge class, you’ll have code like this:

Using the SPHelpMerge class to install an HCCab file. Do NOT include the in the parameter as it is for namespace not filename.

The parameters are hardly documented. Changing most of them did not affect my install.

And there you have it. It only takes a couple of lines of code to install your help content file! Now you can include these lines into a Farm-scoped feature wrapped up in a Visual Studio SharePoint Feature project, and viola!

SharePoint Connections at the SharePoint Conference

Mark Freeman posted an article on the social events at SPC.

Edit: If you have news of any other events, please post them in the comments and I’ll be sure to update this post and Mark will probably update his as well.


Creating Powershell pre-build and post-build events for Visual Studio projects

I had a need to create a cab file containing the files from two project folders, plus a file at the root. Instead of learning Visual Studio addins, I created a PowerShell script that ran on Visual Studio’s pre-build event.  Using the post-build would have meant that the cab file was created after the SharePoint wsp package. The pre-build event is the way to go here.  So, first thing I did was create a PowerShell script that in turn, created a cab file. This script makes use of the makecab utility that ships with Visual Studio. To create a cab with this utility, one needs a Diamon Directive File, or ddf. This file contains a set of instructions followed by a list of files.  I’ll post the script at the end of this article, but it’s not really my focus. What really got me tripped up was (1) getting powershell to run and (2) getting parameters into the script correctly – as it turns out, a space makes a difference!  Here are the steps:

First, to do this, you’ll need PowerShell v2 (or better). Version 2 contains the -File cmdlet, which lets you run a script (*.ps1 file) from a powershell prompt. If you run Windows Server 2008 R2, then you have PowerShell v2. Otherwise, you may need to download it.

 Second, you’ll need to set the execution policy. Assuming you are on a dev box (Visual Studio and all), you can set the execution policy to unrestricted, via set-executionpolicy unrestricted. To check your current policy, use get-executionpolicy.

Third, keep in mind Visual Studio is 32-bit, while powershell has both, 32 and 64-bit versions with their own policies. The 32-bit VS should call the 32-bit version of PowerShell. Here is a screenshot showing the different powershell prompts and different execution policies.

Fourth, here is my script that will render arguments to the console. Yep, that’s all it needs to do.

Finally, the passing of parameters from Visual Studio is quirky. When I used “($ProjectDir)” “($ProjectDir)\bin”  Visual Studio passed that to PowerShell as one parameter. When I added a space  “($ProjectDir) ” “($ProjectDir)\bin”  Visual Studio passed that as 2 parameters. Here are the screenshots.

Finally, here is the script that will make the cab file. It’s all about making the ddf file. Enjoy!!

Note: If changing the execution policy at a powershell prompt does not seem to work (ie, Visual Studio still returns an error such as:

------ Rebuild All started: Project: SPProject, Configuration: Debug Any CPU ------

Compile complete -- 0 errors, 1 warnings
  File C:\MakeHCCab.ps1 cannot be loaded because the execution of scripts is disabled
  on this system. Please see "get-help about_signing" for more details.
      + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordE
      + FullyQualifiedErrorId : RuntimeException

 then you can use

powershell -command "set-executionpolicy unrestricted" 

in the prebuild event before the -file command.

Versioning InfoPath Forms

Almost everyone working with InfoPath forms knows that each time they publish a form, it creates a timestamp and a version number for the template. In InfoPath, go to Form Options and you’ll see this dialog:

InfoPath Form Version Dialog

Well, if you need to keep track of the version number for your form, you can make it easy on yourself and others by adding a small field at the bottom of your form. Then in the default value of this field, insert the formula

  = "mso-infoPathSolution"], 'solutionVersion="'), '"')

Formula for Displaying the version number of a form

Here is a simple screenshot that shows the control

InfoPath Form Version Control


And here is what it renders like (screen clipped a lot):

InfoPath version control rendered in InfoPath Forms Services


I hope this helps you keep track of InfoPath forms version numbers. I know it will me.

SharePoint’s Field Level Security – The Overview

If you’re like me, you’re very frustrated that SharePoint doesn’t have a way, out of the box, to handle field-level security.  However, there are several ways to extend SharePoint to make this happen.

  1. Custom Field Controls
  2. Custom Forms (Edit, Display, New Forms)
  3. Custom Event Handlers

I’m going to cover each of these in seperate articles. They cannot be adequately covered in one blog post. Well, they probably can, but I cannot adequately cover them all at once!

To start, I’ll offer just an overview of each before writing up posts for each of them.


Custom Field Controls

These are the truest form of Field Level Security. No matter where the field is used, the control will apply the same security rules — whatever those may be, as this is a custom control you’ll write your own rules. This can be good, or bad. Imagine designing this control to work with multiple sites, site collections, even web applications. How do you design it to function properly across the entire farm?  Answer: you’ll have to wait until that blog post is written! Another issue with using custom field controls is that you have to write a custom control for each type that you’d like to have secured — types being single line of text, multiple lines of text, dates, booleans, etc.

Custom Forms

(Note: I’m focusing on the Edit Form)
The custom edit form is not one that is designed with SharePoint Designer. While you could design one-offs this way, we’re interested in scalable and repeatable designs. The custom edit form that we’re interested in designing is one that can easily be packaged and deployed. This method is more flexible, but isn’t the truest field level security. We’re going to look into custom templates.  This allows us to use a single control (ascx file) that works for multiple forms.  Just point your content type to this control, and viola! A secured edit form!

Also, one could create a custom form that is an application page, deploy it, and then point a content type to that form. TO do so, just update the Form’s <Form> xml node within the Content Type. While that provides a lot of flexibility in the code, ultimately, I’m not looking to replace SharePoint functionality here. I’m really just trying to get Field Level Security implemented.

Custom Event Handlers

Custom Event Handlers are my least favorite method of the three. On the plus side, they are by far the easiest to grasp and implement, they work for any content type, and they are the most familiar to SharePoint developers. So why are they my least favorite? Because they don’t provide any forewarning to the user that security rules exist. The user can interact with the control and seemingly make edits. But when they click the Save button, the security rules get applied, and suddenly the user is told they don’t have the priviledges to make their changes. Imagine making changes to a Word document or Excel spreadsheet, getting all the right info into it, and then when the user saves it, the application throws a message and discards the changes.  Not a great approach, IMO. Another negative is the hassle of dealing with Before and After Properties. Sure, those work for list items in most cases. But what about document libraries?  Document libraries require special attention because the ItemAdding and ItemAdded method must both be used, since AfterProperties aren’t available in ItemAdding while BeforeProperties aren’t available in ItemAdded.

Also, how do you handle the case where the user can update FieldA but not FieldB? Do you keep the changes for FieldA and not FieldB? How do you inform the userFieldA was indeed changed, but FieldB was not? Keep in mind, you can display a message if and when you use the Cancel. If you don’t Cancel the change, you can’t display the message. So you can discard all changes (in this case to A and B) and let the user know. Or, you can accept the change to A and not B, but the user won’t explicitly be told.

I’d love to hear your thoughts on these three options. Another type of workaround would be workflow, but that’s a lot of hassle.

OneNote 2010 Requires the Windows Desktop Experience

I’m trying to copy some code from Reflector into OneNote 2010. Unfortunately, OneNote requires the Windows Desktop Experience. What a bummer. Now my VMs need to have the DE feature installed.

Speaking at HDNUG

This Thursday, 1/13/2011, I’ll be speaking at the Houston .NET User Group, HDNUG. I’ll be speaking on SharePoint development.

I’ll update this post with the links that will be in my presentation.

Information Worker Virtual Machine:

There are about 20 videos here on Channel 9 for developers:

More to come…

Use PowerShell to quickly show your SharePoint Features

I wanted to know what features were installed on my farm. Not just farm-scoped features, but all feature scopes. So I wrote some quick powershell to tackle the job.

Here is a screenshot of the code for easier reading.

Alt text for the script

Script to display all SharePoint features

Here is the code so that you can copy/paste.

Add-PSSnapin Microsoft.SharePoint.Powershell
write-host "Farm scoped features"

# This will display all Farm scoped features
#Get-SPFeature -Farm 

# This will display a specific Farm scoped feature if it exists
Get-SPFeature -Farm | where { $_.Id -eq "319d8f70-eb3a-4b44-9c79-2087a87799d6" }


foreach ($webapp in get-spwebapplication) {

  write-host "Web Application " $webapp.url  

  # All WebApplication scoped features
  #Get-SPFeature -WebApplication $webapp.url 

  # specific WebApplication scoped feature if it exists
  Get-SPFeature -WebApplication $webapp.url | where { $_.Id -eq "0ea1c3b6-6ac0-44aa-9f3f-05e8dbe6d70b" }

  foreach ($site in $webapp.sites) {

    write-host "Site Collection " $site.url 

    # All SiteCollection scoped features
    #Get-SPFeature -Site $site.url 

    #specific SiteCollection scoped feature if it exists
    Get-SPFeature -Site $site.url | where { $_.Id -eq "7094bd89-2cfe-490a-8c7e-fbace37b4a34" }


    foreach ($web in $site.AllWebs) {

      write-host "Web " $web.url 

      # All Web scoped features
      #Get-SPFeature -Web $web 

      # Specific web scoped feature if it exists
      Get-SPFeature -Web $web | where { $_.Id -eq "00bfea71-1e1d-4562-b56a-f05371bb0115" }

write-host "Done"