I've just recorded a new video that was published on Channel9, if you're interested to watch it, it's here:
I usually don't relay other blog posts since there is rarely added value but this time I'll make an exception. I've been recently invited to test cloudshare, a company offering cloud solutions and as Liam Cleary mentioned in his blog post :
I'm also very enthusiastic about their solution. I should add that this is:
- Easy to use and very intuitive
- Looks stable & reliable as far as I could test
It took me a while before I could find time to record these few mute videos demonstrating how you can use and install the rating system for SharePoint Foundation available on CodePlex at http://sptoolbasket2010.codeplex.com/
|Videos in WMV format|
|Install the solution||1.9 MB||42 sec|
|Activate the site collection feature||1.7 MB||30 sec.|
|Using rating functionality with list & libraries||8.3 MB||2 min 42 sec.|
|Using rating functionality with discussion boards||3.6 MB||110 sec.|
|Using rating functionality with pages||3.9 MB||2 min 30 sec.|
|Creating a rating team site & site collection||3.7 MB||1 min 42 sec.|
|Using rating functionality within a blog||4 MB||2 min sec.|
|Viewing rating reports||3.4 MB||1 min 10 sec.|
|Working with comment approval||8.2 MB||4 min.|
|Handling the anonymous||3.2 MB||1 min 35 sec.|
I'll be in Paris on February 8 and 9 for the Microsoft Techdays as an ATE (Ask The Expert). Don't hesitate to come to the SharePoint stand, it will be a good opportunity to meet.
I've just released a small tool on CodePlex that helps managing ribbon buttons for lists & libraries in SharePoint. You also have additional options to decide whether you want to apply your settings to xsltlistview webparts only or not.
If like me you experienced the above error, don't lose time wondering what the hell is going on. When you use FBA, once the FBA authentication gets completed, a SPCLaim token is issued and that's why, the following line of code (usual in 2007):
would throw the following invalid cast error:
Unable to cast object of type Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider to ...
You could of course workaround this exception by using this syntax:
but you would end up with a NULL value in return.
So, the solution is just to target your FBA provider like this:
and it's likely to work better :).
When querying ListData.svc directly from AJAX, if your SharePoint web application is configured using Windows Authentication with either NTLM or Kerberos, your browser will either transmit your credentials automatically (Internet Explorer), either will prompt you to let you logging in (other than IE).
This behavior is not similar when trying to perform AJAX queries in FBA mode, so when your SharePoint web app is set up to use FBA combined to CBA.
In that case, the following piece of code:
would branch to the error part in case you're not yet authenticated. To handle that, you can redirect the user to the regular SharePoint login page so that he gets this:
To handle that, you can use a piece of code looking like this one:
where you test the returned status which is 302 with Firefox & 12150 with IE 8 for some reason...In case this error is returned, you just redirect the user by building the new URL dynamically. SharePoint will do the remainder and the user will be redirected back to the current page after authentication gets complete.
SharePoint COM, client side error handling and impact on the performance + tips to handle returned error codes
As stated in the title, in this blog post, we're going to see the difference between handling errors client side and server sides when using the SharePoint Client Object Model.
An introduction to this is available on MSDN at http://msdn.microsoft.com/en-us/library/ee534976.aspx and a more detailed documentation is available at http://ranaictiu-technicalblog.blogspot.com/2010/08/sharepoint-2010-exce....
However, none of these describes how to deal with returned errors, nor whether it's more performant or not to use the client side error handling using ExceptionHandlingScope.
So, the main advantage of this client side error handling is that you can from the client decide how the server should react in case an error occurs without calling ExecuteQuery() or ExecuteQueryAsync() multiple times. This avoid unnecessary roundtrips between the client and the server.
However, while this is true, client side error handling doesn't work the same way than server-side error handling. In server-side error handling, we trap the exception details directly in the catch block so that this:
is totally possible. As soon as you are in the catch block, you can start working on the returned error (displaying it, log it, check what kind of error, stack trace etc...)
while in Client Side Error handling, this:
won't throw an error but won't work either. Because, the ServerErrorCode will always be -1. The reason for that is because at that stage, no communication has been done with the server so, that's why you get an empty error code even when an error occurs.
It means that you can't undertake a specific action according to a specific error. In the example shown on MSDN, the only possible error you could have is that the list doesn't exist. So, you know that if you get in the catch block, it's 99,99% due to the fact that the list doesn't exit.
However, when you don't know in advance the type of error you might encounter, this can be kind of a problem and I have no solution for that. But, what I noticed is that you can read the right error code after ExecuteQuery() or ExecuteQueryAsync() was called:
At that stage, the error code is correctly returned. It's a bit shocking to use the scope object outside the using block...but that's the only way to get it working (at least according to what I found).
The other way is not to use using blocks.
Okay, so now that we've seen how to get the error code back if any, what about multiple operations to perform at once? Say you want to delete 100 items of a list no matter whether there are errors or not. It's a kind of "on error continue" mode. How to deal with that?
With the below code:
As soon as an error is met, the server will stop the treatement although the try/catch logic is applied for each operation. It seems that one error only is permitted per scope...:). Here I say that I want to delete the 3 first items of a list. If I put a breakpoint before starting the delete operations, then if I go delete the two first items manually from the SharePoint UI, then I hit F5 to go ahead, my last item won't be deleted, meaning that the server stopped as of the first error encountered.
Moreover, I have only the code returned for this first error of course. So, how to say "I want to delete all the items I can and treat the errors afterwards?". Here is a technique that seems to work:
What is it all about?
- Start initializing a dictionnary that will store all the item ids & scope objects
- foreach delete operation, instanciate a new scope object
- after the loop completes, read your dictionnary and get all the items ids for which the server encountered a problem via a LINQ query.
In my case, I had a list with 3 items, I put a breakpoint before the delete operations, then I removed the two first items but left the third one in the list. Then I just let the program go ahead and here was the ouptut of the program:
So I got indeed the right errors for the right IDS plus my third item was correctly deleted from the list as I expected. Bear in mind that all of this occured with one call to the server only.
What are the drawbacks of this technique:
1) You instanciate a scope object for each operation...so that's of course resource consuming on the client
2) With the client OM, you have to limit your batch size to more or less 300 items, otherwise you get an error from the server telling you that your query was too big.
What's the alternative?
Actually, you can just do this:
Which will produce the same results, meaning that you get the right errors & all the other items are deleted but the major difference is that you contact the server for every item because of the call to ExecuteQuery().
So, what's best? 1 option consumes memory & resources, the 2nd one generates a lof of roundtrips to the server.
Here are a few tests I performed using both techniques.
To delete hundred items, I got these results:
No Client Error Handling == Call to executequery for every item
ClientError Handling == one scope object per operation
What do we see?
On 5 attemps, with the client error handling (1 scope object per operation), each attempt is at least 1 sec faster than with the other approach.
If we do the same with 200 items:
the time difference increases as there are almost 2 secs of difference for each attempt.
Note that the figures obtained with those tests are not representative of a prodution system since I ran them on a development machine with poor resources. But what's important to remember is the time difference between both techniques, not the figures themselves.
I don't know if you have already noticed that problem but when adding a XSL listview webpart on a page, if you have custom ribbon buttons associated to either a content type, either a list id, those buttons do not show up.
As a concrete example, if I take my rating system, I've got a custom action defined like this:
This shows the following button in the ribbon for all document libraries:
And it works fine when I click on the list itself from the quick launch. However, if I add this list as a webpart on the page, my button disappears.
The reason for that is that you need to specify the right toolbar in the webpart properties. It defaults to "Summary Toolbar" but if you change it to full toolbar or Show Toolbar:
Then the button is back again in the ribbon...
I don't know whether it's a bug or by design but I observed that changing the toolbar makes it working as expected.