Alexander Brütt

SharePoint navigation: Quick launch vs. Navigation

In this article I’ll write about some notes on how quick launch configuration differences between publishing and collaboration sites in SharePoint 2010.

If you navigate to the site settings the “Look and Feel” section you will see that there are different options available between collaboration and publishing sites.

Look and feel options of a publishing site (enterprise wiki):

Look and feel options of a collaboration site (team site):

On collaboration sites there is a link named “Quick launch” and on publishing sites there a link named “Navigation”.

The “Quick launch” configuration on collaboration sites is straight forward; you can add headings and links and modify the order.

Many users report to us that they would like to open links in new windows what seems not to be possible in team sites. Well it is, I’ll come back on this at the end of this post.

Now let’s have a look at the navigation option on publishing sites.

First of all, it looks totally different but we have a lot more options here. We can inherit navigation from above and we can configure both the global and the current navigation.

In addition it is possible to open links in a new window:

If the collaboration site is a sub site of a publishing site it inherits the configuration tool from above and offers the same tool like the publishing site. If we want to make the publishing navigation features available in a collaboration site collection, we just have to activate the publishing infrastructure feature on the site collection.

Wiki vs. Documents

Since SharePoint 2010 has been released half a year ago, lots of people start talking about the new cool wiki features it brought with it. Some people seem trying to use the wiki features whereever possible not thinking about the drawbacks. Documents seem to be old-fashioned, they’re not enterprise 2.0… 

Indeed, it is true that the SharePoint 2010 wiki feature are a lot better that the prior version and they combine very well with the also new social features like tagging, rating and the news feed.

In my opinion document are not old fashioned and I don’t think that a wiki always is a good tool to store data in. Maybe I’m one of the last guys who think documents are cool, especially now in SharePoint 2010! So check out my pros for document and wiki features in SharePoint 2010:

Documents can be send (E-Mail or fax) or printed as a whole. A wiki consists of linked pages that cannot be printed or send.

Documents can be read and edited offline/remote. Even nowadays offline people are guilted as homeless people, you cannot do that with a wiki.

Documents are a standardized storage medium. The wiki produces some kind of HTML that would pass no W3 standard verification.

The editor for documents named Word 2010 is the best document editor on this planet at the moment. No web based wiki WYSIWYG content editor can top that, even not the SharePoint 2010 rich content editor.

Documents can switch their file format as desired. A wiki cannot really do that.

Even documents can be edited by multiple persons simultaneous, a wiki is better in this because it consists of lots of pages. I’m not sure how well this works if two people try to edit the same wiki page at once.

A wiki can be combined with tagging and rating very well and a lot better than documents. You can tag or rate documents only as a whole while you can do that with each wiki page.

A wiki can be enriched by rich media like videos. It is possible to place videos within documents but they’re not really made for this.

My last point mentions search. A search is never better that the structure of the crawled information. This is important for both wiki and documents so I have no winner in this point.

Conclusion

I tried to find some strong arguments pro documents and pro wiki to make you think a while when you have to make the choice next time. If you think there are more reasons pro wiki or pro document, please leave me a comment on this.

Things to keep in mind when testing a custom or 3rd party design for SharePoint

Scrolling behavior

Wiki bracket features

Wiki page history feature

Colorings of texts

Silverlight mouse click positions

Visibility of controls

Different site templates

Different browsers

Type not registered as safe error in a sandbox solution

In my case this error occured after renaming the web part class or modifying the namespace.

I found the SafeControl entry in the hidden file SharePointProjectItem.spdata located in the same directory as my web part class:

<SafeControls>
    <SafeControl Name="SafeControlEntry1" 
    Assembly="$SharePoint.Project.AssemblyFullName$" 
    Namespace="MyNamespace.WebPart1" 
    TypeName="*" IsSafe="true" 
    IsSafeAgainstScript="false" />
 </SafeControls>

So if you rename a web part or modify the namespace have a look at the following checklist:

• Check namespace in .cs file
• Check class name in .cs file
• Check namespace and class name in .webpart file
• Check namespace in the hidden .spdata file

