I have implemented a custom SPClaimProvider that is doing claims augmentation in the FillClaimsForEntity method. I have packaged this as a SharePoint feature and deploy it in a WSP.

I am trying to uninstall the existing version and add a new version of the same assembly. After I uninstall the existing version, the token service is still looking for the old assembly.

At first, the problem was that the feature was missing. I then used the Feature Admin Tool to find the faulty feature and remove it.

Faulty Feature found! Id: '12345678-1234-1234-123456789012 Found in Scope:Web, http://vm-sps-5e. Should it be removed from the farm?

Farm - Removing Feature '12345678-1234-1234-123456789012, Scope: Web' from the Farm.

WebApp - Removing Feature '12345678-1234-1234-123456789012' from Web Application: 'SharePoint - vm-sps-5e'.

SiteColl - 1 Web Scoped Features removed in the SiteCollection http://vm-sps-5e. 1 sites/subsites were scanned.

This removed the feature, but a reference to the old assembly still exists somewhere.

Edit: A more detailed stack trace

SPSecurityTokenService.Issue() failed: System.IO.FileNotFoundException: Could not load file or assembly 'ClaimsAssembly, Version=, Culture=neutral, PublicKeyToken=0123456789012345' or one of its dependencies. The system cannot find the file specified. File name: 'ClaimsAssembly, Version=, Culture=neutral, PublicKeyToken=0123456789012345' at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String assemblyString) at Microsoft.SharePoint.Administration.Claims.SPClaimProviderDefinition.GetClaimProviderType(String assemblyName, String typeName) at Microsoft.SharePoint.Administration.Claims.SPClaimProviderDefinition.get_ClaimProviderType() at Microsoft.SharePoint.Administration.Claims.SPClaimProviderDefinition.CreateClaimProvider() at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.get_EnabledClaimProvidersByName() at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetEnabledClaimProviders(SPClaimProviderOperationOptions mode) at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetClaimProviders(SPWebApplication webApplication, Nullable 1 zone, SPClaimProviderOperationOptions mode) at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetClaimProvidersForContext(Uri context, SPClaimProviderOperationOptions mode, IEnumerable`1 providerNames) at Microsoft.SharePoint.Administration.Claims.SPClaimProviderOperations.ClaimsForEntity(Uri context, SPClaimProviderOperationOptions mode, String[] providerNames, SPClaim entity) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.AugmentClaimsIdentity(IClaimsIdentity identity, SPClaim identityClaim, RequestSecurityToken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.GetOutputClaimsIdentity(IClaimsPrincipal principal, RequestSecurityToken request, Scope scope) at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityToken request) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenService.Issue(IClaimsPrincipal principal, RequestSecurityToken request) WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].


The command Get-SPClaimProvider displayed that the custom claim provider was configured in the list of all claims providers - finally... found it.

I tried to remove it using: Remove-SPClaimProvider -Identity ClaimsAssembly.CustomSPClaimProvider

Could not load file or assembly 'ClaimsAssembly, Version=, Culture=neutral, PublicKeyToken=0123456789012345' or one of its dependencies. The system cannot find the file specified.

Above all, once there is an error in the token service itself, it is very hard for SharePoint to do anything at all.


I assume that Version= is the 'old' version?

If so I'd suggest dropping that assembly version back into the GAC, removing the custom claim provider, then deploying the new version and creating an new SPClaimsProvider.

Probably a bit safer than editing the config db directly.

Essentially, remove all the old stuff before trying to upgrade them.

| improve this answer | |
  • This is the better answer. (As long as you still have the old assembly, or have the key to recreate it.) – umbyersw Mar 11 '12 at 4:28
  • 1
    The key to avoiding this issue from ever occurring is that the call to Uninstall-SPSolution must be preceded by a call to Remove-SPClaimProvider. – umbyersw Oct 10 '12 at 23:02
  • I remove the old provider, deployed the new version and created a new SPClaimsProvider and I am still get the error. Any suggests or ideas? – Kyle Johnson Jun 10 '15 at 19:23
  • Ok. This is strange. I made a change to the security token web.config and now it seems to not be throwing the error anymore. – Kyle Johnson Jun 10 '15 at 19:30

You need to edit the SharePoint configuration database manually to remove the custom Claims Provider.

Warning: This is probably not a good idea, but it did work for me and I didn't see any other option.

Locate the target configuration element using the query:

SELECT  [Id],[ClassId],[ParentId],[Name],[Status],[Version],[Properties]
,CONVERT(xml, [Properties]) AS PropertiesXml -- for convenience: clickable view
FROM [SharePoint_Config].[dbo].[Objects]
WHERE Name = 'ClaimProviderManager'

Copy the value of [Properties] into a text editor and remove the XML portion referring to the missing Claims Provider. In other words, delete the entire <fld /> tag around the data that you want to remove.

Copy the edited value back into a new query like this (also, copy the Id from the original query to match):

UPDATE [SharePoint_Config].[dbo].[Objects]
SET Properties = 'PASTE_XML_HERE'
WHERE Name = 'ClaimProviderManager'

Run this query.

| improve this answer | |
  • 1
  • 1
    When nothing else worked, this solution worked perfectly. – udog Sep 11 '14 at 22:04
  • I wouldn't do this on a PROD server indeed, however on my test VM this is the only solution that worked. – Matthieu Nov 3 '15 at 10:29

Use the following power shell command:

  1. Check if your assembly really there using:

    Get-SPClaimProvider -Identity "Your Claim Provide Name"

  2. If you see your provider then use:

    Remove=SPClaimProvider -Identity "Your Claim Provider Name"

| improve this answer | |
  • This is how you would normally accomplish this task. Unfortunately, this question is about the situation where the steps you are describing do not work. The claims provider is visible, and Remove-SPClaimProvider throws an exception. – umbyersw Aug 21 '14 at 21:17

As long as the process the Assembly is used by is not restarted, that process will keep using the old "in memory" version of the assembly. Perform an iisreset to force a reload of your assemblies, same goes for the SharePoint Timer Service etc.

Temporary (ASP).NET assemblies are stored in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files, clearing out that folder forces .NET to recompile all need DLL's from the GAC / codebehinds / satellite assemblies to. You can safely delete anything in there.

| improve this answer | |
  • Thanks for your answer - I deleted the temp files and and I'm still getting the error. :( – umbyersw Mar 9 '12 at 22:01
  • Did you do an iisreset as well? and restarted the sharepoint services? On every machine in the farm? Did you try a reboot? – Colin Mar 9 '12 at 22:24
  • This is a one-server farm, a development box. It was rebooted, and the error remains. It must be originating from configuration in the database perhaps? I've searched for the reference in .config's and it is not present anywhere that I can find. – umbyersw Mar 9 '12 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.