Visual Studio 2010 mit SharePoint Support

Heute hat uns Jason Zander (General Manager für Visual Studio) hier an der TechEd EMEA in Barcelona in seiner Keynote einige Funktionen von Visual Studio 2010 gezeigt. Sehr spannend finde ich die neuen Funktionen für das Software Testing. Für SharePoint Entwickler sind folgende News viel interessanter:

Mit VS 2010 soll das Entwickeln von SharePoint Anwendungen vergleichbar einfach werden wie das Arbeiten an Client Applikationen oder ASP.NET Web Anwendungen. Die Highlights:

• In einem Server Explorer sind Sites, Lists und weitere SharePoint Items direkt im Visual Studio sichtbar. Ähnlich wie wir es vom SQL Server Explorer kennen.
• Neue Templates für das Erstellen von WSP, Web Parts, Listen Templates, etc. Neue Solution können z.B. durch den Import eines bestehenden WSP erstellt werden.
• Das Web Part Template erstellt automatisch ein UserControl (ASCX), eine .CS Datei, welches dieses ASCX lädt sowie eine Webpart Definition Datei.
• Event Handlers können mit einem Wizard erstellt werden.
• ASP.NET Forms für Workflows können mit einem WYSIWYG Editor bearbeitet werden. Dabei wird die Master Page vom SharePoint geladen.
• Weiter erwähnt aber nicht konkret gezeigt oder vertieft wurde Linq to SharePoint und die Möglichkeit, den Code lokal auf der Workstation auszuführen.

Da können wir uns ja auf etwas freuen!

SharePoint Custom Site Definition Battle

Joel Oleson hat in seinem Blog einen Krieg losgetreten: den SharePoint Custom Site Definition Battle. Die Reaktionen hat er u.a. hier zusammengefasst. Er sieht berechtigte Risiken in der Upgradefähigkeit von Site Definitions und wollte deren Verwendung unter Bann stellen. Die Reaktionen waren heftig. Doch hat sich ein konstruktiver Dialog ergeben, welcher ich hier kurz wiedergeben möchte.

Alternativen

Auf die Alternativen zu Site Definitions möchte ich nur kurz eingehen, da es im SharePoint kein anderes Konstrukt gibt, mit einem Klick eine Site ab einer bestimmten Vorlage zu erstellen.

So decken z.B. Site Templates (STP Dateien) nur ca. 80% der Funktionen ab. Die restlichen 20% müssten entweder geklickt oder programmiert werden. Weder das eine noch das andere lässt aber das Herz des SharePoint Architekten höher schlagen. Wenn ab

Funktionalität

Zu SharePoint 2003/WSS v2-Zeiten standen uns bis auf Site Definitions keine anderen Möglichkeiten zur Verfügung Vorlagen für Listen, Sites, etc. abzulegen. Mit SharePoint 200//WSS v3 basieren die Site Defintions auf Features, welche das Gros der Customizations beinhalten.

Wenn Customizations (Listen Vorlagen, Listen, Content Types, etc.) in Features ausgelagert und diese an eine Custom Site Defintion gestampelt werden, spricht nichts gegen Custom Site Definitions. Falsch wäre es aber heute Site Definition auf die "alte Art" zu erstellen und alles ins ONET.XML zu packen.

Um die eigenen Features aber mit einer Site Definitions zu verbinden (Stampling), kommen wir nicht darum herum eigene Site Definitions zu erstellen.

Upgradefähigkeit

Wurde eine Site ab einer Site Definition erstellt, bleibt sie auf immer mit dieser verbunden. Da gibt es keinen Weg heraus. Niemand weiss, wie das Upgrade von SharePoint 2007 auf SharePoint v.Next in Bezug auf die Site Definitions aussehen wird. Man munkelt, dass SharePoint v.Next keine Site Definitions mehr unterstützen wird. Trotzdem wird uns Microsoft einen Weg zur Verfügung stellen, wenigstens jene Sites zu migrieren, welche ab OOB Site Definitions erstellt wurden.

Sind die eigenen Site Definitions nun bis auf die ID identisch mit den OOB Site Definitions, sollte ein Upgrade uns nicht vor grosse Probleme stellen. Dadurch, dass wir aber eine eigene ID haben, können wir unsere Features mit unserer Site Definitions verbinden.

Quintessenz

1. Erstelle eine Custom Site Definitions, wenn es notwendig ist. Auch wenn es nur darum geht, eine Site Definition mit einer eigene ID in der Hand zu halten, auf welche die Features gestapelt werden.
2. Wenn du eine Custom Site Definition erstellst, beschränk dich auf das Minimum und bleib nahe bei den OOB Site Definitions. Alles was mittels Features gelöst werden kann, soll mittels Feautres gelöst werden.

Euer Kommentar ist herzlich willkommen. David Schneider

Azure übernimmt die Weltherrschaft

Heute hat Ray Ozzie an der Keynode der PDC das neuste Pferd im Microsoft Stall vorgestellt: Die Azure Services Platform bzw. das darauf basierende Produkt Windows Azure. Beim früher als Red Dog bekannten Projekt handelt es sich um die Cloud-basierte Service Platform, welche von Microsoft betrieben wird und neben dem "Betriebssystem" Diente für Management, Datenspeicherung, Authentication, etc. zur Verfügung stellt.  Der Vorteil von Azure liegt im Cloud Computing: hohe Verfügbarkeit, Skalierbarkeit und Flexibilität vereinfachen den Betrieb und das Deployment massiv.

Man muss sich nicht mehr um Server, Speicher, Backup oder Performance Sorgen machen. Man stellt die Applikation in die Wolke und kann sofort loslegen. Ob nun ein Benutzer oder die halbe Welt auf die Applikation zugreift, merkt man erst, wenn die Rechnung Ende Monat ins Haus geflattert kommt.

Spannend wird die Geschichte, wenn wir uns die Komponenten von Azure anschauen:

Windows Azure ist das "Internet Betriebssystem" und erlaubt das Ausführen von beliebigen Code. In der aktuellen Phase handelt es sich dabei um .NET Code, welcher mit entsprechenden Visual Studio Templates / Tools erstellt wird.

Die Live Services standen bereits davor zur Verfügung und bieten die Möglichkeit zum Speichern und Austauschen von z.B. Photos, Videos und Silverlight Applikationen.

Bei den .NET Services handelt es sich um eine Cloud-basierte Implementation von einigen .NET Framework Komponenten wie z.B. Workflow und Access Control.

Die SQL Services übernehmen die Speicherung von strukturierten und unstrukturierten Daten. Abfragen und die Suche erfolgen über Web Services (REST). Ebenfalls wird das Reporting integriert.

Mittels SharePoint und Dynamics CRM Services lassen sich Business und Collaboration Daten speichern und abrufen. Ebenfalls können hierfür eigene Erweiterungen codiert werden.

Alles sehr spannend. Gerade die SharePoint Services! Ich denke, dieses Announcement ist wegweisend und zeigt in die richtige Richtung! Schauen wir einmal, ob es an den TechEd mehr Informationen über Azure gibt. In der Zwischenzeit kann man bereits das SDK herunterladen und sich auf die CTP Waiting List eintragen können.

SharePoint v.Next

Um die nächste Version von SharePoint (SharePoint V14 / SharePoint 2009) ranken sich viele Gerüchte. Eine schöne Zusammenstellung habe ich bei Edin gefunden. Ich habe sie für euch übersetzt und weitere Features angefügt.