Accessing field values in a sandbox solution

In my case I tried to read a field value of type LinkFieldValue. The field type is defined in the assembly Microsoft.SharePoint.Publishing. I read the field value using this line of code:

var fieldValue = item["MyFieldName"] as LinkFieldValue;

This works pretty fine in a console test application or in a farm solution. In a sandbox solution the following error will occur:

Type ‘Microsoft.SharePoint.Publishing.Fields.LinkFieldValue’ in Assembly ‘Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ is not marked as serializable.

It took me some time to solve this:

string value = item.GetFormattedValue("MyFieldName");
LinkFieldValue fieldValue = new LinkFieldValue(value);

It’s not a beautiful piece of code but it works.

MCTS 70-573 Certificate

I finished the MCTS 70-573 certificate: Microsoft SharePoint 2010, Application Development.

http://www.microsoft.com/learning/en/us/exam.aspx?ID=70-573

*cheer*

How SharePoint extensions can block your upgrade path

SharePoint extensions are a risky factor when upgrading a SharePoint farm to a new version, e.g. From SharePoint 2007 to 2010. Every SharePoint extension has a potential to no longer function in the new version.

In my opinion a good upgrade strategy is this:

1. Uninstall all extensions from your existing farm
2. Upgrade the farm to the next version
3. Upgrade each solution and reinstall it

The point here is that some solutions might not be able to be upgraded because the vendor does no longer support it or your last SharePoint developer has left the company as the new SharePoint version was released. If this is the case, your site might no longer work with the new SharePoint version.

If your site breaks in the new SharePoint version depends on the kind of extension you use. A site will continue to work if you cannot upgrade a web part solution. But here are some kinds of solutions that cause content to be not accessible when the solution is not upgradable:

• Custom field definitions
• Custom site definitions
• Custom list definitions

I recommend avoiding these kinds of solutions if possible and using site or web templates instead of definitions and using list templates instead of list definitions.

If you have any opinion on this please feel free to comment on this.

Create/Delete site collection with PowerShell

Today I played some minutes around with Powershell for SharePoint 2010 and easily created a new site collection and also deleted it.

Create new site collection:

New-SPSite  -url http://mymachine/sites/powershell -template STS#0  -OwnerAlias “mydomain\alexander.bruett“  -Name “Powershell Testsite”

Delete site collection:

Remove-SPSite -Identity http://hbv83025270/sites/powershell -Confirm:$False

If I were an IT-Pro, I’d love this

Ribbon Hero rocks

Yesterday I stumbled about Ribbon Hero, a new addon from Microsoft Labs for Office 2007 and 2010. The idea is learning by playing and gaining achievments for using special features within Word, PowerPoint or Excel. The most funny part is the connection to facebook that lets you compare your score with your friends.

http://www.officelabs.com/ribbonhero

It’s not just funny, it’s also useful. The Ribbon Hero shows you very cool functions you haven’t used yet. Check it out, it’s fun. If you work in a company with lots of Office noobs, it’s a great way to educate them.

Good luck becoming a Ribbon hero

If you want to compare your score to mine, invite me on facebook.

SharePoint 2010 and Visual Studio 2010 Beta 2 target Framework problems

Today, I tried to add a reference to the assembly Microsoft.Office.Server.Search.dll and got this warning:

The primary reference "Microsoft.Office.Server.Search, Version=14.0.0.0,
Culture=neutral, PublicKeyToken=71e9bce111e9429c,
processorArchitecture=MSIL" could not be resolved because it has an
indirect dependency on the framework assembly
"System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" which could not be resolved in the
currently targeted framework. ".NETFramework,Version=v3.5". To resolve
this problem, either remove the reference
"Microsoft.Office.Server.Search,Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL" or
retarget your application to a framework version which contains
"System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35

Solution:

Create a .reg file and add this lines:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\
v2.0.50727\AssemblyFoldersEx\Chart Controls]
@="C:\\Program Files (x86)\\Microsoft Chart Controls\\Assemblies"

Run this file and the entry will be added to the registry. Restart Visual Studio and the warning will be gone.