Welcome to my blog, stay tunned :

ALM Module - Part I - Feature Basics


I have decided to record a new series of videos about ALM (Applciation Lifecycle Management) in SharePoint ouf of real world experience in different enterprises. The topics I'll cover are not particularly new but I intend to bring some added value by giving you some tips and by talking about problems I meet regularly in real world deployments.

Here is the content of this module:

  • Feature Basics
  • Importance of Hidden Features
  • Feature Depencencies
  • Feature Stapling
  • Feature Internal Working and Activation Process during deployments
  • Feature Versioning & Feature Upgrade
  • Farm Solutions vs Sandboxed Solutions vs Apps
  • Farm Solutions deployment tips and automation
  • Farm Solutions Code Review
  • Farm Solutions versioning
  • Sandboxed Solutions
  • Code migration and refactoring pitfalls
  • App Model Introduction
  • SharePoint-Hosted Apps deep dive and ALM considerations

Topics covered in this video:

  • Introduction of the ALM module
  • Purpose of features
  • Feature Scopes
  • Feature Receivers and deployment tips

You can access the desktop version of the ALM module here. On the mobile version, just tap the WebCasts button

Happy Coding

Silver-IT goes mobile


My blog is currently built in Drupal, a choice I made a few years ago because I had absolutely no time to do anything else and I wanted to have a blog up & running in a matter of a few hours with full flexibility and extension capabilities with a perssonal hosting as well, that's the reason why I didn't take any of the blog providers.

That said, I wouldn't say that it was the happiest choice in my life and now I'm too lazy to make a migration (content wise) to something else! As more and more devices visiting the Internet are mobile ones, I have decided to create a mobile version of this blog. If you're using a mobile device, you might already be viewing the mobile version. By the way, if you use an iPhone, don't hesitate to add a shortcut to your home screen to benefit from a full screen view.

I've added a webcast viewer in the mobile view. For now, I have only one webcast but I plan to record some modules soon. I'll start with an ALM module containing a few videos. It's not a new topic nor is it specific to 2013 but I realize in my day to day activities that it's still hard to do good ALM in SharePoint and to handle deployments properly, especially in large shared environments. I'm collaborating a lot with the infrastrcuture teams and understand their concerns when it comes to Farm Management.

That's why I've decided to share my experience around those topics, starting from the very basics to the most complex.

Hopefully you'll enjoy it.

Migrating InfoPath Forms Services applications from 2010 to 2013 - Gotchas


I've recently been involved in migrating a series of InfoPath Forms using SharePoint Forms Services from 2010 to 2013.
I've suffered a lot to make a successfull migration and this was mainly due to security and Claims-Based authentication. Here are the problems I noticed and their possible solutions.

Classic mode to Claims => Forms Services web services failures

One of the biggest change when migrating SharePoint 2010 to 2013 is the authentication mode. As you might know, 2013 is based on Claims-Authentication by default while 2010 is based on Windows Authentication, the so-called classic mode.
While classic-mode is still possible in 2013, this is not a recommended approach anymore. Microsoft even recommends migrating the 2010 to Claims before performing the actual migration to 2013. Also, you have to migrate the stored user credentials to Claims as well using PowerShell (easy to do).
Which impact does Claims have on Forms? Well, the impacts are quite huge. The forms that are using SharePoint web services and/or FRPC calls will not work anymore.
So, if you have a form calling listdata.svc or OSSSVR.dll, they will not work anymore. The reason is easy : when Claims-Authentication is enabled, Forms Services is not able to retrieve the user credentials (SAML token) and reverts to IUSR (anonymous) to perform the web services calls.
This ends-up in a 403 (Access Denied)....because SharePoint is expecting authentication, at least for non anonymous web apps. This was actually already the case in 2010 but since most of the 2010 farms are still based on classic mode, you don't even notice that "problem".
Something you'll notice when you create a SharePoint webapp in Claims mode from the Central Administration is that the corresponding IIS webapplication will have anonymous access enabled+Forms authentication enabled as well. This is in this exact scenario that Forms Services stops working with extra web services calls.
However, if you create a webapp in Classic Mode, anonymous access isn't enabled at IIS level. If you switch that webapp to Claims afterwards via PowerShell, it's not changing IIS anonymous settings and Forms Services keeps working fine with web service calls even in Claims...However, I wouldn't recommend that approach since it might have some side-effetcts and you'd better chose the right authentication mode at creation time.
So, what's the solution?
It seems that the only possible solution to avoid anonymous requests is to use the Secure Store Service, map users and/or groups to some Windows Credentials and then reference the Secure Store Service SSO in your UDCX connection file. That way, Forms Services will use the SSO to connect to the web service. However, this is only usable in situations where you can afford to use a technical account to consume your web service. This is not a passthrough authentication but rather a kind of revert-to-self auth.
If you're calling custom web services (not SharePoint ones), it is also possible to allow anonymous calls...depending on your security requirements.
Don't trust the preview mode
While this was also valid in 2010, don't trust the preview mode of InfoPath if you plan to use Forms Services. Indeed, with the preview mode, the web service connections will work just fine as opposed to Forms Services. This is because when you make a preview, this is the rich client that performs the requests, not Forms Services.

