It was the first time that I participated in beta examination so I didn’t really know what to expect when I signed up for the exams. Doing the exams turned out to be a great experience: although you could feel it was a beta examination, it was great to see the results of hard work of the Microsoft Learning team.

I really like the way the exams are balanced now: while the TS exam covers the basics of SharePoint development, the PRO exam takes the content a step further verifying your knowledge about designing and developing SharePoint Solutions. Another great improvement in my opinion is the fact that there is no more separation based on SharePoint SKU. Being a certified developer for SharePoint 2010 means that you can design and develop solutions on the SharePoint 2010 platform no matter the SKU.

As I was participating in the beta run of the exams, I found it a bit challenging to prepare to the exams. Although I’ve been working with SharePoint 2010 for a while now and have some hands-on real life experience with it, there are so far no official preparation materials. There is the exam preparation guideline but you will have to gather all the content yourself. While preparing for the exams I found very useful the SharePoint 2010 Developer Training Course on Channel 9.

Having completed both exams I can definitely recommend them to you. The exams are a great way to verify your knowledge of SharePoint 2010 as development platform and if done well you can learn a lot of new things while preparing for the certification.

Content Types Groups

One of the new features in the next release of CKS:DEV is the grouped view of Site Content Types: just as you see them on the Site Settings > Site Content Types page.

This view not only allows you to browse through the Content Types more easily and consistent with the SharePoint Web UI, but it also has one very important and useful feature.

One of the features provided with CKS:DEV is the ability of importing existing Content Types into your SharePoint project. This feature allows you to create and configure your Content Types using the SharePoint Web UI, and once you’re done import those Content Types into your project. While this feature was a great improvement of the development process, it was still pretty inconvenient, especially if you had not one but ten or twenty Content Types that had to be imported.

With addition of the Content Types Groups in the next release of CKS:DEV you will be able to import all Content Types from the specific group into your SharePoint Project with a single mouse click!

The only downside here is the limitation of the current extensibility API of the Visual Studio 2010 SharePoint Developer Tools. At this moment you cannot either hide or remove any of the existing nodes, so eventually you will end up with both full and grouped view of available Site Content Types.

Site Columns Groups

Just recently we added to CKS:DEV support for importing Fields (Columns) into SharePoint Project. Similar to Content Types, importing Site Columns is a tedious process. The big difference is that when you might have just a few Content Types you will very likely end up with many more Site Columns, so doing all of it manually is just very time consuming.

In the next release of CKS:DEV we will be shipping a new node called Site Columns, which will provide a grouped view of available Site Columns.

Additionally it allows you to import a single Field but also a whole group into your project with a single mouse click!

Other stuff

Site Columns and Content Types are not the only area we’ve been improving for the next release. We’ve done some minor bug fixes and included some improvements suggested by the users of CKS:DEV. You can find more information about our work on the CKS:DEV Issue Tracker page. Also if you have any suggestions for future feature that’s the place to add it to.

Although the exact details about the next release are still to come, all I can say now is that it will be very soon and very exciting and if you are developer you should really stay in touch for the updates. Oh, and if you don’t want to wait on the official release, you can always grab the latest source and build your own version of CKS:DEV!

In case you missed the tweets, we’ve recently added support for importing Site Columns right into your SharePoint Project. To do that simply click with right mouse button on a column in the Server Explorer and click on Import.

The selected column will get imported to the active SharePoint Project in your Solution.

Importing single Fields is just a little step we made towards simplifying working with Site Columns and Content Types. Right now we’re discussing other possibilities of how we could further improve CKS:DEV and make importing SharePoint artifacts even easier and faster. Don’t hesitate to let us know if you have some great ideas: we do listen and we do make it happen.

Although Importing Fields is not quite enough for a whole new release you can get it right now from CodePlex. Simply download the latest version of the source, and build it, and the Import Field option will appear under the Field menu.

Imagine…

Let’s have a look at an image inserted on a page using the standard functionality provided with SharePoint 2010.

Look all right, doesn’t it? If you however look beneath the hood you should notice the problem:

While the picture displayed on the page is 304px x 254px the original picture is loaded: 1693px x 1413px 280KB. Although you can resize a picture using the standard SharePoint functionality, all it does is, it includes the new size as in-line CSS styles. On each request the original picture is requested and resized by the browser. Including multiple of such pictures on your page increases the overall page size and makes the page load slower as more data has to be loaded by the browser.

