I’ve been working on a sample app for SharePoint 2010 that demonstrates the Sync Framework, Custom Service Applications and a Custom Timer.

There’s a few good articles on MSDN and elsewhere that document the process of creating a custom timer job pretty well.  This hasn’t changed much in 2010 – if at all – from what I can see.  However, the samples don’t show you how to create a Service/Server level job definition, so here’s my small addendum to show how to do this.

Creating a Service Job

When you construct a new job definition – custom or otherwise – there are two constructors you use:

protected SPJobDefinition(string name, SPWebApplication webApplication, SPServer server, SPJobLockType lockType);

protected SPJobDefinition(string name, SPService service, SPServer server, SPJobLockType lockType);

You can override the constructors in your custom job.  For a service timer you should use the 2nd constructor.  In this case, the lockType can only be Job or None.

Persisted Configuration

If you take a look at the definition of SPJobDefinition you will notice that it inherits SPPersistedObject.  The MSDN sample talks about creating a separate persisted object for the job configuration data.  This is not necessary.  Instead, you can add your [Persisted] public fields directly to your custom job definition.

Errors

When you run a timer job that is created for a service, the service must be running – yes, strangely :)  If it’s not the job will fail silently and you have to look in the logs to see the error.  There doesn’t seem to be any way to catch this exception.

Weirdness

I managed to waste about 3 hours trying to track down why timer execution of my service method was failing when calling it directly would work.  There is no special logic in the timer.  The bug I was seeing was something that I had fixed previously so I was baffled why it was failing for the timer and not for my web page.

Overnight, and after a few IISResets, redeployments and reboots, it came right and now works correctly.  I also made sure the GAC was cleared out between deployments.  It seems to me like there was an old version of the service application dll that the timer was using and the rest of the site wasn’t.  I cant prove this but that’s certainly how it appeared.

Debugging

As Andrew Connell points out in his articles, you need to fire an Assert() to get the debugger to stop in the job Execute() method. 

#if DEBUG
            System.Diagnostics.Trace.Assert(false);
#endif

Attaching to OWTIMER.exe is not enough.  However, for me, this Assert does not popup a message – you need to attached to OWTIMER first.  This maybe a SP or VS 2010 thing.

Enjoy :)

The SP User Groups are organising a nation wide launch party for SharePoint 2010 on May 13.  If your interested then register here: http://www.dot.net.nz/Lists/SharePoint2010Survey/overview.aspx

I’ve been enjoying the stability and extra performance of a 64 bit OS for about 2 years now so I am surprise and somewhat disappointed that the latest round of goodness from Microsoft – i.e. SharePoint 2010, Office 2010 and Visual Studio 2010 have some annoying incompatibilities in this mode.

Datasheet View of  a SharePoint list with a 64 bit version of Office does not work, you just get this annoying dialog:

Apparently this is because the ActiveX control is not available for 64 bit OS’s.  I have only tested on 2008 R2 server – Windows 7 64 bit may be ok.

Also, Intellitrace in Visual Studio – aka Historical Debugging - does not support SharePoint (or any 64 bit app?).

I’m sure Microsoft are aware of these limitations and will offer solutions in due course – but really, 64 bit has been coming for a while and I think we can expect not to see this sort of incompatibility, especially for Office. 

For me this has tarnished my experience only a tad, but overall, 64 bit everywhere is better than 32 bit in the same way that cake is better than two week old bagels.

I’m in the deep end at the moment.  SharePoint 2010 provides an improved mechanism for service applications that replaces Shared Service Providers.  I’m not ready to say I understand how these beasts (and they are a beast) work yet, but I can tell you that at this early stage of the 2010 release cycle (i.e. very nearly RTM) there is bugger-all documentation available.  The following list may prove useful if you want to get started learning this.

Andrew Connell has a video and some sample code from Channel9.  The video is very hard to watch but there are a few tid-bits that may prove useful.  The sample code is also useful but not as complete as I’d like (for the client end there is only a powershell script to test).

Tony Bierman has a 4 part series that steps through the process and explains the various files in some detail, but again, this is not totally complete (there are no sample PS scripts) and the example is unusal (a web service for autocomplete).  Plus he has added a few extra features to the code which are useful I’m sure – but confusing when you are learning.

MSDN of course has a bunch of sample and documentation – but this seems to be the most incomplete version I have found – I’m sure it will improve when SharePoint is actually released.  Sridhar Raghunathan has posted a fixed version of this sample but it is also somewhat incomplete (no admin pages or deployment scripts).