InfoPath Designer 2013

While at last InfoPath Designer 2013 isn't based on VSTA 2005 anymore (it was really time!), the bad news is that the 2010 projects fail to convert properly. This failure results in InfoPath Designer not being able to load the custom code...it throws an error such as "the specified path cannot be found...". Even remapping your form to the project doesn't help...The only solution is to remove the code and recreate the project from scratch at the time of writing.
I hope that Microsoft will fix that since it's really a pain in the a..
Of course, any other component that would be manipulating users login names needs to be claims-aware as well. Except that, I didn't notice other troubles with Forms Services but as you can see, you'd better take this into account when planning your migration.

Happy Coding!

Rating System for SharePoint Foundation 2013


I've been asked a few times whether I'd migrate my rating system (MOSS 2007, SharePoint Foundation 2010) to SharePoint Foundation 2013. At first, I wasn't too enthusiastic as I'm doing that during my free time and I had many other things to do.
But it turned out that I've just finished my book on 2013 so I've had a little bit more time to handle that migration. So I did it!
I made a "as is" migration. It means that I didn't add any new feature nor did I make something specific for 2013. It's just working as before.
I had to perform some adjustements regarding the Site Definition & regarding the list view rendering since now, list views are based on Display Templates (JSLink) but that's it. So, installing this new WSP (Farm Solution) onto Foundation 2013 before (or after) having upgraded your 2010 databases should make it just fine!
However, rating discussion boards is now only partially supported, that's the only small difference. This is due to the change in rendering list views and the discussion board is a very specific one.
You can download this 2013 version on CodePlex http://sptoolbasket2013.codeplex.com/

Happy Coding!

Content Type Explorer App


I've just released a new SharePoint-Hosted App on CodePlex https://sptoolbasket2013.codeplex.com/releases/view/91909.
Sometimes we need to delete content types but we don't always know where they are used. Because you cannot delete a content type that is still in use, this App helps finding which lists and/or child content types make use of a given content type.

Here are some screenshots:

The App is localized in French & English and will be available soon on the SharePoint Store.

Happy Coding!

Search Engine not working fine in your App?


I know that might sound stupid and it really is but I spent recently a few hours trying to figure out why the Search Engine wasn't working fine when queried from my App.
It turned-out that I forgot to ask the permission to use it. So, I was missing this line in my AppManifest.xml:

While this is very stupid, this little distraction made me realize that the system isn't behaving as expected. Indeed, one could expect that the App Model throws an exception such as "Attempt to perform an unauthorized operation" but it doesn't. It's actually even querying the Search Engine successfully but simply, no results are returned.
It is behaving as if it was applying some kind of security trimming but it's not because the App had full control over the site collection...Morality, just don't forget this line and you should avoid some headaches :).

Happy Coding!

Demo SharePoint-Hosted App showing how to use the REST API (CRUD, micro-blogging, following content, people, search)


Update : I've published this App to the online SharePoint Store which facilitate its installation. The App is available here http://office.microsoft.com/en-us/store/rest-api-demo-WA104068939.aspx?q.... However, since the SharePoint Store doesn't permit Tenant Full Control permissions, the App capabilities are a little bit reduced compared to the one published on CodePlex

Creating a micro blog with new hashtags with the REST API


Update 04/2013 download my demo App at http://sptoolbasket2013.codeplex.com/

Similarly to my previous post, here is how to create a new hashtag inside of a microblog using the REST API from a SharePoint-Hosted App. Basically, you also have to address the ContentItems

Creating a micro blog with mentions with the REST API


Update 04/2013 download my demo App at http://sptoolbasket2013.codeplex.com/

As I've struggled a lot to get this working and since I coudln't find the information anywhere, I've decided to create this blog post that shows how you can create a microblog entry in SharePoint 2013 for the connected user (from a SharePoint-Hosted App) using mentions.

