SharePoint Future 2012

SharePoint Future 2012
SharePoint Future 2012

We launched the SharePoint Future brand back in 2009, during the very early days of the SharePoint 2010 beta timeframe.

It was the first event in Italy (and probably the first or the second one in Europe) about SharePoint 2010, just a week after the public disclosure, which took place during the SharePoint Conference in Vegas.

Three years after, the new “15” wave is the new “future”: SharePoint 2013 reached RTM some weeks ago, bringing to the masses a plethora of new and exciting features in most, if not all, of the pillars that constitute the SharePoint platform.

It’s time for a new edition of the SharePoint Future event!

SharePoint Future 2012 will take place in Milan on November 27.

On the event website, you can find all the information you need: content, logistics, registration.

I will be presenting 2 sessions about Search and Web Content Management and about the new Developer stuff, with special emphasis on the new Workflow platform.

And… well, this is just a small prelude of what we’ll be talking about during the SharePoint and Office Conference 2013.

See you in Milan!

 

 

It’s new, it’s green

And it’s finally live: the new Green Team web site!

It’s been rebuilt from scratch, using SharePoint 2010 as the CMS publishing infrastructure.

The web design was created independently from the SharePoint-isms using a Responsive Layout pattern based on plain HTML5/CSS3. Then it was “applied”, i.e. converted into SharePoint master pages and page layouts.

Most of the content targeting is driven by Managed Metadata terms and rollup techniques leveraging CQWP and Search.

There’s some multimedia content also, produced internally by our multimedia gurus Smile… they have almost succeeded in making myself an actor (take a look at the video from the home page).

Hope you like it!

Extending Base Xslt Web Parts with custom control bindings

What a long title! Maybe it requires a little bit of explanation. Here it is.

First of all, by Base XSLT Web Parts I mean a whole family of OOTB SharePoint Web Parts that leverage XSLT transformation to produce markup out of XML data coming from a data source. If you dig into the class hierarchy starting, say, from the XsltListViewWebPart or the ContentByQueryWebPart, you’ll find something like this:

image

If you navigate up the hierarchy, you’ll see that several features are implemented by the base DataFormWebPart class. One of these features is the capability to resolve dynamic parameters, i.e. values that come from query string, postback parameters and a few other sources.

More accurately speaking, the sources for dynamic parameters and the logics of parameters substitution are defined by an internal method of DataFormWebPart, named ResolveParameterBindingsToParameterValues.

Below you can find an excerpt of the method implementation:

image

As you can observe, you can actually set the ParameterBindings web part property to an XML string with proper semantics, thus inject dynamic values as XSLT parameters for the rendering transformation.

You can choose from the following sources:

  • Query String
  • Postback Parameters
  • Form Parameters
  • Web Part Connections
  • Web Part Variables
  • Resources
  • Server Variables
  • CAML Variables
  • Controls

Since XSLT and XPath are a powerful query and transformation engine, you will be able to define conditional blocks and data manipulation expressions based on these dynamic bindings.

But there’s more!

Did you notice the last binding source, the Control source?

The way it works is easy: you have to specify the server ID of an ASP.NET control available on the page and the name of one of its properties. The implementation of DataForWebPart will recursively walk the ASP.NET control tree upwards until it finds a control with the specified ID: then, with a couple of Reflection tricks the value of the specified property will be retrieved and made available to the web part rendering.

You can try this behavior adding, say, a TextBox or a DropDownList control on the page and using the value coming from the Text and SelectedValue properties respectively.

What I like most of this approach (hence the reason of this post’s title) is that you are not limited to OOTB web controls: you can “attach” pretty much any kind of control which exposes a readable property in a plain format (complex data types would be serialized using the ToString method, so the usefulness of these properties really depends on the overridden implementation of the ToString method).

By any kind of control I mean any kind of controls, including any custom control that you may develop in order to extend the XSLT* Web Parts capabilities.

From the extensibility point of view, this means that you (as a developer) can write a suite of simple web controls that are not meant to be used for their output markup, but just as a data source for existing, SharePoint web parts. Then, a colleague who is capable of building no-code solutions using SharePoint Designer will be able to leverage your extensions, using CQWPs or CoreResultsWPs without reinventing the wheel (i.e. building everything from scratch).