There is another one here that I haven’t looked at.

I also got my hands on a presentation and some training kit material (not public yet sorry) which helped a bit.

My current solution is a blend of all of these samples – which are generally similar.  How I just need to make it work.

More later…

Loving SharePoint 2010 :) We are doing a LOT of work with this baby and so far it’s been a fairly painless experience.  I’m currently diving deep into creating a custom Service Application… more on these later.

It’s the little things that make the difference for day to day SharePoint dev.  Replaceable parameters are a fantastic worry-removing new features.  In the past (SP 07) you had to include full assembly reference in .ASPX and similar files thus:

SomeNamespace.SomeClass, SomeAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6017a297d36052bf

The problems occur when you update the version of change an assembly name etc – things that can happen quite often during the early stages of a product life cycle.  Getting the key is also a complete PITA.

With replaceable parameters you can let Visual Studio worry about these.

SomeNamespace.SomeClass, $SharePoint.Project.AssemblyFullName$

The parameter will be replace during packaging.  There is a bunch of different parameters you can use in various types of files like XML and ASPX.

HOWEVER, not all files are processed.  In my case I have a .SVC file (for WCF).  Luckily, it’s very easy to add processing for this. 

1. In Visual Studio, right click the SharePoint project and select Unload.
   
2. Right click the project again and select Edit
3. At the end of the first property group in the proj file, add this: 
   

You can list as many extensions as you want, seperated by ;.

Full documentation is on MSDN.

Enjoy

Here’s an example of great UX.  Error reporting and possible solutions are presented in SharePoint 2010 Central Admin thus:

Selecting an item in the list displays:

Key Points.

1) The categorisation of the lists.

2) The message in the list is human readable – not just some stupid error number and cryptic message.

3) The explanation of the problem is clear and concise.

4) The remedy is similarly understandable

and, best of all

5) The remedy contains a link to the solution

Wouldn’t it be fantastic if all products were so well designed?  How much more productive would programming be if Visual Studio worked like this.  eg:

Warning: You have a compiler error in a LINQ query with a join.  Click here for a solution.

Clicking would show the native compiler error, a few links to MSDN documentation, the top 10 web search hits for the issue and a link to see more in Bing/Google.

You could maybe also add in automatic refactoring, tied to code analysis rules or whatever.

Hey, how about this one:

Warning: The application you are creating has already been created by 12,875,435 other developers.  Would you like to download one of these instead?

:)

Yesturday Microsoft announced the Visual Studio 2008 version of Visual Studio extensions for WSS (v 1.2). It is available for download now!  This took me by surprise as I thought it was scheduled for next month - but earlier is better!

Also, checkout the spunky new site for SharePoint developers:  http://www.mssharepointdeveloper.com/.  This is a great central resource for getting started with SharePoint dev.  It contains a bunch of FREE learning material - 10 Virtual Hands On Labs to be precise - and links to other goodies.

FYI: A gang of kiwi's were heavily involved in creating some of this material, including myself and some other's at Intergen and of course Paul Andrew.

Today I notice a blog thread initiated by a post from MVP Jeffrey Palermo on the merits of SharePoint as a development platform

Jeffrey lists a few facets of what makes a great development platform, most of which I agree with. 

• Easy to install
• Easy to configure
• Integrates well with simple tools
• Easily extended to make simple tools
• Easy to debug
• Easy to create test automation
• All configuration stores easily in source control
• (Others He forgot)

I'm the first to moan and rant about the pain of SharePoint but this is mostly based on ignorance and impatience.  I'm learning fast and am starting to appreciate the benefits of using SharePoint as a development platform.

But back to the original question:  Is SharePoint a Great Development Platform? Using Jeffry's list above lets see.

Easy to install :  There's only a few options in the installer and once you understand what each means and why you would chose each option, then yes, I think it's very easy to install.

Easy to configure : For out of the box operation of WSS or MOSS it's not too bad.  If you want some enterprise features then there is quite a bit of configuration to wade through.  So, maybe yes, maybe no - it depends.

Integrates well with simple tools : Not totally sure what Jeffrey means here but I think he's talking about development tools.  On that basis, you would have to say yes.  Visual Studio 2005 and the SharePoint extensions make it very easy to create and deploy features.  Visual Studio 2008 support is coming for VSeWSS but it does a better job with SharePoint sites already.  There is also a huge number of tools and samples for SharePoint from the community and vendors.

Easily extended to make simple tools : Not sure this really applies to SharePoint. It can certainly be extended - very easily in fact - but for simple tools?  Simple is not a word I associate with SharePoint.

