Changes in SharePoint Client Object Model Redistributable SP1

Summary:

• Enum Microsoft.SharePoint.Client.RecycleBinItemType.Web was added in Silverlight Client Object Model SP1.  No other significant changes noted.
• This means old code using the previous version of the Client Object Model will work fine without recompilation.  Unless you happen to be doing stuff in the RecycleBin
• I wish I had my evening back

Microsoft’s SharePoint Client Object Model Redistributables

Microsoft announced that along with the latest shiny SharePoint 2010 Service Pack 1, they are also releasing an updated SharePoint Client Object Model Redistributable SP1.  These are the libraries for .NET and Silverlight that you can use to talk to SharePoint, without having actually installed SharePoint on your machine and pulling the same DLLs from the /ClientBin/ folder.

http://support.microsoft.com/kb/2508825

Figure: installing the redistributable.  Note the Cancel button is where you expect Next to be :-(

Once installed, they are hiding in

C:\Program Files\Common Files\Microsoft Shared\SharePoint Client

Did anything actually change?  Do I have new secret goodies in the client object model?

Being the Silverlight and SharePoint fan that I am, I set about discovering what were the changes between the first RTM version of the Client Object Model vs. the Service Pack 1 version.

First thoughts were odd, but at least drove me onward:

Figure: RTM DLLs

Figure: SP1 DLLs

The striking thing was essentially, there are no differences in Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll – these are the .NET versions.

But there was a change in Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.Client.Silverlight.Runtime.dll – these are the Silverlight versions.

What’s also interesting was that the changes were done in October last year and guessing from the file size differences it doesn’t look like it was a major change.

Undeterred, I disassembled

Figure: Only minor changes in most of these files.

The only difference that is significant:

Figure: Additional Enum Microsoft.SharePoint.Client.RecycleBinItemType.Web added to Silverlight Client Object Model library

This raises an interesting question – so… this enum doesn’t exist in the .NET version of the DLLs?

10 InfoPath tips for SharePoint developers

Here are 10 nice tips designed for someone that's familiar with SharePoint, but may be new to InfoPath. 

Having brooded over the idea for a while, I decided to quickly write this down, and if there are any questions I can expand some of these key points.

1. Use InfoPath Designer 2010 to author your forms, even for 2007 forms. The UI is better, design checker gives you more information, and the rules editor supports copy/copy all and paste.
   Note: design checker gives you a lot of warnings and sometimes... they can be ignored.  Which ones are safe and which aren't... is as far as I know, a personal experience thing, think of it as VS.NET warnings.
2. Design your main context fields first, and then try your best not to change existing fields (add new fields are OK).  Removing or renaming fields often break existing forms that had already been filled out.
3. Decide upfront whether this is a rich form or a browser form, and set the compatibility level appropriately.  Use the design checker. 
   If you are planning to create hybrid forms that works on both - there's a form option that will allow your code behind to use the Rich Form API but still check the form for Browser Form compatibility.  In this case, always check in your code whether the form is running in the browser before you call those APIs, otherwise you will get UnsupportedExceptions.
4. If you need to promote InfoPath fields to SharePoint so they appear as columns (and can be used in workflows), you should always use site columns.  You might want to consider always using Content Type as well. 
   It may be tempting to use publish to list - but this creates list fields that are now very hard to manage, and when you realize down the road that you should have used content types, you now have to fix existing list columns and move their data to the site columns.  This always happens. 
5. Brush up on your XPath skills well.  InfoPath renders every view via a XSLT transform and the output is actually a HTML page (either for rich form or web forms).  You need to use XPath when you want to start defining rules that are relative to the current field.  Why use rules when you can use code behind?  See next point.
6. Code behind are powerful, and may look much simpler to a developer, but has deployment considerations.  In 2010, code behind can run either in a farm solution, or via the sandbox user code service.  However, code in the sandbox service sometimes may not run when the service is "busy".  Your best bet is either: deploy code through central administration - if you have access, but then you trip up tip #4 if you haven't been using site columns, or don't use code behind and write your logic using only rules.  You can find detailed InfoPath documentation for developers on MSDN (it may not look like much, but you have functions like get-SharePointServerRootUrl that are just gems hiding)
   Plus, trust me you feel awesome when you can write complex logic using declarative XPath and no C# code. It's like saying yes I could cheat and just use C#, or I can be godlike and do it in XPath.
7. Copying pictures increases your resource size.  The best way for a repeated picture is to include it as a resource, then use a picture button and set the image to your included resource.  Unfortunately you can't set the image of a picture control.
8. Export form as Source files, and work with the manifest.xsf.  While I'm pretty certain it is unsupported to tweak the view.xsl files manually by hand, at least you can now put all the component files within a source control and check what has changed using a simple text difference tool.
9. Learn how to call webservice with Rules.  InfoPath is pretty dumb beyond what's within the form.  Webservices gives you lots of capabilities but only if you know how to call them.  E.g. how to interact with SharePoint users.
10. Don't use the "can't be blank" option, always create validation rules.  When any validation rules fail, it puts the form into an invalid state and prevents any submit action.  If you have them all defined as validation rules - you can add an additional condition that allows saving E.g. if ForceSave = "0" and "MyField" is empty
    This gives you control over what happens when the user is trying to save, and allow you to disable the checking when you need to.

Leave a comment if you feel this was helpful, or you want more explanation for any of the points.  Thanks for reading.

REMIX thoughts: where HTML5 and Silverlight fits in with SharePoint

Congratulations to Microsoft Australia for pulling off another really great REMIX event. 

My biggest take-home thoughts came from the combined session “HTML5 and Silverlight: a love story” by Tathom Oddie and Justin Taylor.

This is their message, paraphrased:

You need to know your persona [user group], if you are trying to reach as many people as you can, you need to build for reach, go with HTML5, graceful-degradation to Silverlight, and have a download link for the browsers that can’t do either.

On the other hand, for your special users that are heavily using the system, you may want to give them a basic HTML upload capability, but feature-enrichment with additional premier experience (a rich application on the iPhone), or better upload experience with Silverlight, and even live recording capabilities. For this persona, you can convince them that they can have a much better experience if they download Silverlight.

(Followed by nice singing from Justin).

There’s an awful lot to think about going forward.  I love Silverlight and the possibilities you can do with it, at the same time it is true that to reach your audience you need to come to their level.

So a compromise, I suggest:

For SharePoint 2010:

• For the consumer, where the user wants to see SharePoint content but not really contributing
  • Aim for HTML/HTML5 – this enables most features should someone in your board of directors want to view something in their iPad. 
  • Gracefully degrade to Silverlight, because many people in the organization may not be using IE9, Silverlight at least is easily available on Windows platforms and works with Windows XP and IE6
• For the content creator, where the user may be using a lot of rich applications to interact with SharePoint
  • Start with the basic HTML (not HTML5).
  • Feature-enrich with Silverlight – your users already have the environment, it is easier to develop in, and has a significantly richer API
  • Silverlight 5 with Trusted Mode in Browser will enable browser-Office scenarios allowing browser to interact with Office client applications

InfoPath 2010 - embed HTML for rich and web forms

Do we like the SharePoint content editor web part?  Yes!

What if there's a way to add your own HTML in your InfoPath form, and have it appear for both web forms and rich (InfoPath Filler) forms?

Here are the quick steps:

1. Create an external XML file to store the HTML we need
2. Add the external XML file as a secondary data source for the InfoPath form
3. Use the Rich Text control and bind the result from the secondary data source
4. Using resources in the form (images, CSS)
1. Tricks for InfoPath Filler Rich Form
2. Tricks for InfoPath Browser Form
5. Adding your own CSS
6. Notes
1. Script tag doesn't work (stripped from rich text control).
2. Steps to refresh HTML content of the XML resource

1. Create the XML file

This is documented in MSDN Inserting line breaks into text using Rules 

This is pretty much the same thing - I'm inserting a namespace here so InfoPath knows this is a HTML block of text.

<?xml version="1.0" encoding="utf-8"?>
<html>
  <myhtml>
    <b xmlns="http://www.w3.org/1999/xhtml" >A Bold Hello</b> World
  </myhtml>
</html>

Save it as html.xml

2. Add the XML file as a secondary data source

Figure: Add a secondary XML document

3. Use the Rich Text control and bind the result from the secondary data source

Remember to change the Rich Text Box to Read-Only

Figure: Add a new rich text box, then change it's binding

Figure: Bind it to the secondary data source

Run it in Preview (InfoPath Filler)

Figure: InfoPath Filler - looks good

Publish and run in browser (Browser Form):

Figure: InfoPath Form Server - also looks good

4. Use Image from form resources

Let's go one step further and play with resources such as images.  Add an image into the form's resource files

Figure: Go to resource files

Figure: Add a picture "Save.png"

Modify the HTML to refer to this image. 

<?xml version="1.0" encoding="utf-8"?>
<html>
  <myhtml>
    <b xmlns="http://www.w3.org/1999/xhtml">A Bold Hello</b> World
   <img xmlns="http://www.w3.org/1999/xhtml" src="Save.png" border="1" />
  </myhtml>
</html>

Preview this:

Figure: works great in InfoPath Filler

Publish and view in Form Server:

Figure: Doesn't work so well in Browser Form

Figure: Raw HTML

4.1 Using form resources in Form Server

Let's see how does the Form Server handle images.

Figure: Create a picture button

Figure: Set the Picture to the resource

Publish, then check HTML source in the browser for the new picture:

<img style="width: 100%; height: 50px; position: static;" alt="" src=http://server/_layouts/FormResource.aspx?solutionId=XXX&solutionFile=Save.png hoverSrc=""/>

So the format is:

/_layouts/FormResource.aspx?solutionId=xxx&solutionFile=Save.png

Update this back in our HTML file.

<?xml version="1.0" encoding="utf-8"?>
<html>
  <myhtml>
    <b xmlns="http://www.w3.org/1999/xhtml">A Bold Hello</b> World
    <img xmlns="http://www.w3.org/1999/xhtml" src="Save.png" border="1" />
    <img xmlns="http://www.w3.org/1999/xhtml" src="/_layouts/FormResource.aspx?solutionId=XXX&amp;solutionFile=Save.png" />

  </myhtml>
</html>

IMPORTANT: Remember to escape the & in the query parameter to &amp;

Publish to Form Server again:

Compare the same form published on two different clients:

5. Add your own CSS

Let's try some other tags, this is the STYLE tag:

<?xml version="1.0" encoding="utf-8"?>
<html>
  <myhtml>

    <style xmlns="http://www.w3.org/1999/xhtml" >
       img {
           border: dotted 2px purple !important;
       }
    </style>

    <b xmlns="http://www.w3.org/1999/xhtml">A Bold Hello</b> World
    <img xmlns="http://www.w3.org/1999/xhtml" src="Save.png" />
    <img xmlns="http://www.w3.org/1999/xhtml" src="/_layouts/FormResource.aspx?solutionId=XXX&amp;solutionFile=Save.png" />

  </myhtml>
</html>

Purple dotted borders.  Notice how it is also affecting the Ribbon in the Browser Form.

Use this to your advantage ;-)  

6. Notes

1. Firstly, <SCRIPT> won't work.  The rich text control strips them out.
2. Refreshing the XML file when you update it is a bit of a painful process.  This is just the way it is with secondary data sources in SharePoint.  If you are using offline files, you need to go through the wizard again to overwrite the previous connection (and refresh your offline cache).  But if you are storing that XML file in SharePoint - you can just publish a new version there and tell InfoPath not to cache it.