You could of course resize the image to get this done correctly. You would first upload the original photo, fit it on the page, note the desired dimensions, open the picture in your favorite image editor, resize it, upload it to SharePoint and finally add it on the page. Can you imagine doing this every time you want to insert an image?

The answer is: you shouldn’t. This is where Mavention Smart Images come really useful.

Mavention Smart Images

Mavention Smart Images is a custom Solution that allows you to replace your original picture with a resized one on-the-fly without any manual work. This makes it really convenient to work with images and allows you to optimize your pages so that they can be loaded faster.

After installing the Solution a new Web Application Feature is installed in your Farm. Activating this Feature will enable support for dynamically resized images.

The next step is to activate the User Interface which will allow you to replace the URL of the original image with the URL of the Smart Image. In order to enable it you have to activate the Mavention Smart Images Site Collection Feature:

After you activate the Site Collection Feature you can start working with your images. As an example let’s optimize our flower image from the homepage.

Working with Mavention Smart Images

If you go to the Edit Mode and select an image, you will notice a new option in the Picture Tools on the Ribbon. The Convert to Smart Image button allows you to replace the original URL of your image with a URL that dynamically generates a resized version of your image.

After you click the Convert to Smart Image button, the image’s address changes into a dynamic URL. For example:

/SiteAssets/orange_flower.jpg

becomes:

/image.png?img=/SiteAssets/orange_flower.jpg&w=304px&h=254px&f=jpg

Let’s have a closer look at the generated URL. The img parameter contains a server-relative URL to the image that you want to resize. The w and h parameters specify respectively the width and height of the resized image. This is very cool since you can specify the new dimensions either absolutely (ie. using both width and height) or relatively by providing either the width or the height. Additionally you can even use percentages to resize the image!

The last parameter called f specifies the output format of the image. Supported formats are png, jpg, jpeg and gif. Depending on your scenario you might want to use different format. The best practice is to check which one of the provides the best quality/size ratio for your image.

So let’s have a look at the results of our work:

Notice the dimensions of the loaded image but also the size: 16KB instead of 280KB. See the difference?!

Summary

Mavention Smart Images is a great solution if you work a lot with images on your SharePoint website. In fact it is something that simplifies your daily work as a content manager on your corporate Internet-facing website. Using Mavention Smart Images you can dynamically resize and optimize your images without any manual work: Make SharePoint work for you!

Download: Mavention Smart Images (11KB, WSP) from CodePlex

Two faces of the Reusable Content List

From the Content Management point of view, the Reusable Content List is just an ordinary List located in the Root Web of your Site Collection. You can navigate to it using the View All Site Content option. Nothing special about it here.

If you enable using Reusable Content on your Site Collection, an option will appear in the Rich Text Editor allowing you to insert snippets of Reusable Content into the editor.

Given the benefits Reusable Content gives to the content editors it is a crime not to use it or at least not to educate the users about it.

From the code perspective the Reusable Content List – the List which stores all the snippets of reusable contents resembles a lot a system List – there is no easy way to get it…

The challenges

First of all let me note that both the Title and the Name of the Reusable Content List depend on the locale that you are using. So if you’re developing a Solution for a single locale, you might get away with hard coding the name of the list. If you however work on a real Solution that should support you-never-know-which-language, you have some extra work to do.

As I mentioned before the Reusable Content List resembles a hidden List from the code perspective. There is no public method available to retrieve either the instance, the name or the ID of this List. There are some internal properties but as the name says: it’s not something you can use in your code.

So how can you do it in a reliable or an acceptably-reliable way?

The solution

Probably the only reliable way of retrieving a reference to the Reusable Content List is by retrieving its ID and then getting a reference to this List using this ID.

The ID of the Reusable Content List is stored in the SPWeb.AllProperties property called _ReusableContentListId:

string reusableContentListIdPropertyName = "_ReusableContentListId";
SPWeb rootWeb = SPContext.Current.Site.RootWeb;
if (rootWeb.AllProperties.ContainsKey(reusableContentListIdPropertyName))
{
    Guid reusableContentListId = new Guid(rootWeb.AllProperties[reusableContentListIdPropertyName] as string);
}

Using the retrieved GUID you can now get a reference to the Reusable Content List to add your custom content snippets.