Nice, isn’t it?

Below you can find a sample implementation of a web control that exposes the current UI culture, and that may be useful in multilingual scenarios where you want your aggregation web parts (CQWPs, etc…) to behave differently according the the selected language.

But you can easily imagine that this technique can be applied in an infinite number of ways!

   1:  namespace GreenTeam.SharePoint2010.Multilanguage
   2:  {
   3:    public class CultureControl : Control
   4:    {
   5:      [WebBrowsable]
   6:      public Int32 UICultureLCID 
   7:      {
   8:        get
   9:        {
  10:          return Thread.CurrentThread.CurrentUICulture.LCID;
  11:        }      
  12:      }
  13:   
  14:      [WebBrowsable]
  15:      public Int32 CultureLCID
  16:      {
  17:        get
  18:        {
  19:          return Thread.CurrentThread.CurrentCulture.LCID;
  20:        }
  21:      }
  22:   
  23:      protected override void Render(HtmlTextWriter writer)
  24:      {
  25:        // Do not emit markup at all!
  26:      }
  27:    }
  28:  }

How to issue Http Web Requests to a SharePoint 2010 site with FBA and SSL

The .NET Framework provides some handy classes that help you manage HTTP communication through requests and response objects.

Everything is plain and simple, as long as you are connecting to a resource endpoint that does not require authentication and is available through an unsecure channel (i.e. HTTP). Which, of course, is not always the case.

I had a requirement to “invoke” a SharePoint 2010 resource (a file, for example) that is protected by Forms Based Authentication and is exposed by a secured SSL channel. The task is slightly more complicated, since it has to be performed by a client that has no easy way to invoke web services using an autogenerated proxy. That is, no “Add Web Reference” available. Indeed, no RAD environment at all.

You can find my solution in the code snippet below. I have written it with PowerShell just as a prototyping tool, it will have to be translated. But anyway some interesting points can be highlighted:

  • I used the .NET Fx API to “ignore” SSL certificate warnings. This may not be an option sometimes, but the solution can be extended adding some certificate chain verification or whatever you need to check. This is done setting the ServerCertificateValidationCallback static property (line 1).
  • I had to invoke the Authentication.asmx SharePoint Web Service in order to authenticate and, then, reuse the authentication cookie in subsequent requests. This is a requirement for FBA access. I handcrafted the SOAP message since there’s no easy-to-use helper/proxy (line 2-24).
  • I finally issued my HTTP request, using the authentication cookie and adding an HTTP header (line 26-28).
   1: [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

   2: $cookieContainer = new-object System.Net.CookieContainer

   3: $authEnvelope = '<?xml version="1.0" encoding="utf-8"?>

   4:                 <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   5:                   <soap:Body>

   6:                     <Login xmlns="http://schemas.microsoft.com/sharepoint/soap/">

   7:                       <username>yourusername</username>

   8:                       <password>yourpassword</password>

   9:                     </Login>

  10:                   </soap:Body>

  11:                 </soap:Envelope>';

  12: $encoder = [System.Text.Encoding]::UTF8

  13: $authEnvelopeBytes = $encoder.GetBytes($authEnvelope)

  14:  

  15: $authRequest = [System.Net.HttpWebRequest]([System.Net.HttpWebRequest]::Create("https://yoursite/_vti_bin/authentication.asmx"))

  16: $authRequest.CookieContainer = $cookieContainer

  17: $authRequest.Headers.Add("SOAPAction", "http://schemas.microsoft.com/sharepoint/soap/Login");

  18: $authRequest.ContentType = "text/xml; charset=utf-8";

  19: $authRequest.ContentLength = $authEnvelopeBytes.Length

  20: $authRequest.Method = "POST";

  21: $authRequestStream = $authRequest.GetRequestStream()

  22: $authRequestStream.Write($authEnvelopeBytes, 0, $authEnvelope.Length)

  23: $authRequestStream.Flush()

  24: $authRequest.GetResponse()

  25:  

  26: $request = [System.Net.HttpWebRequest]([System.Net.HttpWebRequest]::Create("https://yoursite/yourcontent"))

  27: $request.CookieContainer = $authRequest.CookieContainer

  29: $request.GetResponse()

 

New Slovenian SharePoint User Group

I wish to say “good luck” to the brand new Slovenian SharePoint User Group.

A first meeting will take place today at 5PM: Robi Vončina and Uroš Žunič will present a couple of sessions about “SharePoint Gotchas” and the “Client Object Model” respectively, and maybe some surprise is on the way 🙂

Well done guys, and hopefully we could manage something together with the Italian SharePoint Community (considering the distance… it takes me less to go from Bologna to Ljubljana than to Genoa :-))

