Erwin van der Valk's blog: Practicing patterns : Sharepoint

Sharepoint guidance v2 – drop 9

erwinvandervalk — Wed, 13 May 2009 19:16:53 GMT

This week, we published the results of interation 9 to our codeplex site.

You can get it here:

http://spg.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27299

In this drop, we have addressed a number of tasks:

Implemented trusted facade pattern and removed the fake SSO provider
Refactored the repositories to make better use of WCF Proxies
Support for UpdatePanel in SafeScriptManager
Updated PartnerLandingPage
Removed most usages of .net 3.5
Provided instructions on how to use a host name to access extranet site

Trusted facade pattern

We are demonstrating in our RI how to call back-end services from SharePoint. It’s quite common to have different credentials to log on to back end services.

Replacing the fake SSO provider

Before, we were using a fake SSO provider (Single Sign On) for that. We built a fake SSO provider because it’s actually quite hard and complex to build a real SSO provider. Since the SSO provider should store passwords in a secure way, there are a whole range of attacks you need to watch for. We felt we didn’t want to take on that extra complexity in our project, so we built a fake SSO provider that stored the passwords in clear text. We hoped that calling it ‘fake’ would make it clear enough that this is not something you would want to do in production.

We a lot of feedback that giving an example that shows how to store passwords in clear text is bad. No matter how clearly you explain that it’s not something you want to do in production, somebody is going to do it anyway. But since didn’t want to show you how to build a real SSO provider (that would be a project in itself), we decided to change our implementation to a trusted facade.

Trusted facade explained

The following diagram shows the trusted facade pattern:

A user authenticates with the trusted facade. It validates the credentials provided by the user. Then, if the trusted facade calls the back end service on behalf of the user, it only specifies the username. The back end service trusts the Trusted Facade to provide the correct username, so it doesn’t need to perform any authentication.

We implemented our trusted facade based on this MSDN article. Our implementation looks like this:

A user connects to SharePoint either through windows authentication or through Forms Based Authentication (FBA). Then, when the user wants to make a request to a backend system, for example to retrieve the price for a product, the pricing repository will find out what partner the user belongs to. It will then call the back end service with the name of the partner. The pricing service trusts our SharePoint application to provide the correct partner name, so it doesn’t require any passwords.

Of course, you have to make sure that only the account that SharePoint runs under is allowed to access the pricing service.

Repository refactoring

We took a critical look at our current implementation of the repositories.

The goal of the repositories is to hide data access logic from consumers. For example, we have a ProductCatalogRepository, which has methods like: GetProduct(string sku) to retrieve product information. This repository uses the BDC for some of it’s methods, but for other, it calls into our productcatalog webservices directly. However, the consumers of these repositories don’t know where the data comes from. They also don’t know (and don’t care) that the data is cached.

Webservice proxies

Adding a reference to a webservice is very simple in Visual Studio. What happens under the covers is quite a bit more complex. Visual studio will generate proxy classes based on the metadata that’s returned from the service.

We implemented the following best practices for calling web services:

If your service references are used by multiple projects, create a single project that holds the service references and reference that project.
There are to reasons for this. If you are making changes to your webservice, you only have to update one service reference. Forgetting to update one can cause annoying bugs. But from a design perspective, if you generate two proxies for the same web service, then you’ll have duplicate (incompatible) types in your system. For example, the price object generated for proxy 1 will be different from the price object generated for proxy 2. Even though they have exactly the same signature, you can’t reuse the types for them or reuse methods that work on them. We implemented this in the Contoso.Pss.Services.Client solution.
Don’t call the service proxies directly, but wrap the calls to the service proxies into repositories or service agents.
This best practice is used to shield your application from (minor) changes to the service. It does take some extra coding, because you have to transform the objects you get back from the service into objects that can be used by your application. So this practice does adds a level of indirection and extra complexity to your application, so you have to make the tradeoff if the extra complexity is worth the isolation. In general, if the services are created for and only used by your application, you typically don’t need such a level of indirection. However, if you don’t have control over your services or other clients are also using the services, it’s often worth it.

There were a couple of area’s we explicitly didn’t look at.

Getting the repositories from the service locator

Before, we were creating the repositories directly in our code, for example in our presenters. This is often undesirable, because it makes the presenters harder to unit test. Now, we have registered the repositories in our service locator. Therefore, we can use the service locator to get instances of our repositories and we are able to mock out these in our unit tests. Sweet :)

UpdatePanel in sharepoint

SharePoint has a slightly different method for implementing post backs than the normal ASP.Net framework. It uses a custom javascript method that is called on postback. Unfortunately, this means that the Ajax UpdatePanel doesn’t work out of the box, because it also requires a different postback method. The solution is to emit some JavaScript code that intercepts the postback event and calls the normal UpdatePanel posback code.

