Setting BCS Secondary Fields Programmatically in SharePoint 2010

Phew, that was quite a battle. I have been writing some code to import values from a CSV file into some custom lists in SharePoint (I realise that there are, of course, plenty of other ways to import into SharePoint, such as using PowerShell or a third party app., but specific needs call for special handling), and one of the requirements is to import data into External Columns in the SharePoint list.

Original this process used the GetSecondaryFieldNames() method of the SPBusinessDataField instance to get the internal names of each of the secondary fields, and then combined each of those with the internal name of the SPBusinessDataField to create the displayname value for each secondary field. The list item fields could then be set using these displayname values.

This worked fine in the dev environment... but of course the real workd is different! Researching the failure of this process on the target machine showed that the display names for the secondary fields did not contain the values from the GetSecondaryFieldNames() call (PowerShell allowed me to easily view the Schema XML for the fields in the list, saving the need for a tool like SharePoint Manager).

So, my solution was to seek the secondary field by enumerating through all fields in the list, seeking the field whose:

• "DisplayName" property value starts with the internal name of the related external data field
• "BdcField" property value matches a string value returned by GetSecondaryFieldNames()

This lets me find the required secondary BCS field, and gived me the GUID for use in later populating that field with a value. I then make sure to cache this GUID, meaning on the next pass through this part of the code I can use the cached value rather than re-enumerating all the fields once again.

SharePoint Connection Error in Visual Studio 2010

When running Visual Studio 2010 on a Windows Server 2008 R2 / SQL Server 2008 / SharePoint 2010 development box, even though the logged-in account has local admin rights on the server, I still experienced a SharePoint Connection Error in Visual Studio 2010 on that same Virtual Machine. The text in the error dialog states that "the local SharePoint Server is not available".

Seems the error is caused be the logged-in account having insufficient rights against the SharePoint databases. Log into the SQL Server using the administrator account, and grant rights to the developer account; db_owner rights on the SharePoint configuration and admin database is reported to be sufficient -but as in this instance I was dealing with a development virtual machine, I opted for the easy route of granting sysadmin role to the dev user account :-)

Unlearning My Development Process

Two years - that's about the length of time I have been developing on the SharePoint 2007 platform. Over that time I have been using roughly the same development process and tools, with a few additions to my "tool-belt", and a few tweaks to the steps in the process. But no radical shifts.

Must admit I have always developed from the point of view of creating a deployable solution first, and adding functionality to that solution as I go along. Means that when the functionality is working and tested then I have a package ready to ship. Rather that than developing the packaging as a final task, and then needing to retest the deployment outcomes.

And I like CONTROL over the solution, so I have been hand-crafting some of the solution files. You know the ones - the ones that WSPBuilder hides away. I did try that tool some time ago, but had problems with certain complexities in solutions, so returned to my old ways.

Well, it's time to kick that habit and learn something new! So now that I am starting a major new project I am also trying out a new approach to my day-to-day SharePoint development. First change is to incorporate SPVisualDev from the very start, and I must say I am really impressed with the ease it offers in adding fields, content types and lists to features. It even makes adding resource files nice n'easy, so encourages me to build the features ready for localisation if required in future (I know, I know, "YAGNI", but given that the tool makes this capability easy I'm all for its inclusion).

Then I am using WSPBuilder to create the WSP files (though am disabling the "Cleanup" operation so I can still get to the manifest.xml and ddf files if necessary!).

So far so good. Now all I need is a tool to generate a batch file with the appropriate stsadm commands for deploying a set of WSP files, and I'll be "sweet as, bro" (it's a kiwi thing!)

I'll let you know what else I change for the better.

Debugging SharePoint Timer Jobs

I am sure it has been written about elsewhere, but here is the way in which I have been debugging timer jobs.

Add the PDB File to the GAC
The PDB file needs to be in the GAC for debugging in Visual Studio. You can add this file through a feature manifest file, but you are unlikely to want to deploy the PDB to the GAC on your production server, so a better way on the dev server is to directly place files in the GAC. To do this, map a drive in windows explorer to

\\[your server name]\c$\windows\assembly

This bypasses the windows explorer shell special handling for this folder, and allows you to copy and paste files as normal without using GACUTIL.

In the GAC_MSIL subfolder, find the subfolder corresponding to the name of your assembly. Below there will be one or more version subfolders. Find the latests version subfolder., and copy your timer job dll and pdb file (built in debug mode!) to this folder.

If this copy action is denied, open the Services administrative tool, and STOP the Windows SharePoint Services Timer service. Apply an IISRESET from the command line, and then attempt to copy the files again - resetting those two services should remove the lock on the dll. After copying the files, make sure to restart the SharePoint Timer service!

I did have one occasion where the Timer Service "hung" whilst attempting to restart. I found that ending OWSTIMER in the Windows Task Manager cleared this hiccup.

Debugging In Visual Studio
Set a breakpoint in your timer job code, and then open the "Attach to Process" dialog from the Debug menu. Check the box at the bottom of the dialog titled "Show Processes from All User", and select OWSTIMER.EXE from the list of available processes. Click the Attach button.... and hopefully your breakpoint should display as a nice fat filled dot!

An outlined breakpoint (an empty circle) rather than a filled breakpoint means VS cannot match your code against the running code, and so something in the above process has not worked for you. Worked for me, though! Perhaps you have copied your dll and PDB files to the wrong GAC subfolder?

Triggering the Job
Now you just need to trigger your timer job. One suggestion for this is to modify the schedule of the job to occur frequently - have a look at this post on blah!bLaH!BLOG!! for how to do that.

I have a design pattern in place where the schedule for custom timer jobs are configured in a configuration list in the WSS site. When the feature containing the timer job is activated, a feature receiver reads the configuration data from the list and sets the timer job accordingly. Works nicely when you want to manipulate schedules and other data relating to the timer job.

One Last Timer Job Tip...
If you need to persist data across executions of your timer job, here's how from James Mann.

Debugging SharePoint Custom Code

Great article about debugging SharePoint applications. It also suggests designing code to facilitate debugging, which seems a very sensible idea to me (particularly when combined with the idea of designing to "fail fast", thereby ensuring that exceptions are not hidden by the code)

One MOSS site I developed recently includes several event handlers and timer jobs. Each of these includes a common class to write error messages to a custom list in the site when exceptions occur. Having a central location within the site to monitor error message has proven effective - one advantage is that I can set up alerts in case of exceptions.

Using the facilities native to SharePoint (liist, alerts, etc) simplifies development and gives huge flexibility in using the resulting data.