Mavention

Mavention ontwikkelt nieuwe website Amsterdam RAI

Wed, 22 Feb 2012 16:36:19 GMT

Amsterdam RAI heeft Mavention gevraagd een nieuwe website te ontwikkelen met SharePoint 2010. De nieuwe website moet de verschillende doelgroepen van Amsterdam RAI beter met elkaar verbinden, door meer gebruik van community functies, doelgroepgerichte informatie en inspirerend beeldmateriaal.

Mavention ontwikkelt de nieuwe website met SharePoint 2010 en de nieuwste technieken, zoals HTML5. De website wordt geoptimaliseerd voor toegankelijkheid, search en performance. Verschillend producten van Mavention worden hierbij ingezet. Als basis voor de SharePoint oplossing wordt Mavention Flex Layout gebruikt. Daarnaast worden ook andere WCM producten van Mavention ingezet.

Mavention is inmiddels gestart met het project en verwacht de nieuwe website in april op te leveren.

Meer informatie over het ontwikkelen van websites met SharePoint? Neem dan contact op met Joris Engels.

Speaking at the SharePoint Saturday Holland

Wed, 22 Feb 2012 08:19:42 GMT

On March 24 there will be the next edition of SharePoint Saturday Holland. I have the honor of presenting two sessions for SharePoint developers.

Diwug.nl v2 – How we did it

Recently me and fellow Mavens built a new website for the Dutch Information Worker User Group. This website uses HTML5, is accessible and, what’s the most important, is built on the Microsoft SharePoint 2010 platform. In this session, that I will co-presenting with Octavie van Haaften, we are going to show you how we built the new website for DIWUG.

Optimizing SharePoint 2010 websites for search engines

Whenever you build a public-facing website you want people to find it. Although your website will eventually be indexed by search engines by itself, there are ways for you to help search engines discover the content on your website. In this session I will share with you some tips and tricks in how you can optimize your public-facing website built on the SharePoint 2010 platform for search engines.

About SharePoint Saturday Holland

Join SharePoint architects, developers, and other professionals that work with Microsoft SharePoint Server 2010 for ‘SharePoint Saturday’ event. SharePoint Saturday is an educational, informative & lively day filled with sessions from respected SharePoint professionals & MVPs, covering a wide variety of SharePoint-orientated topics. SharePoint Saturday is FREE, open to the public and is your local chance to immerse yourself in SharePoint!

See you on the SharePoint Saturday Holland!

Originally posted at http://blog.mastykarz.nl/speaking-sharepoint-saturday-holland/

Speaking at The International SharePoint Conference London 2012

Wed, 22 Feb 2012 07:27:43 GMT

During the upcoming International SharePoint Conference London 2012 I will be co-presenting three sessions in the developer track.

Project Startup DEV202

In the Project Startup DEV202 session, that I will be co-presenting with fellow SharePoint MVP and SharePoint MCM Wictor Wilén, Wictor and I will be discussing different approaches to structure your solution and make to help you get the most of the Visual Studio 2010 SharePoint Developer Tools .

Deployment Process – Creating web templates, setup lifecycle management and deployment parts 1 (DEV206) and 2 (DEV207)

Later in the developer track I will be co-presenting two sessions (DEV206 and DEV207) with fellow SharePoint MVP and SharePoint MCM Mirjam van Olst. In our sessions Mirjam and I will be discussing the process of packaging different pieces of the solution that we will be working with so that you can support all the different requirements during the whole lifecycle of the project.

The Developer Track

This year the developer track will be organized in a different way than previously (quoted from the ISC site):

This track is for all the Developers out there who are just starting a SharePoint journey of discovery and for those developers who have been developing for a while and now need to hone their skills to a more advanced level. There is so much that you can do with SharePoint where do you start, and what is the correct way to take a design all the way through to a finished solution deployed live in your production farm. The Developer track in 2012 will be a unique track with a complete 3 day focus on taking a concept all the way through its build, test and deployment process and showing how in the real world what situations a developer can come across and how those situations are troubleshot and resolved. Unlike normal session based conferences this year we plan on expanding on the basic knowledge and going as deep as is needed, so if a topic needs 2 sessions to cover it thoroughly then 2 sessions will be scheduled so you get all the information you need when you go back to the office.

As you can see, instead of giving separate presentations we will be aiming at giving you a more complete insight into the process and hopefully share with you more knowledge that you can benefit of in your every day's work.

I’m looking forward to seeing you in London!