In order to get the UpdatePanel to work, you need a scriptmanager, because that will add the required javascript code for the async postback to the page. We had already built a SafeScriptManager, that you can add several times to a page without causing issues. So it was natural to add some functionality to it to enable support for the UpdatePanel.

Removed most .net 3.5 usages

We were making judicious use of the wonderful new features of .Net 3.5 such as Linq queries, lambda expressions and type initializers. However, we got the feedback from our advisors that .net 3.5 is not widely used by the sharepoint developer community. After many discussions, we agreed that removing most of the .net 3.5 usages would make our guidance a bit more consumable by the sharepoint developer community.

Added instructions on how to use a host name to access extranet site

Lastly, we added some instructions on how to use a host name to access extranet sites. Now, our extranet site is accessable on localhost:9001. If you would prefer to host the extranet site on a hostname, for example extranet.mydomain.com, we have included instructions on how to do that.

sharepoint guidance drop 8 video online

erwinvandervalk — Thu, 30 Apr 2009 20:08:29 GMT

Hi guys,

Our drop 8 video is online on Channel 9. Check it out:

Happy watching and keep practicing!

_Erwin

program to interface… in sharepoint

erwinvandervalk — Fri, 10 Apr 2009 21:29:00 GMT

[Update]

I’ve posted a workaround to this issue here: http://blogs.msdn.com/erwinvandervalk/archive/2009/06/08/using-interfaces-and-base-classes-in-different-assembly-using-vsewss-1-3.aspx.

[Original post]

One of the common practices I try to follow is: Program to interface, not implementation.

It allows you to decouple components from each other and easily plug in different implementation. This is great for test driven development, where you can replace all the dependencies of the object under test with Mock objects.

But when I tried to do something similar in our Sharepoint Guidance project, I ran into a problem with the Visual Studio Extensions for Windows Sharepoint Services (VSSeWSS) 1.3.

The problem

I had created two assemblies, one with an interface definition and the other with the actual implementation. Seems pretty basic, but when I tried to use it to create a WSP package, I got the following error:

Error 1 VSeWSS Service Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Log file written to: C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log 0 0

Ok, maybe the log file explains what’s wrong?

2009/04/10 11:13:59    Error
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
   at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
   at System.Reflection.Module.GetTypes()
   at Microsoft.SharePoint.Tools.Reflection.ModuleWrapper.GetTypes()
   at Microsoft.SharePoint.Tools.Reflection.TypeFinder.GetTypesAsType(IAssemblyWrapper assembly, ITypeWrapper targetType)
   at Microsoft.SharePoint.Tools.Reflection.TypeFinder.Find(IAssemblyWrapper assembly, ITypeWrapper targetType)
   at Microsoft.SharePoint.Tools.SharePointProxies.WSPViewFacade.CreateWebPartReferenceResolverClassMap(String[] paths)
   at VSeWSS.Server.Services.SPService.CreateWebPartReferenceResolverClassMap(String[] paths)

How incredibly useful.

The solution

After a lot of puzzling, I found out that the VSSeWSS 1.3 tool has problems with separating the implementation and interfaces in seperate DLL’s. Even if you reference the DLL’s, but not add project references, it gives the previous error message when packaging it.

However, i found if you set ‘copy local’ to False in the assembly references, the problem goes away. Of course, it does create another problem. How do you get the dll’s on sharepoint.

The solution I’m going to take is: Create a feature that puts the DLL’s on the server. Create another feature that wants to use the dll’s, but has ‘copy local’ to false. I know, it’s not pretty, but it works.

Hope this helps,

_Erwin

p&p Sharepoint guidance v2

erwinvandervalk — Fri, 20 Mar 2009 06:30:20 GMT

Since the Prism project is done, I’ll be working on a different project for the next couple of months.

Sharepoint guidance on Codeplex

The goal of this project is to provide guidance on how to build Sharepoint applications in a professional way.

Version 1 of Sharepoint Guidance

V1 of the Sharepoint guidance project focused mainly around the following aspects:

How to work with development, testing and production environments.
How to build sharepoint solutions in a Test Driven fashion.
How to set up a Continious Integration environment, that does our Builds, and runs our Unit and Acceptance Tests
How to build Sharepoint applications that can be versioned.

To do this, we’ve built a reference implementation that demonstrates all of these concepts.

Version 2 of Sharepoint Guidance

We are now well on our way with the Sharepoint Guidance and are already in iteration 6 (we have two week interations).

In V2, we have the following goals:

How to design and build content driven applications
- How to develop an application that allows a mixture of development activities and authoring.
- How to create composite
How to extend existing LOB systems:
- How to integrate LOB systems in a secure way using Single Sign-On (SSO)
- How to manage connectivity with LOB systems and databases by using the Business Data Catalog (BDC) and call Windows Communication Foundation (WCF) from Sharepoint.

Sharepoint Guidance V2 – Drop 5

