If you are into styling SharePoint - and who isn't! - then you might find these useful:  Ten Themes for SharePoint is VSeWSS Projects.  I think there is a yellow one in there ... :)

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:

  <Module Name="MasterPages" Url="_catalogs/masterpage" Path="" RootWebOnly="TRUE" >
    <File Path="mine.master" Url="mine.master" Type="GhostableInLibrary" IgnoreIfAlreadyExists="FALSE" />
  </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:

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

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

5. Delete the temporary list definition
6. Deploy and cheer!

 

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...

 

No, not mine, but this one.  http://nickgrattan.wordpress.com.  There is lots of useful material here on many SharePoint topics.

Does anyone have a list of quality SharePoint blogs?  Maybe I'll start one here...

When deploying a solution to a site you can sometimes get errors that are not picked up during compilation.  For example, we created a Content Type that contained a field with an inccorrect BaseType of "Person" rather than "User".  This compiled just fine but fails on the first deploy.  It then failed to compile after deploying.

To fix this is easy enough - remember to update the content type xml as well as the generated schema.xml - but Visual Studio can get it's nickers in a knot and will not be able to deploy the corrected solution.

You need to manually remove the solution using the setup.bat that is created during deployment. Run setup.bat from the bin\debug or bin\release folder thus: 

    setup /u

Then IISReset.

If you try to redeploy with Visual Studio you may now get an error that talks about an "invariant language"  - sorry, I didn't save this error message when it happened.  You will need to restart Visual Studio to clear this error.

I'm in lovely sunny Wellington this week working on some WSS samples using the Visual Studio Extensions for Windows SharePoint Services 1.1 (or more easily pronounced VissyWiss).  One of the samples requires the use of a Module Project Item.  There is surprisingly little documentation - official or otherwise - on what a module does and how to use it - at least, not that we can find.  So, here's my contribution - hopefully correct.

A Module Project Item is used to deploy files to any(?) part of your WSS installation.  You specify the source of the item to copy as a file path relative to the module, and the destination as a url path relative to the site root.  This all sounds very simple, but the problem is that there are 2 urls and 2 paths so there are several permitations possible and not all of them work!

When you add a Module Project Item to your project (Site def, Empty def etc) you will get an XML file called Module.xml in a folder.  Our one looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements Id="b43cb805-eebf-421a-83d3-c2a6cb8afa10" xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="module_training" Url="images">
    <File Url="WORD_icon.jpg" Path="module_training\WORD_icon.jpg" Type="Ghostable" />
  </Module>
</Elements>


Module Url: This is where the files will be copied to.  The url is relative to the site root.
File Path: Path to the file relative to the project in Visual Studio.
File Type: This can only be Ghostable or GhostableInLibrary.  You can only use GhostableInLibrary if the module Url is for a List, such as Shared Documents.

<Module> also has a Path attribute but we dont need it for this operation.

The module will create folders if they dont exist so in the above example we are copying an image to the root images folder, but this could easily be "customimages" and the folder will be created.

There's more to Modules but that is all I have for now.  I'll update when I know how to do Wildcards :)

Microsoft have just release v 1.1 of the Visual Studio Extensions for WSS - VSEWSS.  These work with Visual Studio 2005 and offer a few enhancements of the 1.0 release.  There will be another release mid year that will add support for VS08.

WSS dev is a huge hairy beast and it can be hard to get started - or even figuring out where to start. The best part about new release is the user guide that is provided with VSEWSS.  This is something that some clever chaps at Intergen have been working on.  I provided some very minimal input reviewing their work which is basically providing me with some free training in exchange for fixing a few typos!  The user guide will improve over the next few months as we add more sections so keep checking for updates.

Get it here:

VSeWSS 1.1

http://www.microsoft.com/downloads/details.aspx?FamilyId=3E1DCCCD-1CCA-433A-BB4D-97B96BF7AB63&displaylang=en

 

User Guide

http://www.microsoft.com/downloads/details.aspx?FamilyID=a8a4e775-074d-4451-be39-459921f79787&DisplayLang=en

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.