As I mentioned before this is only an acceptably reliable way as the name of the internal property that stored the ID of the Reusable Content List isn’t publicly available in the API and might be changed in the future versions of SharePoint. So if you’re using this functionality in your Solution, it adds an additional point to your checklist before upgrading to the next version.

No matter the answer to the above question, there is a lesson learned for the future: to never hard code the name of the Pages Library and always retrieve it when referring to the Pages Library. And it’s a shame, because it adds both extra complexity and performance penalty to your existing code.

Retrieving the name of the Pages Library in code is not difficult and can be done using the PublishingWeb.PagesListName property. However in order to do that you have to have the instance of the PublishingWeb object first:

SPWeb web = SPContext.Current.Web;
PublishingWeb publishingWeb = PublishingWeb.GetPublishingWeb(web);
string pagesListName = publishingWeb.PagesListName;

Then you can use the value of the pagesListName variable to refer to the Pages Library in code.

Next to the complexity and performance penalty the above approach has one more flaw. Remember which namespaces are supported in Sandbox? Microsoft.SharePoint.Publishing is not among them. Unfortunately, if you want to retrieve the name of the Pages Library from within a Sandbox Solution you have to use a rather quirky approach of retrieving the value of the __PagesListId property stored in the SPWeb.AllProperties Property Bag.

string pagesListIdPropertyName = "__PagesListId";
if (SPContext.Current.Web.AllProperties.ContainsKey(pagesListIdPropertyName))
{
    Guid pagesListId = new Guid(SPContext.Current.Web.AllProperties[pagesListIdPropertyName] as string);
}

And while the above does the job, and it works in the Sandbox and with Anonymous users without elevating the privileges, it somehow doesn’t seem very reliable to me…

Having that all said makes me wonder one thing: how many MOSS 2007 WCM Solutions will break after upgrading to SharePoint Server 2010 because we used Pages instead of PublishingWeb.PagesListName?

If you look at the new Visual Studio 2010 SharePoint Developer Tools, it seems like they have no support for localizing custom Site Definitions at first. If you create a custom Site Definition using the standard toolset, you get a Site Definition that is bound to a specific language by the Deployment Location of the WebTemp*.xml file.

As you might know, localized Site Definitions share all the resources except for the WebTemp*.xml file. The WebTemp*.xml file contains the localized names of the specific Configurations and points to the shared onet.xml file. While the name of the WebTemp*.xml file doesn’t matter that much (as long as it matches the WebTemp*.xml pattern) it is a good practice to append the the identifier of your custom Site Collection to the WebTemp prefix to make it easier to track all Site Definitions installed in the Farm.

If you look at the custom Site Definition that gets created by the Visual Studio 2010 SharePoint Developer Tools you might see one challenge with delivering a multilingual Site Definition. As you can see all files (default.aspx, onet.xml and WebTemp*.xml) are in the same directory. In order to deliver the translated version of your Site Definition in another language you would have to create a copy of the WebTemp*.xml file, but you cannot have two files with the same name in the same directory, can you? So what are the options?

A few approaches that are not quite what you really want…

First of all you could create a new Site Definition project for every translation of your Site Definition. By sharing the common files like pages and onet.xml you could get the job done, but it would make the packaging process unnecessarily complex. First of all you would have a few projects with only a couple of files, and additionally you would end up hacking the identifiers to get it all right.

Another thing that you might try is to choose a different name for every WebTemp*.xml file, for example one that includes the locale like: WebTempMySiteDef1033.xml. This would definitely work and it would allow you to get it all done within a single project. It would be quite quirky though with all the different names and definitely not intuitive for someone not involved with the project during the development stage as it doesn’t follow the good practices. But there is however one more approach worth trying…

Creating multilingual Site Definitions the proper way

One more thing that you could do is to create a directory named after the locale for every language that your Site Definition should support. That would allow you to use the same names for the WebTemp*.xml files and would prevent you from using hacks and dodgy workarounds.

The first step in this approach is to create a regular Site Definition using the Site Definition SharePoint Project Template.

Then you would create a directory named after locale for every locale that your Site Definition must support:

The next step is to move the original WebTemp*.xml file to one of the locale directories and copy it to all the other locale directories translating the contents to match the locale:

The final piece of the puzzle is to change the Deployment Location of each of the WebTemp*.xml files so that they are deployed to the location specified by the locale folder. You can do that using the Properties Window of every WebTemp*.xml file:

And that’s it. Using this simple solution you can develop and package a multilingual Site Definition using the standard capabilities of the Visual Studio 2010 SharePoint Developer Tools and not a single hack!

What is?

Solution Dependencies are a new concept in SharePoint 2010 and are very similar to Feature Dependencies. From the functional point of view they allow you to specify additional resources that are required for your Solution to work properly. Technically there are some differences between Feature and Solution Dependencies.

As you might have known, if you configure the Feature Dependencies in such way, that your Feature depends on another Feature which is hidden, that hidden Feature will be automatically activated if necessary prior to activating your Feature. Visible Features don’t get automatically activated and SharePoint returns an error message saying that another Feature must be activated before you can activate yours. If you specify a Solution Dependency to another Solution which hasn’t been installed/deployed yet, SharePoint will not do anything about it, and all you will get is an error message saying that the particular Solution is missing. This is a great validation mechanism for you to ensure that all resources required by your Solution have been deployed correctly.

Solution Dependencies 101

Specifying Solution Dependencies is very easy. You can specify one or more dependencies using the ActivationDependency Element in the Solution Manifest, for example:

<Solution>
  <ActivationDependencies>
    <ActivationDependency SolutionId="00000000-0000-0000-0000-000000000001"/>
  </ActivationDependencies>
</Solution>

Then during the deployment process SharePoint will check if all Solutions specified in the ActivationDependencies section have been deployed and will return an error message if one or more solutions have not been found:

As you can see the error message takes you a step further but it’s still not very useful providing only the Solution ID. This is quite useless especially if you’re working with third party Solutions and the only way to get the Solution ID is to extract the Manifest.xml from each Solution Package.

That’s why SharePoint allows you to provide additional information for every Solution Dependency. While SolutionId is the only value required you can also include the name of the Solution file, the Title of the Solution and its url (?). Of all this information only the Solution filename is being included in the error message:

At this moment Visual Studio 2010 SharePoint Developer Tools don’t provide any User Interface to specify Solution Dependencies. It can be however easily done by editing the Solution Manifest in the XML Editor.

Summary

Solution Dependencies are a new concept introduced with SharePoint 2010. Solution Dependencies allow you to easily check if all resources required by your Solution are available prior to deploying it. By specifying additional information next to the ID of the required Solution you make it easier to track and install the missing resources.

Provisioning Resource files to your Web Application is very straight forward. All you have to do is to include your Resource file in the Solution using the App_GlobalResourceFile element, for example:

<Solution>
  <ApplicationResourceFiles>
    <App_GlobalResourceFile Location="MyResource.resx"/>
  </ApplicationResourceFiles>
</Solution>

Using the snippet above will copy your resource file to the Web Application’s IIS directory\App_GlobalResources during the deployment process.

Provisioning the Resource files in SharePoint 2010 is even easier if you’re using the new Visual Studio 2010 SharePoint Developer Tools. In such case all you have to do is to add an Empty Element SharePoint Project Item to your project and underneath it add your Resource file. As soon as you do that, the Resource file will allow you set additional property called Deployment Type. In order to deploy the Resource file to App_GlobalResources you have to set the value of the Deployment Type property to AppGlobalResource.

Logging the performance of your custom code to Developer Dashboard is really easy. All you have to do is to wrap a block of your code in a using clause and that’s it:

protected override void CreateChildControls()
{
    using (new SPMonitoredScope("My code block (WebPart1)"))
    {
        Thread.Sleep(50);
    }
}

Will log the following message to the Developer Dashboard:

That’s not all. You can also nest messages to provide some more granular information about your code. All you have to do is to nest the using statements and the Developer Dashboard will do the rest for you:

protected override void CreateChildControls()
{
    using (new SPMonitoredScope("My code block (WebPart1)"))
    {
        using (new SPMonitoredScope("My first block (WebPart1)"))
        {
            Thread.Sleep(10);
        }

        using (new SPMonitoredScope("My second block (WebPart1)"))
        {
            Thread.Sleep(20);
        }

        using (new SPMonitoredScope("My third block (WebPart1)"))
        {
            Thread.Sleep(30);
        }
    }
}

Notice the nested overview in the Developer Dashboard:

One thing to remember about the Developer Dashboard is that you cannot log the performance of your code from Sandbox Solutions. The SPMonitoredScope class responsible for measuring the performance of your code and logging it to the Developer Dashboard doesn’t belong to the types supported in the Sandbox at this moment.