More on invalid file and folder names

I’ve been talking about file name limitations for SharePoint 2010 resources a couple of months ago, focusing on illegal characters and path/url length.

There is, indeed, something more which is related to invalid “patterns”.

Just to give you an example, you cannot use folder names that end with:

  • .files
  • _files
  • -Dateien
  • _fichiers
  • _bestanden
  • _file
  • _archivos
  • -filer
  • _tiedostot
  • _pliki
  • _soubory
  • _elemei
  • _ficheiros
  • _arquivos
  • _dosyalar
  • _datoteke
  • _fitxers
  • _failid
  • _fails
  • _bylos
  • _fajlovi
  • _fitxategiak

Take a look at this post by Jeremy Jameson for further information.

The reason for this behavior is the special handling of the so-called “thicket folders”.

What is a thicket folder?

I’m copying here some glossary terms from MS-GLOS:

thicket: A complex HTML document may be stored as a thicket, which consists of the thicket main file along with a hidden thicket folder containing a thicket manifest and a set of thicket supporting files that together store the referenced content of the document (for example, a Web page or Office Word HTML document that includes graphics, pictures, or other media is a thicket).

thicket folder: A hidden folder containing a thicket manifest and a set of thicket supporting files that together store the referenced content of a complex HTML document (for example, a Web page or Microsoft Word HTML document that includes graphics, pictures, or other media). A thicket folder has a name based on the name of the thicket main file, with a suffix added that is recognized as a thicket folder.

thicket main file: The main file of an HTML document that references contained elements such as graphics, pictures, or other media stored as thicket supporting files in a thicket folder.

thicket manifest: An XML file containing a manifest for the set of thicket supporting files that together store the referenced content of a thicket main file, which by convention is named filelist.xml and is contained in a hidden thicket folder.

thicket supporting file: A file containing a graphic element, a picture, or other media that is referenced by a thicket main file and stored in a thicket folder as part of a thicket.

What is somehow surprising is that SharePoint does not prevent you from creating such a folder. I mean, no error whatsoever. It just renames the offending folder with a trailing underscore!

Why? Maybe just to make OOTB migration easier (automatic rename instead of manual renames beforehand).

Anyway… tricky, isn’t it?

Destinazione Office 365

Destinazione Office 365 (which, as you may argue, is the Italian name for Destination Office 365 :-)) is a new technical event organized by Green Team, together with Microsoft, AvePoint and Nintex. The event, which is free BTW, will take place in Microsoft auditoriums in Milan and Rome.

We have defined an initial schedule with two dates.

  • Milan, February 8, 2012
  • Rome, February 14, 2012

Igor Macori, Riccardo Celesti and myself will be talking about Office 365 from the different perspective of End Users, It Professionals, Site Builder and Developers.

You can find detailed information on the event web site, starting from the agenda:

  • 09:30: Welcome (Microsoft)
  • 09:45: Office 365 Overview (Igor)
  • 10:00: Administering Office 365 (Igor)
  • 11:00: Migrating to Office 365 with AvePoint DocAve
  • 11:30: Customizing SharePoint Online (me and Riccardo)
  • 12:30: Automate Office 365 workflows with Nintex Live

And… there’s something more, which I’ll be talking about in a future post.

Stay tuned, and see you there!!

SharePoint Management Shell vs standard PowerShell console

You know that most of the administrative tasks you perform on a SharePoint Farm can be accomplished using PowerShell scripting. You get a bunch of commandlets (more than 600 indeed!) that are registered through the Microsoft.SharePoint.PowerShell snapin, and you can even add your own commandlets using standard SharePoint deployment techiques.

