Archive | June 2012

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?

Advertisements

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 .HC.cab 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!