Easy to debug :  Definitely yes - from within Visual Studio.  However, diagnostically it can be tricky so I'd say that's a maybe.

Easy to create test automation : It's no harder than any other server platform.  We have created unit tests for MS CRM - if you can test that you can test anything! 

All configuration stores easily in source control : Source control of web.config is a pain for most web sites, more so with SharePoint. If your doing SharePoint development properly then you may have less configuration that normal web sites.

Other Stuff : SharePoint provides so much base functionality out of the box.  Any pain you experience must be weighed against the benefits and time savings that are delivered by this.

To fail SharePoint for development on the basis that you have to use a server OS ??  Sorry, but this is ridiculous.  I can't imagine any serious developer using XP or Vista as a development OS.  Why? 

• It's not what you are delivering applications to - certainly with SharePoint. 100% of the solutions I have delivered in the last 3 years have been for Windows 2003 Server and one of the server products running on it (SQL 2k, SQL 05, WSS etc).
• You can only easily run 1 web site at a time - yes yes, you can fiddle that but it's a PITA
• You can't run any of the server software you need to code against.

Of course, if you only create single user desktop widgets then you can probably use XP or Vista quite happily.

SharePoint is a large complex beast.  It's not another .Net API or some little platform you can learn in 20 minutes.  It's designed to solve complex human problems and manage data in many different formats.  I can't say for sure if it's a great development platform or not, but I KNOW for a FACT that Microsoft are working very, very hard to make it so.

Thanks to Chris Johnson I now know how to create a feature staple with VSeWSS.

If you don't know what a staple is then Chris has a good description on his blog.  You should read this first for more background but my simple explanation of a feature staple follows.

Feature staples are a way of attaching customisations to existing features and hence site definitions.  This is acheived by creating a feature that associates itself with another feature.  You can also add Feature Receiver code (which is like an event handler for feature activation) that lets you do all sorts of goodness that you can't do with CAML.

Feature stapling is the reccommened way of customising SharePoint.  Site definitions may appear to be a good way to go, but dont.  Andrew Connell explains why .

To create a staple you actually need to create two features:  the feature that you want activated and a feature to do the stapling. 

Update:  I just found a much better description of the process here.

VSeWSS 1.1 does not yet support feature stapling via an item template, but you can still do this via a neat trick that the VSeWSS team provided.  Here's the steps.

1. Create an Empty VSeWSS project:
   
   
   
2. Add a module for the feature you want stapled.  This this case I just used the default module that copies sample.txt.
3. Switch to WSP View and refresh.
4. Open the module feature.xml and change the scope to Site.
5. Open the Module.xml for the new module and change the Url to "MyModule" and add RootWebOnly="FALSE":
   
   
   
6. Deploy the solution and make sure that you get sample.txt in a new folder MyModule.
7. Now for the stapler.  In the solution explorer, create a new folder called Stapler.  Add a new XML filed to this called element.xml.  This will contain the feature associations:
   
   This element.xml contains 3 associations for the new Module.  The Id GUID is from Module1.  Get this value from the WSP View of Module1 feature.xml.  The TemplateName is found in 12\TEMPLATE\1033\XML\WEBTEMP.XML - STS is the name of the templte and #0, #1, #2 is the configuration.  So, this staple associates Module1 with Blank Site, Team Site and Document Workspace.
   
   Make sure the element Id is a new unique GUID.  WSP uses this.
   
   Note: there are issues with the blank site.  I can't find the reference to the explaination of this.. will update when I do.
   
8. Switch to WSP View and refresh.  You should see a new Feature appear for the staple called Untitiled1.  Rename the folders to the name of your stapler thus:
   
   
   You should also change the Title in the feature.xml.
   
9. Edit the feature.xml for the Stapler and set the Scope to Farm:  
    
10. Deploy and pray.
11. Test & checking.  The stapler feature will be deployed to the farm.  Check the Farm Features to make sure it's there. VSeWSS will also deploy the module to the default site so you need to create a new site to test that the staple works. 
12. Create a new Team site.  Use SharePoint designer to see if the MyModule folder is created.
13. Now that you have the stapler working you can create a feature receiver to perform any code based actions.  I haven't done this part yet.  I'll post again when I do.

Normally you will use this method to deploy a master page, aspx page, css etc.  If this is the case then you probably don't need to copy these files to every sub-site, just to the root site.  Set RootWebOnly to TRUE if you want.  Remember that if Module1 is copying files to a library then you need Type=GhostableInLibrary for each file that is copied.