That’s why sometime you just end up firing the default PowerShell console and typing

Add-PSSnapIn Microsoft.SharePoint.PowerShell

Well… you get something that is “similar” to the SharePoint Management Shell Smile

The SharePoint Management Shell is nothing more than a standard PowerShell console (powershell.exe) where tha snapin is automatically loaded upon startup, leveraging a startup script:

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe  -NoExit  ” & ‘ C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 ‘ “

The sharepoint.ps1 script is just a few lines of code:

$ver = $host | select version
if ($ver.Version.Major -gt 1)  {$Host.Runspace.ThreadOptions = “ReuseThread”}
Add-PsSnapin Microsoft.SharePoint.PowerShell
Set-location $home

In the above snippet you can notice the automatic loading of the SharePoint snapin and a “change directory” instruction that brings you to your default home directory (tipically, c:\users\yourusername).

But there’s an additional line:

if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = “ReuseThread”}

This line sets the PSThreadOptions of the PowerShell runspace to ReuseThread, which means that the same thread is used for all command line invocations since the shell has started.

The other options are (see http://msdn.microsoft.com/it-it/library/system.management.automation.runspaces.psthreadoptions(v=vs.85).aspx):

  • Default
    On the local computer,
    UseNewThread is used for runspaces and ReuseThread is used for runspace pools. Server settings are used for remote runspaces and runspace pools. This field is introduced in Windows PowerShell 2.0.
  • ReuseThread
    Creates a new thread for the first invocation and then re-uses that thread in subsequent invocations. This field is introduced in Windows PowerShell 2.0.
  • UseCurrentThread
    Execution occurs on the thread that called the Invoke method. This option is not valid for asynchronous calls. This field is introduced in Windows PowerShell 2.0.
  • UseNewThread
    Creates a new thread for each invocation. This field is introduced in Windows PowerShell 2.0.

If you want a proof of this behavior, just run both a standard powershell console and a SharePoint Management Shell, then run the followind command a few times in each shell.

[Threading.Thread]::CurrentThread.ManagedThreadId

This instruction prints the internal identifier of the managed thread (i.e. the CLR Thread object)

You’ll notice that you get the same value in the SharePoint Management Shell, whereas you get different values in the standard one. By the way, PowerShell ISE uses the ReuseThread option too.

What’s the issue with the default value, i.e. having a new thread spawn (or picked up from a pool) for every command invocation?

Well… first of all there are some SharePoint objects that are not completely thread safe, sou you should pay careful attention when using them from different threads (even if, in this particular case, you have multiple threads that are not executed in parallel Smile)

Another noticeable issue you may experience, though, is resource leakage: if you create SharePoint objects in one thread and suddenly have no reference to that thread any longer, you end up wasting resources that are not disposed correctly.

Wrapping it up… the SharePoint Management Shell is nothing special, but it’s a little bit more than adding a snap in!!

JPGs not showing in browser window

I have to preface that I’m *not* a web designer (should I send you some snapshots of the web pages I have produced, you would definitely agree with me… that’s why I’m not adding pictures to this post :-)).

Therefore the topic of this post may seem obvious to the web designers amongst you.

Anyway, here’s what I have noticed some days ago, in the context of a SharePoint 2010 intranet project where some CQWPs display the most recent items (news, etc..), along with a thumbnail image beside the item body.

Well, the final effect was that some of the images were not displayed at all in the rollup page.

After double-checking the publishing status of each item, I could confirm that each picture item was checked-in and approved, so that it should be visible to all authenticated users.

But while navigating to the assets library that contains the pictures as a site owner, the exact same behavior was visible there: even the XSLT list view web part shows the items, with pictures dispayed as a red cross.

Then, Fiddler comes to the rescue. I fired it up, trying to figure out what was the real network traffic behind the picture download. I got an HTTP 200, and the response mime type was correctly set to image/jpeg.

Ok, then there’s some issue with the image itself. I saved the stream locally, then tried to open the image with any kind of picture viewer tools and… the image displays correctly, no matter of the tool I have used.

This is a confirmation that the image type is not well supported by the browser.

It’s a browser issue, so the next step is to navigate to the image url using different browsers and try to spot the difference… and the difference was now quite evident.