Feature	Beschreibung	Wahrscheinlichkeit	Quellen
64-bit only	SharePoint v14 / 2009 wird nur als 64bit Anwendung verfügbar sein.	Bestätigt	TechNet
Master Data Management	Eine Metadaten Verwaltung (Projekt "Bluedog") wird als Teil von SharePoint 14 ausgeliefert und bietet die Möglichkeit, die Entitäten unternehmesweit zu vereinheitlichen.	Sehr wahrscheinlich	Microsoft MDM Roadmap Wikipedia Microsoft MDM
CMIS support	Content Management Interoperability Services will allow SharePoint to communicate with other ECMs via web services.	Sehr wahrscheinlich	Microsoft
SQL-like Lists	Bill Gates will den Funktionsumfang von SharePoint Listen mit der Flexibilität und Performance von SQL Tables verbinden. Ob aber SharePoint Listen in Zukunft als SQL Tabellen abgelegt werden und uns die volle SQL Syntax offen steht, ist aber noch gar nicht sicher.	Wahrscheinlich	Bill Gates
Groove Integration	Bei installiertem Groove Client, stehen mehr Optionen für die Datensynchronisation zur Verfügung.	Wahrscheinlich	Ray Ozzie
ODF and PDF support	3rd Party IFilter um PDF und ODF Dokumente zu indexieren, wird nicht mehr notwenidg sein.	Wahrscheinlich	Microsoft
FAST search integration	Die FAST-basierte Suchengine wird die Microsoft Search Engine ablösen. Sicher ist, dass Microsoft immer mehr Know How von FAST in SharePoint einfliessen lässt.	Wahrscheinlich	CMS Watch
Site Definitions	Site Definitions werden nicht mehr unterstützt.	Gerücht	Gerüchte haben meistens keine Quelle...
Bi-direction BDC	Die Möglichkeit, Daten via BDC in Legacy Applikationen zu aktualisieren (Update, Insert).	Gerücht
Mehr Social Networking	Das Knowledge Network soll in die nächste SharePoint Version integriert werden. Dies wurde uns jedenfalls versprochen, als der Technology Preview von "Knowledge Network" aufgegeben wurde.	Gerücht	MSDN Blog
AJAX und Silverlight	Das UI und die Webparts werden mehr AJAX und Silverlight 2.0 einsetzen.	Gerücht

Language filter with Faceted Search

SharePoint Search extracts the language of a document during the crawl and use this information for the calculation of the relevancy while generating search results.

This behavior cause problems in multilingual enterprises. SharePoint search returns mainly documents in the user language (respectively the browser language).

Based on a post from Patrick Tisseghem about a hidden managed property which contains the language of a document. This managed property is called "DetectedLanguage". As Patrick mentioned, the language is stored as an integer value (9 = English, 7 = German, etc.). It could be used on your SharePoint out of the box (give it a try and search for "somekeyword deletectedlanguage:9").

But the real power of this managed property is developed in conjunction with Faceted Search. This open source SharePoint extensions allows you to use SharePoint meta data (or Managed Properties) as facets to refine your search. Go to the CodePlex project page and have a look at there web casts for more information.

You can extend Faceted Search to use your own managed properies as facets. In this way, you also can use the "detectedlanguage" property. Just paste to following XML snipped in the property "Select columns for Facets" in the "Search Facets" Web Part. With this, you will be able to restrict your search results based on the lanuage of a document.

As a side effect, you will see, that SharePoint (or the underlining IFilter) does lots of errors while detecting the language of a document.

Here is the XML snipped for the Faceted Search Web Part configuration:

<br /> <Column Name="DetectedLanguage" DisplayName="Language" OrderBy="Hits" TotalResults="5"><br /> <Mappings><br /> <Mapping DisplayName="Arabic" Match="1"/><br /> <Mapping DisplayName="Bengali" Match="69"/><br /> <Mapping DisplayName="Bulgarian" Match="2"/><br /> <Mapping DisplayName="Catalan" Match="3"/><br /> <Mapping DisplayName="Chinese" Match="4"/><br /> <Mapping DisplayName="Croatian/Serbian" Match="26"/><br /> <Mapping DisplayName="Czech" Match="5"/><br /> <Mapping DisplayName="Danish" Match="6"/><br /> <Mapping DisplayName="Dutch" Match="19"/><br /> <Mapping DisplayName="English" Match="9"/><br /> <Mapping DisplayName="Finnish" Match="11"/><br /> <Mapping DisplayName="French" Match="12"/><br /> <Mapping DisplayName="German" Match="7"/><br /> <Mapping DisplayName="Greek" Match="8"/><br /> <Mapping DisplayName="Gujrati" Match="71"/><br /> <Mapping DisplayName="Hebrew" Match="13"/><br /> <Mapping DisplayName="Hindi" Match="57"/><br /> <Mapping DisplayName="Hungarian" Match="14"/><br /> <Mapping DisplayName="Icelandic" Match="15"/><br /> <Mapping DisplayName="Indonesian" Match="33"/><br /> <Mapping DisplayName="Italian" Match="16"/><br /> <Mapping DisplayName="Japanese" Match="17"/><br /> <Mapping DisplayName="Kannada" Match="75"/><br /> <Mapping DisplayName="Korean" Match="18"/><br /> <Mapping DisplayName="Latvian" Match="38"/><br /> <Mapping DisplayName="Lithuanian" Match="39"/><br /> <Mapping DisplayName="Malay" Match="62"/><br /> <Mapping DisplayName="Malayalam" Match="76"/><br /> <Mapping DisplayName="Marathi" Match="78"/><br /> <Mapping DisplayName="Norwegian" Match="20"/><br /> <Mapping DisplayName="Polish" Match="21"/><br /> <Mapping DisplayName="Portugese" Match="22"/><br /> <Mapping DisplayName="Punjabi" Match="70"/><br /> <Mapping DisplayName="Romanian" Match="24"/><br /> <Mapping DisplayName="Russian" Match="25"/><br /> <Mapping DisplayName="Slovak" Match="27"/><br /> <Mapping DisplayName="Slovenian" Match="36"/><br /> <Mapping DisplayName="Spanish" Match="10"/><br /> <Mapping DisplayName="Swedish" Match="29"/><br /> <Mapping DisplayName="Tamil" Match="73"/><br /> <Mapping DisplayName="Telugu" Match="74"/><br /> <Mapping DisplayName="Thai" Match="30"/><br /> <Mapping DisplayName="Turkish" Match="31"/><br /> <Mapping DisplayName="Ukrainian" Match="34"/><br /> <Mapping DisplayName="Urdu" Match="32"/><br /> <Mapping DisplayName="Vietnamese" Match="42"/><br /> </Mappings><br /> </Column><br />

Update Content Type with a Feature

If you deploy your Content Types with a Feature, you will run into a problem, when you would like to modify the Content Type. If you modify and redeploy the Feature, then the Site Content Type is disconnected from the List Content Type. This is because very time a Content Type is assigned to a list, a new List Content Type is created, which inherits from the Site Content Type.

If you do the modification manually you should always modify the Site Content Type. While doing via Site Settings, you have an option which force SharePoint to propagate the modification to all the List Content Types inherited from the Site Content Type.

But when you do the modification by changing the Feature, then SharePoint won't update the inherited List Content Types. There are some STSADM extensions which do this work for you (i.e. from Gary Lapointe or Søren Nielsen).

I took the Code from Søren Nielsen and put it in a FeatureActivated Event Handler. In my Content Type Feature.xml I set the ReceiverAssembly and ReceiverClass attribute. This allows you the modify the Content Type in the Feature, upgrade the WSP, deactive and finally reactive the Feature. Reactivating the Feature will change the Site Content Type. SharePoint will propagate the modification with the FeatureActivated Event Handler to all the List Content Types inherited from the Site Content Type.