I had a custom field type in my MOSS solution that was a simple CODE type.  This was based on a Text type but all it did was to uppercase any value.

However, when I referenced a list that used this field type from InfoPath the column would not display in InfoPath.

I haven't figured out how to do this yet so I reverted back to a Text field for now.  I'm guessing there is an attribute I need to add the the module.xml or maybe in code? If you have a solution, I'd love to know :)

Not sure what it fixes - but it's gotta help!

http://www.microsoft.com/downloads/details.aspx?familyid=B57C805D-2821-4625-A6F1-80725267F887&displaylang=en

I truly wish you haven't been wasting as much time as I have this week with SharePoint anonymous access and a custom master page.

I have a site that uses a custom membership provider, forms authentication, anonymous access and a custom master page.  My problems were many but in the end the main one was getting anonymous access to the home page.  This would always give me an ugly 401 error.

After a good nights sleep and with a clear head, I finally realised that the problem was not with Pages/default.aspx but with it's masterpage which as not deployed correctly.  I had missed putting type="GhostableInLibrary" into the file node of the module:

It's the little things that can really screw you!

TGIF.

If you are having problems creating a State Machine workflow for SharePoint in VB (and I really dont know why you would want to use VB but... :) then you may see an error about missing files, Workflow1.layout and Workflow1.resx.  If this is the case then you need to copy these files from the C# Project Tempalte zip to the VB version.  Full details are in the following blog post comments- it's a long one so search for workflow1.layout to find it.

http://blogs.msdn.com/sharepoint/archive/2006/06/07/introduction-to-sharepoint-workflow.aspx

To create a forms library definition with VSeWSS 1.1 is very easy.  You can similarly create a list definition based on a content type.  However, you cant automatically create a forms library with an attached content type.

This is how I did it.

1. Create your content type
2. Create a temporary list based on the content type
3. Create a form library list
4. Edit the forms lib schema.xml

1. Copy the content type fields from the temporary list schema to the <Fields> node.
2. Update the <List> node, adding:
   
   

3. BaseType = " 1 "
   Direction = " 0 "
   EnableContentTypes = " TRUE "

4. In <ContentTypes> optionally remove the base Form content type reference if you only want to allow the specific content type:

   <ContentTypeRefID="0x010101"> ... </ContentTypeRef>

5. Add a new <ContentTypeRef> that has the ID that matches the content type you created in step 1.

Here's a small trick that confused me for a while this morning.  VSeWSS creates a setup.bat & .wsp file that will deploy a site definition into a specified server.  Running setup.bat from the command prompt appears to be the obvious way to do that.  You can also override the default web and site urls, e.g:

setup /weburl http://myserver /siteurl http://myserver

The default being localhost (or whatever you developed against).

However, this was failing for me becuase the specified web did not yet have a root site collection and some part of the site definition (web parts) were scoped to the site.

The solution is to create a blank site using stsadm thus:

stsadm -o createsite -url http://myserver  -ownerlogin administrator -owneremail me@myemail.com

Then you can deploy the site defintion using setup.bat. When you browse to the new site you will be prompted with a list of possible site definitions.

Like all things SharePoint this is easy and obvious when you know...

I recently found an excellent series of posts that describe how to customise the UI in Scarepoint.

http://www.cleverworkarounds.com/category/sharepoint/

There's a LOT of other useful stuff in this blog - regular reading I think.

I'm not a very good googler.  Others in the office seem to find the right answer quickly when I can spend an hour searching and not finding what I want. Today I spend 2 hours trying to solve this problem.

When you have a secondary data source that uses a web service, InfoPath lets you specify the input parameters.

You can set the value here to any simple data type.  However, it's not immediately apparent how you would set the value to a variable data item.  In this case I wanted to fetch some data for the currently logged in user.  This data is then used to pre-populate the form.

InfoPath has a username() function.  To use this to specify the value to the web service you need to create a rule for the Form.

1. Select Tools/Form Options.
2. Select Open and Save.
3. Click Rules.
4. Add a new rule.
5. Add an action to set a field value.
6. For the field, select your web service as the data source and the input parameter you want to set.
7. Set the value to a function or some other calculated value.
8. Add more actions if you have more input parameters.
9. Add a final rule to submit the query for the web service.

Ensure that the data connection for the web service has the "Automatically retrieve data when form is opened" option turned off.

The complete instructions for this were located here.

Update :  I Love SharePoint

