Developing solutions and features for SharePoint is a nightmare for all beginners, and even for the experienced SharePoint developers. If you ever have had the opportunity to create a SharePoint solution you most probably have had to make a lot of hacking in a bunch of XML files, just to build a simple feature. This is the way you have to do it, and the way taught by tutors and Microsoft, when using it with Visual Studio and no add-ins. This is the way it was, and has been, for most of us SharePoint programmers since the beta releases of SharePoint version 3.
Nowadays you have several tools that help you out; such as Visual Studio Extensions for WSS, WSPBuilder, STSDev and more. Some have a user interface that helps you a lot; such as VSeWSS and SPVisualDev and some does not help much there; such as STSDev. But whatever tool you use you will find that you are digging yourself deep into hacking those Xml files. Unfortunately the documentation is quite poor, but we have the fantastic SharePoint bloggers and MVPs that made their code and samples available through
Lots of XML
For example when you have a site and you would like to create a custom list, you will have to define a Content Type, a list schema, a list template and a list instance and then you have a feature manifest and a solution manifest - that counts to at least five different XML files and a few different schemas. This is an awful amount of job in the beginning and I think in some cases it's a waste of time, especially if it's a custom list that only will be used once. Then we have the thing when we want to update the list or content type when it's deployed...a whole lotta XML in combination with compiled code (for example when updating Content Types)!
The API Way
Almost everything that these XML files can do can be done using compiled .NET code and utilizing the SharePoint API's. Take the example above - those XML files can be replaced with a few lines of C# code. Create a Content Type, create a List, add a Content Type to the List. There are still few XML files left; the feature and solution manifests; but those two are easy to handle.
All you have to do is put this initialization and creation code in the Feature Receivers of the Features.
Upgrading and developing these features using the API way are also very easy and straightforward. I think it also fits better into a TDD kind of development way. If you have a list that is created through the Feature Receiver and you find that you need to add a field to that list, I just de-activates and activates that feature. This is done by a set of extension I use to create fields if they don't exist, in Lists or Content Types.
API way - Pros
Using the API way has several benefits:
- As a beginner, but experienced .NET developer, it might be easier to start working with the SharePoint API
- Mistakes are easier discovered:
- You have to deploy and test your feature to find small mistakes in the XML
- Some errors are detected during compilation phases
- Debugging - yea try that with XML based features!
- Upgrading experience is far much better (de-activate and activate)
- Development time is most often faster, just re-register the assembly
- Easy to staple the feature, and it's receiver, to Site Defintions
- Testing, and TDD, is possible even outside of the SharePoint scope
API way - Cons
Of course there are cons of using the API way. First of all there are some things that you can't do
- Create List Templates - for reusable lists, i.e. lists available for the end-user to create
- Create Site Definitions
- Create Custom Actions
- Configure Delegate Controls
The cons with the API way are for example:
- Requires installation of assemblies in the GAC
- This is in many installations prohibited due to the fact that it requires that you run in full trust.
- I find it easier in some situations to re-use configurations created in XML files
- When using XML definitions you can specify ID's of Content Types etc which are required in many situations, for example when you are re-using your Content Type in many farms or Site Collections.
- Requires that you really understand how the provisioning works in SharePoint
- Requires that you take care of the clean-up when deactivating
Most pros and cons are of course a personal consideration, but as I said, I almost every time nowadays use the API way for my features.
How do you develop your Features, Lists and Content Types?
Basically I try to have a clean and simple Site Definition and then staple my features and it's receivers onto that Site Definition. It comes down to very little XML and some compiled code - very maintainable.
Finally I’ve found the time to make the last work on ChartPart 2.0 for SharePoint. I have been working on and off on this release for quite some time – but now it’s here!
ChartPart 2.0 for SharePoint is a Web Part that allows you to instantly create charts based on your existing SharePoint lists. You can make columns, bars, pies and even 3D charts.
ChartPart version 1.0 was released last year and have had up until now close to 10.000 downloads, which I’m very proud of. I’ve received awesome feedback on the Codeplex site, on Twitter, my blog and when I met people and told them that I was the one who made it.
ChartPart 2.0 has been in beta/RC for quite some time and has had about 4.000 downloads, which also is awesome! People have been asking me when is it due, when is it ready…and now it’s done! It’s uploaded and free to download. You can even get the source and make your own implementation.
ChartPart 2.0 contains a number of new features such as; better 3D charts, more customization etc. But the most interesting two things are 1) you don’t have to install it in the GAC (which several people asked med about) and 2) you can connect the ChartPart to a list view and filter the graph.
For a full list of features just head on over to the ChartPart 2.0 website on Codeplex.
Another interesting feature that is new in 2.0 is that you can edit the .webpart files and set a Lock Down Mode. This allows you to restrict your users from editing certain properties, such as colors, graph types etc. This is one feature that I hope can make the ChartPart 2.0 be used in larger companies.
I’d like to thank all the thousands of people who has helped me out by downloading ChartPart 1.0 and those who has submitted issues on Codeplex. A special thanks to those who helped me with the translation into other languages; Arash Aghajani, Frank, Alexander Bautz, Anders Dissing..
What are you waiting for, go download it…
Last night we had a SharePoint User Group Meeting here in Stockholm, Sweden. It was a great evening with a lot of attendees, thank you all for showing up. It's always fun to see new and old faces, sorry I didn't have time to talk so much with you (due to my VM's crashing just before my demos…).
First, a big thanks to KnowIT and Jonas who provided us with a great place to host the meeting and some good food and beer!
Niklas Goude started the meeting with some SharePoint and PowerShell love. Great session and demo. Really looking forward to see his, and Mattias Karlssons, book project come to life. You can find Niklas awesome PowerShell scripts here and Mattias automagic create your farm in Excel script here.
The second session was held by yours truly, and I did a brief introduction to PerformancePoint 2007 with some demos on how to create dashboards and publish it to SharePoint. I'm thinking about writing up a post on the last "Dangerous Lists" demo, would you like that? You can find my presentation here. And here are the links that I referred to regarding PerformancePoint 2007 and Microsoft BI.
And if you would like to know some more on what will happen with PerformancePoint in the upcoming 2010 release, please attend the SharePoint & Exchange Forum 2009 and my session on PerformancePoint Services 2010, that will take place in Stockholm in November.
The latest version, 4.0, of the great SharePoint Administration Toolkit has been released, read all about it in the post by the SharePoint Team. It contains a lot of interesting and great stuff that you could use for everyday usage.
One new part of the Administration Toolkit is a SharePoint solution called Permission Reporting Solution. This is a solution package that hugely improves the permissions management of your Site Collections and Sites in SharePoint.
The Administration Toolkit was first released about a week ago. It was quickly pulled back, since it contained some erroneous files. It's not currently available from the download site but these links will get you to it; x86 and x64.
Note: I actually started out writing this post while trying to install the permissions reporting solution but eventually found out that the DLL that was released was not signed properly and couldn't be installed into the GAC. My guess is that's why they pulled the release back.
Before installing the PermissionReporting solution you have to have upgraded your farm to at least the April 09 Cumulative Update and have a version that is equal or higher than 6504.
After installing the SharePoint Administration Toolkit you have to install the WSP package like this:
stsadm.exe –o addsolution –filename [Full path]PermissionReporting.wsp
stsadm.exe –o deploysolution –name PermissionReporting.wsp –immediate -allowgacdeployment
stsadm.exe –o activatefeature –name PermissionReporting
The PermissionReporting.wsp is normally found in the c:\Program Files\Microsoft\SPAdministrationToolkit\PermissionReporting\ directory.
I also had to run this command to get it working:
stsadm.exe -o copyappbincontent
How to use it
When you go to Site Settings on a site you will normally find three options under Users and Permissions.
After activating the PermissionReporting feature, on the farm, you have a set of new options.
It will also add new functions to lists and list items:
Check Effective Permissions
The Check Effective Permissions is a really nice feature that allows you to check what are the effective permissions for a specific user on a list, list item or a site.
This is how it looks like when I check the effective permissions for a specific user on a document in a document library:
This user is member of the Visitors group and has read permissions but has been given contribute permissions directly on the object. Handy right?
Compare Permission Sets
When you are working out some permissions issues the Compare Permissions Sets feature is great. It's simply a tree view of your lists and sites in which you can see exactly what permissions are set on a site or a list.
Broken Inheritance Report
The Broken Inheritance Report feature is a report job that every 20 minutes creates XML report files of broken sites in the site collection.
The GrpMembership.xml file shows you what groups users are members of, Rights.xml shows you the rights set for your site collection and Permissions.xml shows you where permission inheritance has been broken and what permissions are set on those objects.
All these XML files can be opened in Excel for easier reading.
With SharePoint 2010 around the corner, we can hope that these features are there from start and we don't have to wait for three years before handy features like this appears :-)
Today I stumbled upon Yet Another SharePoint Problem (YASP) with a custom timer job. The custom timer job is supposed to synchronize some user information between site collections (on a WSS 3.0 installation). In some cases the timer job has to add users to site collections. Sounds like a no-brainer, right!
The problem is that we are using this installation as an internet facing site and the external users are stored in AD LDS (Active Directory Lightweight Directory Services, formerly known as ADAM) and our own custom authentication provider.
When the timer job was running it found users in one site collection and could not add them to the other site collections, using EnsureUser(). It just threw an exception and stated that it could not locate the user.
We made sure we had the right privileges, that the timer service was running under correct account etc. Finally we hooked up the debugger and set some breakpoints in our custom authentication provider to see where it failed when it tried to resolve the users. But the Visual Studio debugger never loaded our provider assembly!
Then it struck me; how would the OWSTimer.exe know what assembly our custom authentication provider is located in, in Central Administration you only specify the name/prefix of the forms authentication provider. The definition for the custom authentication provider is only specified in the web.config of our web application.
So we added a configuration file to the OWSTimer.exe, called OWSTimer.exe.config and specified the authentication provider, see below. Then after a restart of the service, everything worked like a charm.
<?xml version="1.0" encoding="utf-8" ?>
<!-- Add providers here -->
Everyday with SharePoint gives you new obstacles…