If you just add some Site Columns to your Site Content Type (or delete some unused Columns), this would make your deployment and change management process much more easier. Perhaps almost as easy as the good old ALTER TABLE SQL scripts ;)

Here is the my Code. Just copy the ProcessWeb() and all the other method from Søren Nielsen's blog.

<br /> public override void FeatureActivated(SPFeatureReceiverProperties properties)<br /> {<br /> SPWeb rootWeb = null;<br /> try<br /> {<br /> // get the site collection specified<br /> rootWeb = ((SPSite)properties.Feature.Parent).RootWeb;<br /><br /> //Get the source site content type<br /> SPContentType sourceCT =<br /> rootWeb.AvailableContentTypes[ContentTypeName];<br /> if (sourceCT == null)<br /> {<br /> throw new ArgumentException("Unable to find "<br /> + "contenttype named \"" + ContentTypeName + "\"");<br /> }<br /><br /> // process the root website<br /> ProcessWeb(rootWeb, sourceCT);<br /> }<br /> catch (Exception ex)<br /> {<br /> log.Fatal(ex.Message, ex);<br /> }<br /> finally<br /> {<br /> if (rootWeb != null)<br /> {<br /> rootWeb.Dispose();<br /> }<br /> }<br /> }<br />

Object Required Error – Drag & Drop of Web Parts

Some days ago one of my MOSS 2007 WCM sites faced up with an "Object Required" Java Script error while a content editor tried to drag & drop a Web Part in a custom Web Part Zone. Usually this sets the index of the Web Part in this Zone.

All right.. I tried to debug the problem with Visual Studio. The Debugger gave me the information about a missing offset in function “MSOLayout_GetRealOffset”, but I wasn't able to figure out what the reason for this behavior could be. After the provisioning of a new Site with the Standard Master Pages and Style Sheets applied, the error didn’t appear anymore. This means that it had something to do with my custom Styles I applied.

Step by step I reapplied my CSS and discovered that the error only appears when I apply the custom styles for my WebPart Zone Holder Divs.

In my CSS I had defined the property: “position: relative”, which caused the error.



You should use no other position definitions than “position: static”. This is the only way it works.



Drag & Drop anyway just works in Internet Explorer, but to miss this functionality is indeed not user friendly.

Display Profile Properties in Table Style

I would like to show you, how you can display profile properties in a table. For example this would allow you to generate a telephone directory from your profile data.

Briefly this would be done in two steps: indexing your profile properties and displaying them with a People Results Web Part.

Let's start creating a managed property. Every property you would like to display on the list, must be crawled by the index and mapped to a managed property.

Creating a managed property

1. On the SSP admin site, go to the "User profile and property" page, select "View Profile Properties" and select the profile property, you want to display. You could also create new properties.
   
2. Make sure that the checkbox "Indexed" is selected.
3. Repeat this set for every property.
4. Do a full crawl of the SSP/MySite content source (usually the "Local Office SharePoint Server sites")... and wait until it is completed.
5. Now you can create managed properties. For this, go to "Search Settings" and choose "Metadata property mappings".
6. First check, if your desired property is no all ready managed. If not, create a new managed property and add a mapping to the crawled property.
7. Again start a full crawl.

Sample with the managed property "Xing" which is mapped to the crawled propery "Xing".

Bringing the properties to the screen

Of course you could write a Web Part which iterates over the profiles and then render the data in a gridview. But you can also do this by configuration with the People Search Core Results Web Part.

1. To begin, you have to create a new Web Part Page and add the "People Search Core Result s".
2. In the Web Part Properties you set a "Fixed Keyword Query" and select a Cross-Web Part Query ID different from "user query". As "Fixed Keyword Query" you could enter contentclass:"SPSPeople" to display all profiles. But you can also define a custom query, which matches only to a parts of the profiles in your Shared Service Provider.
   
   
   
   
3. Under "Selected Columns" add a line for every Managed Property. Check first, if it's not allready there. In our sample, I added <column name="Skills"> before the closing </columns> tag.
4. Now we have to edit the XSL. If you are a native XSL speaker like my fellow worker Dänu, you can start creating your XSL and can stop reading here.
   
   
   
   
5. If not, here some tricks how this could be done. I would suggest, that you copy the existing XSL. This XSL could be used later as a starting point.
6. With the following XSL you can output the XML code of the search resutls.
   

   
   <?xml version="1.0" encoding="utf-8"?>
   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   <xsl:template match="@* | node()">
   <xsl:copy>
     <xsl:apply-templates select="@*|node()" />
   </xsl:copy>
   </xsl:template>
   </xsl:stylesheet>
   

   
   Copy & Paste it in to the XSL editor field and hit "Apply".
   
7. Now you have to look at the HTML source code. Search for and copy the hole tag (until the closing ) to the clipboard. In this XML you will see all the properties returned by SharePoint.
   
8. If you are familiar with Visual Studio 2008 you could use it to generate a new XSL. Save the XML output to a file und try to run the XSL against that file (Menu: XML \ Show XSLT Output).
   

Here is a sample XSL which display the name, the e-mail and a like to a Xing profile.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<!-- XSL transformation starts here -->
<xsl:template match="/">
<table>
  <tr>
    <td>Name</td>
    <td>Email</td>
    <td>Xing</td>
  </tr>
  <xsl:apply-templates />
</table>
</xsl:template>

<!-- This template is called for each result -->
<xsl:template match="All_Results/Result">
<xsl:variable name="id" select="id"/>
<xsl:variable name="url" select="url"/>
<tr>  
  <td>
    <a href="{$url}" id="{concat('CSR_',$id)}">
      <xsl:value-of select="preferredname"/>
    </a>
  </td>
  <td>
    <xsl:value-of select="workemail"/>
  </td>
  <td>
    <xsl:if test='string-length(xing) &gt; 0'>
      <a href="{xing}" id="{concat('XING_',$id)}">
        <xsl:value-of select="xing"/>
      </a>
    </xsl:if>    
  </td>
</tr>  
</xsl:template>
</xsl:stylesheet>

WCM Approval Configrator

Today I wrote a small application which will allow you to set some of the approval workflow settings on a per-site base. This apps will modifiy the workflow association for you on every "Pages" library in the selected sites.

You have the possibility to enable or disable the approval workflow, choose the participants of the workflow and allow or disallow to change the participants lists on workflow start.

I created this application to configure the approval workflow on a customer site. If you want you can download and extend the source code. You will see, that the association data is stored in a XML and with a little debugging you will be able to also modify the other parameters.

Here you can download the application including source code and Visual Studio 2008 project.

Update 10/17/2008: I moved the code to an ASPX, packed as WSP and uploaded to CodePlex. You can find the download on the MOSSApprovalConfig project site.

how to: avoid loading “name.dll” active X component in anonymous WCM scenarios

just imagine.. after hard weeks of SharePoint development you configure your anonymous authentication provider to publish your web app anonymously to the internet. After you first browse your site, it wants to install an active x component named "name.dll". this component is loaded by core.js. The component then tries to fetch the availability information of Microsoft Office Communicator. I don't think your anonymous users will use this functionality. ;-)

Let's have a look at the problem:

In case of performance optimization you should never load core.js in anonymous WCM scenarios. SharePoint also tries to load other unnecessary stuff.

A nice way to avoid this is the MossCleanup HTTP Filter. Information on how to implement this: http://www.ie-soft.de/blog/PermaLink,guid,968b0588-f306-467b-be51-54f7a8f2079d.aspx

Fallback: If you need the core.js for any reason, just add this piece of javascript to your masterpage and "name.dll" wont be loaded anymore.

<!-- Avoid calling name.dll ActiveX -->

<script language="javascript" type="text/javascript">

function ProcessImn(){}

</script>