IE8 had issues with that specific image, while neither FF nor Chrome nor IE9 suffered any problem.

Then, I just had to google for “IE8 JPG” to find what I was looking for.

I knew that JPG is too vague, since you can get different encodings and internal representations, ending up with a JPG file extension as well.

But I didn’t know that IE8 dropped support for jpeg images saved as CMYK.

Here you can find some information about this issue, and even a web page where you can test how your browser behaves with CMYK JPEGs:

http://www.computerhope.com/issues/ch001283.htm

Browser are sometimes always strange 🙂

Ahhhh, the Ribbon!

Let me say first that I definitely like the Ribbon, especially from a user interaction perspective. You have to get used to it, but we have to admit that this kind of user experience was not introduced with SharePoint 2010!

We got Office 2007 some years ago. We are seeing Windows tools that have been rebranded this way (Paint? Wordpad?). Components vendors are providing a ribbon framework since 3 or 4 years, which means that a crew of developers are releasing Windows Applications with a ribbon on top (even when it is not suggested by official or common-sense guidelines).

That said – and here my complaints start – the ribbon is quite an obtrusive component. And this is especially true when it is used in web applications, where you have a much more fragile control over the final layout your users will be experiencing. I’m a fan of the ribbon, but I still have to struggle a little bit to convince myself that it’s good as well for html rendering.

Let me expand these considerations with a couple of more practical examples.

Imagine you are realizing a public, internet-facing web site. And you do this with SharePoint, right? J

It will take you a couple of hours to realize that the ribbon should be made available to content editors, but you need it to be hidden to anonymous users (or more generally to site viewers).

A ton of articles and tutorials have been written, and it’s not so complicated as it may seem: you can use some trimming controls (SPSecurityTrimmedControl, LoginView, EditModePanel, AuthoringContainer, something you have developed yourself, etc) and just prevent it from rendering.

Will the ribbon be visible? No. Will it take part to the page markup? It depends.

The reason why it depends is strictly related to the way you are hiding the SPRibbon control.

Are you using some CSS attributes (display:none) applied to some container? Ok, go back immediately and try another approach: the markup fragment is there, and it is useless.

Are you using some server-side visibility logic (as suggested above)? Ok, the ribbon markup is not there any longer. Much better! Well done! But…

Have ever noticed that you are emitting tons of javascript code and did you ever wonder where that script code comes from?

Most of the times, ASP.NET controls generate JS code by with the help of some ClientScript.Register<Something> method. If you want to spend some time in front of a decompiler and start investigating how SharePoint controls behave, you’ll find out that many of them contain a bunch of code like the one I’m showing right below:

If (SPRibbon.GetCurrent(Page) != null)

{

// Write 10 KBs of ugly JS

}

Is this harmful? Hopefully not.

Does this execute if you have hidden the ribbon control? Probably yes.

Indeed, many conditional panels (SPSecurityTrimmedControl, for example) apply their conditional logic very late in the page rendering lifecycle (usually during the PreRender phase). And they are just preventing the ribbon to render, they are not eliminating it from the page control tree!

Which means that any control on the page that checks for the existence of the ribbon will succeed in

this check and perform whatever operation it is supposed to do.

Summing it up:

· The ribbon is hidden

· It does not occupy bytes inside the page body by itself

· It has “side effects”, causing other controls to emit extra markup or, more generally, to behave inconsistently

How can you fix this?

You could use some smarter conditional logics (a SmartPanel, if you like the name) that could just “ignore” its contents if the condition is not met. By “ignore” I mean that this panel should not add its child controls to the control tree at all.

While I would suggest you to carefully consider this approach, I would also like to point-out some drawbacks you may face.

If you remember, I had mentioned two side effects at the beginning of this article. So here’s the other one.

The SPRibbon control automatically sets the MaintainScrollPositionOnPostback property on the page to true. Which means that, after a postback, the user navigation is taken back to the same vertical scroll position he had set before.

Is this good or bad?

Well, it depends, of course.

But you have to take care of this behavior, since the sole presence of the Ribbon control may vary this after-postback setting: if you hide or show the ribbon based on the user rights, you end up having users with different rights having a different navigation experience. And… this does not depend, this is bad by definition J