A lot of people seem to think that Sharepoint and MOSS are wonderful things - a joy to behold!  As of today, I am not one of them.

I've been handed two jobs that require the use of InfoPath forms.  The first is to create a Leave Application form for our intranet.  The other is a bigger project of about 30 forms for a local government site.

As these seemed relatively straightforward things to do I thought it would be a good opportunity to learn and dispel my bad impressions.

So, this is a dynamic post of the issues I have with InfoPath, WSS, MOSS & Forms Services.  As I find solutions or overcome my frustrations I will update (and apologise where necessary).  I'll also include a summary at the end and my current mood.

InfoPath Issues

Contact Selector. 

This is an ActiveX control that is used on InfoPath forms to allow users to select a user from ActiveDirectory.  It requires inclusion of a custom data source (xml file) and creation of fields with very specific names. 

1. To use more than 1 contact selector on the page requires you to create reference fields - which currently confuse the hell out of me.
2. Because you can only have a single Context data source in the form, all contact selectors will work against the same domain.
3. There is no way to filter what the user can select.  I want a contact selector to only allow groups to be selected.  This is not possible.
4. Contact selector does work on browser enabled forms.  It is the only ActiveX control that does this and it appears as though it's hard wired to work.  According to the InfoPath blog there is absolutely no way to create your own ActiveX control that will work in browser forms.
5. Setting a rule on drop down lists will get you 6 level deep in modal dialogs.  This is a very bad UX.

Lookups

I can attach a drop down list to Sharepoint list very easily but I can only set the display and value fields.  The list I'm displaying has 3 values - ID, Team Name and Manager Email.  I store the ID in the form, display the Team Name in the drop down and I need to find the Managers Email from the Workflow when the form is submitted.

Designer

1. Moving tables is impossible.  You can't drag and drop a table and cutting and pasting will trash the contents.

Sharepoint Designer Issues

Getting pretty picky now.

1. When editing a workflow, you can't right-click the Workflow item and select New workflow.  You have to go to the file/new menu option for that.
2. Cannot change the format of emails sent from the workflow.  The emails are pretty ugly really.
3. Workflow Lookups are very confusing. 

WSS Issues

1. All to often you fall off the edge of the Sharepoint world and are required to use command line tools - the horrendous STSAdm.exe mostly.  This has more options than a Linux command shell!  I understand the need for a command line tool but why-oh-why isn't here a GUI version?
2. Publishing an InfoPath form to Sharepoint is pretty easy until you want them browser enabled.  This requires an admin install of the template.  An admin install requires 1) access to the central admin site, 2) an upload of the file from a hard drive (not from a Sharepoint list), 3) activation of the template in a site and 4) configuration of a list to use the new content type created for the form, 5) local machine administrator group membership. This is bloody ridiculous when you consider that publishing a non-browser enabled form works from InfoPath with 3 or 4 clicks of the mouse.
3. The help is complete rubbish.  It's either far to simple or vague or blank.

Workflow Performance

You cannot have more than 10 workflow's active on a single list and submitting 3 forms with workflow concurrently to the same list kills the server. This was proven for another site we did recently.  If I was paying the (huge) bill for MOSS, this would be a show stopper.  Thankfully there is K2 .

Update: I've been informed by someone much more informed than I (thanks Paul) that there is no 10 workflow limit.  In fact there is a WSS property that can be set to specify the event delivery throttle.  I wish we had know about this a lot sooner - it's too late for 1 customer :(.  Full details here:  http://technet2.microsoft.com/Office/en-us/library/93a3282e-00d2-4d03-9721-df42b5aa7cfb1033.mspx?mfr=true

Deployment

I have yet to do this but from what I have seen - don't go there.  Create your forms and content directly into your production environment. 

1. You can't package forms in a STP file.  You have to deploy these separately.  This will probably require hacking the raw XML files of the form.  You also need to generate a .JS script file or MSI using yet another command line tool.

Summary

There are sooo many holes in WSS & MOSS  & related tools that it's a wonder anyone is using it.  When you consider that this is the 3rd version of Sharepoint - albeit a massive re-write - it's woefully inadequate.  It's much more like a v1.0 product.

If you need to create InfoPath forms that require any custom code - DONT!  Just create a windows or web app that talks to Sharepoint lists.

If you have complex workflow requirements or require high performance - use K2 or host workflow's in your own service - DONT use Sharepoint for it.

Current Mood: Tony says I'm Indifferent but I feel reluctant. Not nearly as grumpy about SharePoint as when I wrote this but reticent to withdraw the post completelty.