Originally posted at http://blog.mastykarz.nl/speaking-international-sharepoint-conference-london-2012/

changing the application pool for existing web applications

Tue, 21 Feb 2012 08:33:59 GMT

There are many articles about SharePoint 2010 and application pool management. One of those topics is the number of application pools to be used by your SharePoint web applications. I like this post by Todd Klindt: Top 10 SharePoint 2010 Configuration Mistakes. Mistake #5 is about application pools and web applications. There’s no need to have an application pool for each web application. Sharing an application pool by several web applications saves you lots of megabytes of memory.

With Central Administration it is undoable to set a different application pool for a web application. First, you have to delete the web application without deleting the IIS site and content databases. Then you can recreate the web application using the correct application pool, the existing IIS site and finally attaching the content databases. If you have features activated at the web application scope, you also have to reactivate them again and Lord knows what happens then!

You don’t want this. No, you don’t.

Alternative? PowerShell of course! Basically you will need a reference to the application pool first, then a reference to the web application and then you can update the ApplicationPool property.

At one of my customer’s SharePoint Farm I noticed that every web application had it’s own Application Pool. What a waste of resources that is. Time for scripting, I guess.

Here’s my PowerShell Script:

$config = Get-Content Set-DefaultApplicationPoolConfig.xml
$defaultAppPoolName = $config.WebApplications.defaultAppPoolName
 
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[Void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration") 
 
$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService 
 
Write-Host "Checking presence default application pool $defaultAppPoolName..." -NoNewline
 
[Microsoft.SharePoint.Administration.SPApplicationPool] $newAppPool = $service.ApplicationPools[$defaultAppPoolName] 
 
## The Default Application Pool MUST exist!
if($newAppPool -eq $NULL)
{
    Write-Host ""
    Write-Host -ForegroundColor Red "The default application pool '$defaultAppPoolName' does not exist."
    Write-Host -ForegroundColor Red "Please ensure the application pool '$defaultAppPoolName' is already registered in SharePoint."
    exit
}
else
{
    Write-Host -ForegroundColor Green "[OK]"
}
 
foreach( $webAppConfig in $config.WebApplications.WebApplication )
{
    $url = $webAppConfig.url
    Write-Host "Updating $url..." -NoNewline
 
    $webApp = Get-SPWebApplication $url -ErrorAction SilentlyContinue
 
    if( $webApp -eq $null )
    {
        Write-Host -ForegroundColor Yellow " [Web application does not exist]"
        continue
    }
 
    $currentAppPool = $webApp.ApplicationPool
    if($currentAppPool.Name -eq $defaultAppPoolName)
    {
        Write-Host -ForegroundColor Green " [Change not needed]"
    }
    else
    {
        $webApp.ApplicationPool = $newAppPool
        $webApp.Update()
        $webApp.ProvisionGlobally()
        Write-Host -ForegroundColor Green " [Done]"
    }
}

As you can see this script uses a XML configuration file. In this file I configure what the default application pool name is and which web applications I want to change to this application pool.

XML Configuration file:

<WebApplications defaultAppPoolName="SharePoint - Default Web Application Pool" >
    <WebApplication url="http://dummy.ochadev.local" />
    <WebApplication url="http://redactie.diwug.local" />
    <WebApplication url="http://playground.ochadev.local" />
    <WebApplication url="http://testdummy" />
</WebApplications>

And this is the result:

After executing the script the SharePoint web applications are registered with the new default application pool. This also means that whenever you extend your farm with a new SharePoint server, it also has the correct web applications and their application pools.

Good luck and enjoy.

Download script

Originally posted at http://blog.octavie.nl/index.php/2012/02/21/changing-application-pool-for-existing-web-applications/

Modifying views of a List View Web Part in a Sandboxed Solution

Fri, 10 Feb 2012 09:19:51 GMT

In my recent article I showed you how to declaratively provision List View Web Parts to pages from within a Sandboxed Solution. Since the default view is often not what you want and creating a List Definition just to get the right view for the List View Web Part is way too much overhead, what is the easiest approach to modify a view of a List View Web Part in a Sandboxed Solution?

The challenge when working with List View Web Parts (LVWP), or any other Web Part for that matter, from within a Sandboxed Solution is that the SPLimitedWebPartManager class is not available. This makes it impossible to programmatically modify any of the Web Part’s properties after it has been added to a page. Although most Web Parts can be provisioned preconfigured, it’s the List View Web Part that makes things challenging. Because you cannot access the LVWP, you cannot change the view that the Web Part is using, or can you?

BinarySerializedWebPart

One of the changes in SharePoint 2010 is storing saved Site Templates as SharePoint Packages (WSP). To support provisioning preconfigured List View Web Part the BinarySerializedWebPart element has been introduced. Stefan Stanev has a good article describing the whole process and Peter Holpar has a series of articles dedicated to working with the BinarySerializedWebPart.

Although the BinarySerializedWebPart works and will get you the right results, it’s rather inconvenient to use. First of all, because the Web Part is serialized, it’s hard to tell what its contents are. This is particularly important when multiple developers are working on the solution. Another challenge that the BinarySerializedWebPart introduces, is that it’s nearly impossible to maintain the BinarySerializedWebPart. Probably the only convenient way of doing it would be to have the Web Part provisioned to a page, apply the required changes, and export the Web Part again.

There is however another approach that you might consider.

Anatomy of a List View

If you have ever taken a closer look at List Views, you might have noticed the Url property. Although it might not seem like much it turns out that for views used by the List View Web Part, the Url property contains the URL of the page on which the List View Web Part using that particular view is located!

As shown in the figure below, a List View Web Part for the standard Announcements List added to the SitePages/Home.aspx page would create a hidden View in the Announcements List with the Url property set to SitePages/Home.aspx.

Given this, all we have to do, to modify the List View Web Part’s View, is to get a reference to the Announcements List, get a reference to the right View, apply our changes and update the view: all of which can be perfectly done from within a Sandboxed Solution!

Programmatically changing List View Web Part’s View

The perfect place for applying changes to a LVWP’s View is the Feature Receiver of a Feature that provisions that LVWP to a page. The following code snippet shows how you can modify the view of a List View Web Part pointing to the standard Announcements List.

using System;
using System.Linq;
using System.Runtime.InteropServices;
using Microsoft.SharePoint;

namespace WebPartsFromSandbox.Features.Pages {
    [Guid("8645cbdd-101a-4866-9701-8957975238e4")]
    public class PagesEventReceiver : SPFeatureReceiver {
        public override void FeatureActivated(SPFeatureReceiverProperties properties) {
            SPWeb web = properties.Feature.Parent as SPWeb;

            if (web != null) {
                ChangeViewFieldsForAView(web, web.RootFolder.WelcomePage, "Announcements", new string[] { "Title" });
            }
        }

        private static void ChangeViewFieldsForAView(SPWeb web, string pageUrl, string listName, string[] viewFields) {
            SPList list = web.Lists[listName];
            SPView view = (from SPView vw
                           in list.Views
                           where vw.Url == pageUrl
                           select vw).FirstOrDefault();

            if (view != null) {
                view.ViewFields.DeleteAll();

                foreach (string viewFieldName in viewFields) {
                    view.ViewFields.Add(viewFieldName);
                }

                view.Update();
            }
        }
    }
}

After executing this code you should see the standard view of a List View Web Part pointing to the Announcements List changed to show only the Title column.

As you can see the code required to modify a the view of a List View Web Part is simple. We start with retrieving a reference to the List with which the LVWP is associated (line 18). Next, from the list of all available Views we retrieve the View that is used by the LVWP. We use the Url property to determine which View that is (lines 19-22). In this sample all we do, is to change the fields visible in the View. We do this by first removing all fields (line 25) and then we add all fields that we want to be visible in the View (lines 27-29). When done we confirm our changes by calling the List’s Update method (line 31).

Summary

One of the frequent challenges when provisioning List View Web Part from within Sandboxed Solutions is the inability to modify the view used by the Web Part. Using the fact the URL of the View created by the LVWP points to the page where the LVWP is located you can easily retrieve that View and modify it to meet your requirements.

Originally posted at http://blog.mastykarz.nl/modifying-views-list-view-web-part-sandboxed-solution/

Mavention spreekt op SharePoint Conference in London

Sat, 11 Feb 2012 14:53:15 GMT

Op 23 april 2012 vertelt Waldek Mastykarz de best practices voor de inrichting van SharePoint Solutions op de The International SharePoint Conference London 2012.

De SharePoint conference in Londen wordt dit jaar voor de vierde keer gehouden. Niet alleen de naam (voorheen: ‘best practices’) maar ook de opzet is dit jaar anders. In drie dagen tijd wordt een volledig project uitgevoerd. Door de verschillende programmaonderdelen heen wordt een kennismanagement oplossing ontwikkeld.

Het opzetten van een SharePoint solution is de basis voor vrijwel ieder project. Waldek Mastykarz geeft tijdens één van de eerste tracks op de conferentie een presentatie over dit onderwerp (DEV202): ‘Hoe haal je het meeste uit de developer tools die op de markt zijn?’ Waldek geeft deze presentatie samen met Wictor Wilén. Wictor is net als Waldek SharePoint MVP (Most Valuable Professional) en houdt zich voornamelijk met SharePoint ontwikkeling bezig.

Meer informatie over de SharePoint conference in Londen vindt u hier.

Inconvenient provisioning Web Parts to Wiki Pages in Sandboxed Solutions

Sun, 05 Feb 2012 14:13:57 GMT

Sandboxed Solutions are a powerful way to create SharePoint 2010 Solutions in a secure manner. The price of security however is limited access to the SharePoint API which makes it challenging to accomplish certain tasks like provisioning Web Parts to Wiki Pages. Find out how to provision Web Parts to Wiki Pages in Sandboxed Solutions.

Playing in the Sandbox

The introduction of Sandbox in SharePoint 2010 empowers both IT-Pros and Developers. Using Sandboxed Solutions developers can deliver rich solutions that leverage the SharePoint 2010 capabilities. Because those solutions are executed in an isolated fashion and have limited access to the SharePoint API and the .NET Framework, there are less risks involved with deploying and using them in a SharePoint Farm. One more important benefit of using Sandboxed Solutions is, that they require less involvement from IT departments as they can be deployed and managed by Site Collection Administrators.

In SharePoint 2007, where no Sandbox was available, designing SharePoint Solutions was a lot like all or nothing: either developers were allowed to create solutions with custom code and had virtually access to the full SharePoint API and .NET Framework or SharePoint Farms were sealed, no custom code would be allowed and developers were tasked with the challenge to get things to work using nothing more than the standard functionality of the SharePoint platform. As you can imagine neither of those two approaches is perfect. Allowing developers to use the full API means you have to spend more time on security-testing their work and narrowing the options to standard functionality only means that not the solution but the technical capabilities are central and there is a chance that business might get not the solution that they need, not to mention the extra effort required to “just get things done”.

Sandboxed Solutions offer added value to SharePoint developers allowing them to use their knowledge to build secure solutions. And although the API available for Sandboxed Solutions gives developers the ability to interact with data stored in SharePoint, it might be too limited to complete all tasks and provide end users with fully working solutions instead of a collection of building blocks and a manual.

Inconvenient provisioning Web Parts instances from Sandboxed Solutions

One of the challenges when working with Sandboxed Solutions is how to provision Web Parts instances to pages. If you have done this before in a Farm Solution you know, that in order to add a Web Part to a page programmatically in SharePoint you have to retrieve the instance of the SPLimitedWebPartManager class and use it to add the instance of a Web Part to a page. Unfortunately, as the SDK mentions, the SPLimitedWebPartManager class is not available in Sandboxed Solutions which means that you cannot programmatically add a Web Part to a page from within a Sandboxed Solution.

Luckily the programmatic approach isn’t the only option that SharePoint offers for adding Web Parts to pages. It turns out that there is a declarative approach as well, which is just perfect for when you need to provision a Web Part instance from within a Sandboxed Solution.

Declaratively provisioning Web Part instances to pages

Declaratively provisioning Web Part instances to pages is easy and can be done using a Module. The following code snippet shows how you can add a Content Editor Web Part with the Hello world text to a Web Part Page:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="HomePage">
    <File Path="HomePage\default.aspx" Url="default.aspx">
      <AllUsersWebPart WebPartOrder="0" WebPartZoneID="Left">
        <![CDATA[<?xml version="1.0" encoding="utf-8"?>
<WebPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/WebPart/v2">
  <Title>Content Editor</Title>
  <FrameType>Default</FrameType>
  <Description>Allows authors to enter rich text content.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>Left</ZoneID>
  <PartOrder>0</PartOrder>
  <FrameState>Normal</FrameState>
  <Height />
  <Width />
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <AllowConnect>true</AllowConnect>
  <AllowEdit>true</AllowEdit>
  <AllowHide>true</AllowHide>
  <IsVisible>true</IsVisible>
  <DetailLink />
  <HelpLink />
  <HelpMode>Modeless</HelpMode>
  <Dir>Default</Dir>
  <PartImageSmall />
  <MissingAssembly>Cannot import this Web Part.</MissingAssembly>
  <PartImageLarge>/_layouts/images/mscontl.gif</PartImageLarge>
  <IsIncludedFilter />
  <Assembly>Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
  <TypeName>Microsoft.SharePoint.WebPartPages.ContentEditorWebPart</TypeName>
  <ContentLink xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor" />
  <Content xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor">Hello world</Content>
        <PartStorage xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor" />
        </WebPart>]]></AllUsersWebPart>
    </File>
  </Module>
</Elements>

Important: to provision a Web Part to a Web Part Page you will need a Web Part Page file. You can copy the default Web Part Page file from 14\TEMPLATE\SiteTemplates\sts\default.aspx.

As you can see adding Web Parts to Web Part Pages is fairly easy. The challenge begins however as soon as you start working with Wiki Pages.

Declaratively provisioning Web Part instances to Wiki Pages

One of the new features introduced with SharePoint 2010 was the concept of adding Web Parts in content. Before that we had to use Content Editor Web Parts to store content if we wanted to use Web Parts in between. With SharePoint 2010 we could just type rich content and insert Web Parts in between just as if we were adding images or tables.

The Web Parts in content capability has been made available in Publishing Sites as well as Collaboration Sites. The only requirement with regards to Collaboration Sites is, that you have to be using Wiki Pages. A while ago I wrote an article about how you can add Web Part instances to content. The approach I presented involved using custom code which unfortunately cannot be used from within Sandboxed Solutions as it relies on the SPLimitedWebPartManager class. However using the same information about how Web Parts in content work behind the scenes, we can alter the declarative approach used for Web Part Pages to add a Web Part to a Wiki Page. The following code snippet presents the Module modified to add the Content Editor Web Part to a Wiki Page:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="HomePage">
    <File Path="HomePage\wkpstd.aspx" Url="SitePages/Home.aspx">
      <Property Name="WikiField" Type="string" Value="
&lt;div class=&quot;ms-rtestate-read ms-rte-wpbox&quot; contentEditable=&quot;false&quot;&gt;&lt;div class=&quot;ms-rtestate-read 46113482-da36-45a5-bbac-e1e1771c19fa&quot; id=&quot;div_46113482-da36-45a5-bbac-e1e1771c19fa&quot;&gt;&lt;/div&gt;&lt;div style='display:none' id=&quot;vid_46113482-da36-45a5-bbac-e1e1771c19fa&quot;&gt;&lt;/div&gt;&lt;/div&gt;
      "/>
      <AllUsersWebPart WebPartOrder="0" WebPartZoneID="wpz" ID="g_46113482_da36_45a5_bbac_e1e1771c19fa">
        <![CDATA[<?xml version="1.0" encoding="utf-8"?>
<WebPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/WebPart/v2">
  <Title>Content Editor</Title>
  <FrameType>Default</FrameType>
  <Description>Allows authors to enter rich text content.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>Left</ZoneID>
  <PartOrder>0</PartOrder>
  <FrameState>Normal</FrameState>
  <Height />
  <Width />
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <AllowConnect>true</AllowConnect>
  <AllowEdit>true</AllowEdit>
  <AllowHide>true</AllowHide>
  <IsVisible>true</IsVisible>
  <DetailLink />
  <HelpLink />
  <HelpMode>Modeless</HelpMode>
  <Dir>Default</Dir>
  <PartImageSmall />
  <MissingAssembly>Cannot import this Web Part.</MissingAssembly>
  <PartImageLarge>/_layouts/images/mscontl.gif</PartImageLarge>
  <IsIncludedFilter />
  <Assembly>Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
  <TypeName>Microsoft.SharePoint.WebPartPages.ContentEditorWebPart</TypeName>
  <ContentLink xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor" />
  <Content xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor">Hello world</Content>
        <PartStorage xmlns="http://schemas.microsoft.com/WebPart/v2/ContentEditor" />
        </WebPart>]]></AllUsersWebPart>
    </File>
  </Module>
</Elements>

Important: Note that the Wiki Page uses a different page file that can be copied from 14\TEMPLATE\DocumentTemplates\wkpstd.aspx

If you took a careful look at the code snippet you might have noticed that a few things have changed. First of all we changed the page’s URL to SitePages/Home.aspx (line 4) so that it points to a Wiki Page instead of a Web Part Page. Next we added the WikiField property (lines 5-7) which contains the content of the Wiki Page. Although the content is a little difficult to read it contains the HTML marker of Web Part added to content, which after decoding looks like this:

<div class="ms-rtestate-read ms-rte-wpbox" contenteditable="false"><div class="ms-rtestate-notify  ms-rtestate-read 46113482-da36-45a5-bbac-e1e1771c19fa" id="div_46113482-da36-45a5-bbac-e1e1771c19fa"></div><div id="vid_46113482-da36-45a5-bbac-e1e1771c19fa" style="display: none"></div></div>

Next, to the AllUsersWebPart tag we added the ID attribute (line 8). Although the SDK doesn’t explain what this attribute is for, it can be used to provision a Web Part with a predefined ID. The only requirement is, that all – (dash) are replaced with _ (underscore) and the ID is prefixed with g_. As you can see the Web Part’s ID corresponds to the ID used in the marker placed in the Wiki Page’s content.

Bonus: Declaratively Provisioning List View Web Parts to Wiki Pages

There are scenarios when you might need to provision a List View Web Part to a Wiki Page. The good news is that the required approach is not much different from provisioning a Content Editor Web Part or any other Web Part for that matter.

If you’ve worked with declaratively provisioning List View Web Parts you know that in order to add a List View Web Part to a page you have to use the View element. For example to add a List View Web Part for the Announements list available in a standard Team Site to a Web Part Page, you would use the following code:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="HomePage">
    <File Path="HomePage\default.aspx" Url="default.aspx">
      <View List="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;" BaseViewID="1" WebPartZoneID="Left" WebPartOrder="0" />
    </File>
  </Module>
</Elements>

Adding List View Web Parts to content is very similar to adding regular Web Parts. All you need to do is to change the value of the WebPartZoneID attribute to wpz and add the ID attribute to the View element with a GUID specified exactly as if you would for any other Web Part that would be added in content, for example:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="HomePage">
    <File Path="HomePage\wkpstd.aspx" Url="SitePages/Home.aspx">
      <Property Name="WikiField" Type="string" Value="
&lt;div class=&quot;ms-rtestate-read ms-rte-wpbox&quot; contentEditable=&quot;false&quot;&gt;&lt;div class=&quot;ms-rtestate-read 46113482-da36-45a5-bbac-e1e1771c19fa&quot; id=&quot;div_46113482-da36-45a5-bbac-e1e1771c19fa&quot;&gt;&lt;/div&gt;&lt;div style='display:none' id=&quot;vid_46113482-da36-45a5-bbac-e1e1771c19fa&quot;&gt;&lt;/div&gt;&lt;/div&gt;
      "/>
      <View List="$Resources:core,lists_Folder;/$Resources:core,announce_Folder;" BaseViewID="1" WebPartZoneID="wpz" WebPartOrder="4" ID="g_46113482_da36_45a5_bbac_e1e1771c19fa" />
    </File>
</Module>
</Elements>

Summary

Sandboxed Solutions offer great power and flexibility for extending the SharePoint platform with custom functionality. The price of this empowerment is limited access to the SharePoint API and the .NET Framework. One of the common tasks which is affected is provisioning Web Part instances to pages. Although the programmatic approach is not available to SharePoint developers, the declarative way is a good alternative.

Originally posted at http://blog.mastykarz.nl/inconvenient-provisioning-web-parts-wiki-pages-sandboxed-solutions/

Kennisnet voor Nederlandse Zorgautoriteit online

Wed, 01 Feb 2012 10:30:43 GMT

Het interne kennisplatform van de Nederlandse Zorgautoriteit (NZa) is live gegaan: Kennisnet. Het doel van Kennisnet is het delen en verspreiden van kennis over verschillende aspecten van zorgonderwerpen en zorgmarkten. Kennisnet is voor iedereen binnen NZa toegankelijk.

Binnen Kennisnet hebben de NZa-medewerkers een eigen profielpagina die zij zelf invullen en aanvullen met kennis, expertise en ervaring. Binnen deze profielpagina’s kan naar collega’s gezocht worden met bepaalde kennis of ervaring. Daarnaast is een keur aan achtergrondinformatie opgenomen, in zogeheten Wiki’s. NZa-medewerkers werken samen aan een bepaald zorgonderwerp en houden de kennis actueel. Bovendien kan via de digitale werkruimten een groepje collega’s met elkaar contact houden, vragen en dilemma's voorleggen, discussies voeren over actuele ontwikkelingen en documenten uitwisselen.

Als kennisintensieve organisatie heeft NZa behoefte aan een eenvoudig en efficiënt platform voor het uitwisselen van kennis en ervaring en een platform waar collega’s makkelijk kunnen samenwerken. Het door Mavention ontwikkelde Kennisnet biedt dit platform.

Kennisnet is een onderdeel van het NZa-project professionalisering informatiestromen.

Meer informatie is te vinden op de referentiepagina van het project Kennisnet voor de NZa.

Easier using widgets in SharePoint 2010 with the Mavention Widget Web Part

Fri, 27 Jan 2012 15:03:18 GMT

In my previous article I explained why using widgets in SharePoint 2010 is inconvenient and showed what you can do to make it easier using the standard functionality. In this article I’ll show you how you can simplify working with widgets even further using the Mavention Widget Sandboxed Web Part.

Mavention Widget Web Part

The Mavention Widget Web Part is a Sandboxed Web Part which allows you to include in the page any snippet of HTML without any restrictions. Although from the functionality point of view this Web Part doesn’t seem like much, it’s offering you a lot of flexibility and simplifies the maintenance of your pages.

In order to use the Mavention Widget Web Part you have to activate the Mavention Widget Web Parts Package first. Since it is a Sandboxed Solution you can do it by opening the Site Settings and navigating to the Solution Gallery.

After uploading and activating the Mavention Widget Web Parts Package the Mavention Widget Web Parts Feature is installed. Because it’s a Site Collection-scoped Feature it is also automatically activated allowing you to directly start with including widgets on your pages.

After activating the Solution Package navigate to the page where you would like to insert a widget, edit the page and from the Insert tab click the Web Part button.

From the Categories list choose Mavention Web Parts (1), select the Widget Web Part (2) and click the Add button (3) to add the Web Part.

After adding the Web Part, edit its properties and from the Widget Web Part section click the Edit… button.

Next, in the dialog window, paste the contents of your widget and confirm changes by clicking the OK button.

After you confirm changes the widget will appear in the Web Part.

Editing the widget is just as easy as adding it. All you need to do is to open the Widget Web Part’s properties, click the Edit… button and you will see the widget’s code just as you pasted it.

Download: Mavention Widget Web Part (5KB, Sandboxed WSP)

Originally posted at http://blog.mastykarz.nl/easier-widgets-sharepoint-2010-mavention-widget-web-part/

Deploying solutions with Language Packs with PowerShell

Fri, 27 Jan 2012 13:36:18 GMT

In previous post(s) I described deploying your solutions with PowerShell. Lately I encountered the situation I had to deploy a solution language pack. This is a regular WSP file with the same Solution ID as the original solution, but containing localization resources for specific languages. The purpose of solution language packs is to add localization for additional languages after the original solution package has already been distributed without having to upgrade the original solution package. I suggest you read this MSDN article about Working with Language Pack Farm Solutions.

Deployment

For deploying these solution language packs the same PowerShell cmdlets can be used: Add-SPSolution and Install-SPSolution. However, this time the –Language parameter must be used. Keep in mind that the original solution is deployed first.

Removal

For removing these solution language packs the same PowerShell cmdlets can be used: Remove-SPSolution and Uninstall-SPSolution. Again, the –Language parameter must be used. Also, the original solution is still present in the farm.

Extending the script

So, how can we fit this deployment and removal in our existing script Solutions.ps1?

First of all, we need to tell our script we’re dealing with a solution language pack. I have created a Solution.xml file with solutions to deploy, remove or update (I kept it simple):

<Solutions>
  <Solution file="..\SharePointLearningKit.wsp" deploy="TRUE" remove="TRUE" update="FALSE" />
  <Solution file="..\SharePointLearningKit-1043.wsp" deploy="TRUE" remove="TRUE" update="FALSE" lcid="1043" />
</Solutions>

The lcid attribute tells the script that it is a solution language pack and which language it is. Another important thing is that I have named the wsp file correctly: the same name as the original code solution and a suffix “-{lcid}”. I will use this in the scripts.

Secondly, our deploy.ps1 (and also remove.ps1 and update.ps1) needs to be changed in order to use the Solutions.xml file.

$deployConfig = Get-Content Solutions.xml
 
foreach( $solution in $deployConfig.Solutions.Solution )
{
    if( $solution.deploy.ToUpper().Equals("TRUE") )
    {
        if( $solution.lcid )
        {
            .\solution.ps1 -solution $solution.file -deploy -url $url -language $solution.lcid
        }
        else
        {
            .\solution.ps1 -solution $solution.file -deploy -url $url
        }
    }
 
}

When the solution configuration item contains a lcid attribute it calls the solution.ps1 script with the language parameter provided with the lcid value.

Third and final step is to change the solution.ps1 script to actually deploy (or remove or update) the solution language pack. As just mentioned the solution.ps1 script has an additional parameter Language:

param(
    [string]$solution,
    [string]$url,
    [switch]$deploy = $false,
    [switch]$remove = $false,
    [switch]$update = $false,
    [int]$language
)

Then if $language is provided (the actual value will be greater then 0), we are dealing with a solution language pack and we need to know the name of the original solution.

# locate the solution file:
$solutionFile = Get-ChildItem $solution
# get the solution Name
$solutionName = [System.IO.Path]::GetFilename($solutionFile)
 
if( $language)
{
    #solutionCoreName is the name of the original solution package
    $solutionCoreName = $solutionName.Replace( "-$language", "" )
}

For deployment, the script looks like this:

if($deploy){
 
    Write-Host ""
    Write-Host -ForegroundColor Yellow "Installing " -NoNewline
    Write-Host -ForegroundColor Green $solutionName -NoNewline
    if( $language )
    {
        Write-Host -ForegroundColor Green "($language)"
    }
    else
    {
        Write-Host ""
    }
 
    if( $language )
    {
        $sol = Get-SPSolution $solutionCoreName -ErrorAction SilentlyContinue
        $sol = $sol.LanguagePacks | where-object { $_.LocaleId -eq $language }
    }
    else
    {
        $sol = Get-SPSolution $solutionName -ErrorAction SilentlyContinue
    }
 
    if ($sol)
    {
        Write-Host -ForegroundColor yellow "$solutionName already installed in this farm"
    }
    else
    {
        Write-Host -ForegroundColor yellow "Adding to the farm" -NoNewline
        if( $language )
        {
            Write-Host -ForegroundColor yellow " with langauge $language" -NoNewline
            $sol = Add-SPSolution $solutionFile -Language $language
        }
        else
        {
            $sol = Add-SPSolution $solutionFile
        }
        Write-Host -ForegroundColor Green " DONE"
    }
 
    if( $language )
    {
        $sol = $sol.LanguagePacks | where-object { $_.LocaleId -eq $language }
 
        if ( $sol.ContainsWebApplicationResource ) {
            Write-Host -ForegroundColor yellow "Deploying to $url" -NoNewline
            Install-SPSolution -Identity $solutionCoreName -GacDeployment -CasPolicies -Language $language -Webapplication $url
        }
        else {
            Write-Host -ForegroundColor yellow "Deploying" -NoNewline
            Install-SPSolution -Identity $solutionCoreName -GacDeployment -CasPolicies -Language $language
        }
    }
    else
    {
        if ( $sol.ContainsWebApplicationResource ) {
            Write-Host -ForegroundColor yellow "Deploying to $url" -NoNewline
            Install-SPSolution -Identity $solutionName -GacDeployment -CasPolicies -Webapplication $url
        }
        else {
            Write-Host -ForegroundColor yellow "Deploying" -NoNewline
            Install-SPSolution -Identity $solutionName -GacDeployment -CasPolicies
        }
    }
 
    if( $language)
    {
        $sol = Get-SPSolution $solutionCoreName
        $sol = $sol.LanguagePacks | where-object { $_.LocaleId -eq $language }
    }
    else
    {
        $sol = Get-SPSolution $solutionName
    }
 
    if ($sol.Deployed -eq $false ) {
        $counter = 1
        while( ($sol.JobExists -eq $true ) -and ( $counter -lt $safeguard  ) ) {
            Write-Host -ForegroundColor yellow "." -NoNewline
            sleep $sleeptime
            $counter++
        }
    }
    Write-Host -ForegroundColor Green " DONE"
 
}

The interesting part is to get a reference to the solution language pack. First, get the original solution. It has a LanguagePacks property that returns the list of language packages associated with this solution. I want to have a reference to my language pack:

$sol = Get-SPSolution $solutionCoreName -ErrorAction SilentlyContinue
$sol = $sol.LanguagePacks | where-object { $_.LocaleId -eq $language }

If $sol is not null, I know the solution language pack is present in the farm. If it is null then I can add it and deploy it.

Similar lines of code are for the remove and update scenario’s. I have all script files zipped and it can be downloaded here.

Originally posted at http://blog.octavie.nl/index.php/2012/01/27/deploying-solutions-with-language-packs-with-powershell/