Partager via

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

  • Article

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 (https://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.

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

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    October 23, 2013
    Hi Steve, Thanks for such an informative series on custom claims provider. I've few queries regarding this.
  1. Is there any way to remove our custom claims provider when we deactivate the feature?
  2. Is there any way we can use claim values while setting up "target audience"?
  3. We need to test diff scenarios: checking the site behavior when   a. user is associated with claim1, claim2.   b. user is associated with claim3, claim4. claim5. This mapping of claims to user id is done in backend. Right now what I'm observing is that, after iisreset when user logs in for the first time; our claims provider gets executed and ,say, Claim1 and Claim2 get added; Now user signs out of SP UI; closes the browser window; Updates claims associated with user in backend; and accesses the URL of the site in new browser window. This time our claims provider doesn't get executed and user ID continues to have claim1 and claim2 associated with it. Did you face such issue? how do we test different scenarios.
  • Anonymous
    September 18, 2014
    The comment has been removed