Last Friday, we’ve released drop 5 to codeplex. You can download it from here:

http://spg.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=24674

The most important things we have addressed in this drop are:

How to implement global navigation, across different site collections.
How to implement custom navigation.
How to add Silverlight controls to your site.

Francis cheung and I have created a webcast that guides you trough some of the things we did in drop 5:

Global navigation

In our reference implementation, we’re demonstrating how to create consistent navigation across different sites and site collections. It’s very simple to create a sitemap for a single site, by creating a sitemap.xml and using the asp.net sitemap control to create the sitemap and add it to your site. However, creating a sitemap that’s shared between all sites is a bit harder.

The structure of our reference implementation is as follows:

We have a sitecollection for our intranet site, a sitecollection for our extranet site and a sitecollection for partner specific sites. Partners who log on to their homepage, will likely navigate between pages on their site and pages on the extranet home, for example to view products or promotions.

We want the global navigation structure to look somewhat like this:

The partner should be able to seamlessly navigate between each part of our Sharepoint site. Of course, we only want to have the structure of our site stored and versioned in one place. So to create a consistent story across multiple pages, we have taken the following steps:

Created a Sharepoint deployment project to create a feature that will apply a masterpage (with the website’s branding). This masterpage also contains a sitemap control that points to the SPXmlContentMapProvider:
```
<asp:SiteMapDataSource ShowStartingNode="false" 
    StartingNodeUrl="/pssportalroot" SiteMapProvider="SPXmlContentMapProvider" 
    ID="contosoPssSiteMap" runat="server" />
```

Create a Sitemap xml file that will be placed 12 hyve. To do that, you have to put it in the folder Templates\Layouts folder.

The sitemap xml looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap>
  <siteMapNode title="" url="/pssportalroot">
    <siteMapNode title="Partner Home" url="/_layouts/contoso/partnerredirect.aspx?page=Home">
      <siteMapNode title="Manage Incidents" url="/_layouts/contoso/partnerredirect.aspx?page=incidents" />
    </siteMapNode>
    <siteMapNode title="Product Catalog" url="/sites/pssportal/productcatalog/category.aspx?categoryid=0"/>
    <siteMapNode title="Promotions" url="/sites/pssportal/promotions" />
    <siteMapNode title="Search" url="/sites/pssportal/search" />
  </siteMapNode>
</siteMap>

Create a featurereceiver to merge the sitemap xml fragment into sharepoints global sitemap. To do that, call the following method in the FeatureActivated method of the FeatureReceiver:
```
web.Site.WebApplication.Farm.Services.GetValue<SPWebService>()
    .ApplyApplicationContentToLocalServer();
```

Custom sitemapprovider

We are also demonstrating how fill a sitemappath control with custom data and we are using the business data catalog for that.

In our scenario, the business data catalog provides a list of categories and products (which it gets from WCF webservices in a different system). It then uses this data to create category and product pages to display the individual catalogs and products.

We’ve created a custom sitemap provider that will retrieve the categories and url’s to the category pages from the BDC. We then tie a normal asp.net sitemappath control to that sitemap provider to display a ‘crumb’ path that displays sitemap information.

Silverlight Controls

In our reference implementation, we are also demonstrating how to add silverlight controls to your site. To a ‘normal’ asp.net webapplication, adding silverlight controls is really easy, because the IDE takes a lot of things out of your hands. In Sharepoint, unfortunately that’s not as easy. So if you want to use the Serverside Silverlight controls (in System.Web.Silverlight, from the Silverlight SDK), you will also need to have Asp.net Ajax support in your site. This means: Adding the required entries to the web.config and adding a scriptmanager control to your page.

Web.config changes

There are basically two ways to make changes to the web.config of a sharepoint server. Programmatically, through the API or declaratively, in a XML file. Since there are quite a few changes you have to make to your web.config, we figured the declarative approach works best. Again, you have to call ApplyApplicationContentToLocalServer() to merge the declarative changes into the web.config. I’ll write a later blogpost or do a webcast on how to do this in more detail. But if you are interested, you can always look at our drop.

SafeScriptManager

The scriptmanager proved to be an issue. You can only have 1 scriptmanager on your page and it must appear before any controls that need it. Normally, you would add a scriptmanager to your masterpage and be done with it. However, sharepoint is quite dynamic with it’s masterpages. You can easily create a new masterpage and use it as the default masterpage for some group of pages. So this means that if you use ajax in some of your webparts, you can no longer use those webparts on pages that don’t have a scriptmanager.

So we’ve created a control called the SafeScriptManager. You can safely add it to any controls or webpart that needs a scriptmanager. It will check if a scriptmanager is already present.

Conclusion

I hope this clarifies a bit what we have done in this drop. I plan on doing a blog post and a webcast for each drop from now on. As always, any feedback (on the post, on the drop or on the weather) are welcome :)

Happy coding!