On MSDN, you can find a sample showing how to create a microblog here : http://msdn.microsoft.com/en-us/library/jj822974.aspx. While this is already a good start, there is no mention about posting more complex microblogs and for instance, embedding mentions to other people. If you try just to add @user in the text body, you won't end up with a valid solution :).

So, after a bit of digging, I eventually found out how this works. In the below example, I'm targetting users demo and eni by saying hello to both of them. This is the result when posted:

and here is the JSON data you have to send via a POST query to /_api/social.feed/my/Feed/Post to do that:

    'restCreationData': {
        '__metadata': {
            'type': 'SP.Social.SocialRestPostCreationData'
        'ID': null,
        'creationData': {

            '__metadata': {
                'type': 'SP.Social.SocialPostCreationData'
            'Attachment': null,
            'ContentItems': {
                'results': [
                        '__metadata': {
                            'type': 'SP.Social.SocialDataItem'
                        'AccountName': 'dc07\\demo',
                        'ItemType': 0,                                        
                        'Uri': null
                        '__metadata': {
                            'type': 'SP.Social.SocialDataItem'
                        'AccountName': 'dc07\\eni',
                        'ItemType': 0,
                        'Uri': null
            'ContentText': 'Hello @{0} and hello @{1}',
            'UpdateStatusText': false

The magic happens with the ContentItems collection where you have to provide the information about each targetted account which you reference after in the ContentText property by their respective index.

Happy Coding!

Double quotes & single quotes when using the Search REST API of SharePoint 2013 combined with KQL from JavaScript


Update 04/2013 download my demo App at http://sptoolbasket2013.codeplex.com/
I've been facing a quite strange issue when using the new search REST API of SharePoint 2013 and you might be facing the same kind of issue so as it took me a while to figure out the problem, I thought it was a good idea to share both the problem and the fix.
Double quotes
First, the problem! When trying to pass double-quotes into the querytext parameter. If you do not use the KQL syntax, you don't have any problem. So, if I transmit this:


it's working fine.
If you're using the KQL to say for instance that you want to retrieve only items whose title equals "test". You can do it this way:


Usually, you'll make sure to encode the full querytext parameter. However, with the KQL syntax, you can use parenthesis and if you repeat the same query than before with parenthesis:

=> encoded value is :/_api/search/query?querytext='%28Title%3D%22item%201%22%29'

it will also work fine. Usually you'll use parenthesis if you want to apply priorities among multiple search criteria, however this is not a must since the above query works also fine but...strangely enough, if you add a double quote in the value, despites of the fact that this is encoded:

/_api/search/query?querytext='(Title="test " double quote")' 
=> encoded value is :::/_api/search/query?querytext='%28Title%3D%22test%20%22%20double%20quote%22%29'

You see that the value test " was encoded to test%20%22 so the double quote is escaped, at least from a web point of view, you will still receive the following error from the service:

Status:500Error:{"error":{"code":"-1, Microsoft.Office.Server.Search.REST.SearchServiceException","message":{"lang":"en-US","value":"We didn't understand your search terms. Make sure they're using proper syntax."}}}

and the reason of that are the parenthesis...If you get rid of them, you won't have that message anymore. So, make sure to use the parenthesis only if you need them...even with multiple search criteria. So, I don't know exactly why the parenthesis have this effect but for sure, they seem to have a weird impact.
Actually, the double quote character is meaningfull for the KQL engine so I think that encoding doesn't change anything and the character is still interpretated somehow by the KQL engine. I tried many different ways of escaping it with %22, \", \x22 in Javascript...and none of them is working.
If I have an item that has this value with " quotes and I try to search using the encoded form, I'll have no error without parenthesis but it won't return any result no matter how I'm encoding the ", I'll have the error described earlier with the parenthesis and it will just work fine with the right results if I replace " by nothing.
Single Quote
Here it's even worste, whatever you're trying to do, the server will crash with an error whether you're working with KQL or even with a basic search term...and the reason of this is because the ' character is enclosing the value of the querytext parameter and that's most probably why it goes mad. So, again, if I just remove the ' character from the search value, it's finding results correctly even when you make an exact match. So if you search for Title="test single quote", items whose the title is test ' single quote are returned...
So, not sure that removing both ' and " from the search terms is the right workaround but it seems to work and you'll probably avoid some headaches.
Note that these problems are only encountered when working with GET and _api/search/query, you won't run into them when using _api/search/postquery because there, you can just use JSON.stringify of the entire request and pass it as the data parameter and that will work like a charm.

Happy Coding!