Share-n-dipity

SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

Packaging A SharePoint 2010 Custom Claims Provider in a Visual Studio 2010 SharePoint Project

Packaging A SharePoint 2010 Custom Claims Provider in a Visual Studio 2010 SharePoint Project

  • Comments 3
  • Likes

For those of you who have been developing solutions for SharePoint 2010 with Visual Studio 2010, you may have noticed a slight packaging peculiarity when it comes to custom claims providers.  In Visual Studio 2010 you can create a new feature and you can easily add a feature event receiver to it by just right-clicking on the feature and selecting the Add Event Receiver menu.  That’s nice because it’s very easy and productive to get working on the coding for your solution rather than the configuration.  The disconnect comes in because the event receiver it adds by default inherits from SPFeatureReceiver.  As I’m sure you all know, the event receiver used to register a custom claims provider must inherit from SPClaimProviderFeatureReceiver (http://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx).  In addition, the built in SharePoint smarts in Visual Studio don’t lend itself to a really intuitive way to just add a class to a SharePoint 2010 project and then have it associated with a feature.  There is however a fairly easy and slick way around this.

I went down this path a while ago when I was beginning with my usual starting point – I had a custom claims provider I had written and corresponding feature receiver to install it.  These two classes were part of a single project.  I decided that I really wanted to make the new feature packaging goo in Visual Studio 2010 work for me, so here’s how I did it.

1.       Complete your first run at your custom claim provider project and corresponding event receiver for registration, then compile it.  You want to look at the compiled assembly and get the strong name for the assembly as well as the class name for the event receiver.

2.       Add a new project to your solution, and base it on a SharePoint 2010 “Empty SharePoint Project” template.  Configure the project to be deployed as a farm solution.

3.       Right click on the Features node in the project and select Add Feature.  Your feature should be scoped to Farm and should auto activate.  Otherwise, configure the feature properties as appropriate for what you are trying to do.  Here is the important point – configure these two properties on the feature (in the Visual Studio Properties window) as described:

a.       Receiver Assembly:  put in the strong name to your assembly described in step #1, for example MyClaimProvider.ClaimTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=edb00fee02fa0701

b.      Receiver Class:  put in the name of the class that you wrote your custom claims provider in step #1, for example MyClaimProvider.ClaimTest.MyClaimsFeatureReceiver

4.       Add your compiled custom claims provider assembly to the list of assemblies your packaging solution is going to deploy.  To do this, double-click on the Package.package node in the Visual Studio packaging project.  Click on the Advanced tab.  Click on the Add button, then the Add Existing Assembly menu.  Find the correct location for your compiled custom claims provider assembly, and leave the Deployment Target: GlobalAssemblyCache selected (it is by default).  Click the OK button to save your changes and then you can close the Package properties window.  One thing to note here – I usually just create a folder in my packaging project where I copy my compiled assemblies from other projects that I want to be distributed with the solution.  When I configure the additional assemblies in the Package, I just select from the folder in my packaging project.  In my other projects, I have a post-build script that automatically copies the compiled assembly into this assembly folder in my packaging project.  It’s a simple one line of code post-build that copies the assembly whether it’s a debug or release build so I don’t need to remember to do it myself each time.  It looks like this: 

copy "$(TargetPath)" ..\..\..\MyPackagingProject\GacFiles /Y

Your package is now complete.  You just need to compile the package project and then select the Package menu from the right-click menu for the project.  You’ll end up with a WSP file that you can then distribute and have it automatically roll out your custom claims provider.

Attachment: Packaging A SharePoint 2010 Custom Claims Provider in a Visual Studio 2010 SharePoint Project.docx
Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment