0

We are developing a custom claims provider. In order to aid in debugging I write to a log file. I have little experience with SharePoint but I found and follow several different guides. Essentially, I create a WSP (with a Farm-level feature) and deploy it with PowerShell:

Add-SPSolution C:\temp\OurCCP.wsp
Install-SPSolution OurCCP.wsp -GACDeployment

And when I test it and spot issues, I make changes. I thus need to retract the solution.

Uninstall-SPSolution OurCCP.wsp
Remove-SPSolution OurCCP.wsp

Then I redeploy as above, except sometimes I change the log information and even the log filename itself.

All of this goes off without errors being thrown; however, when I redeploy I notice that multiple logs are being written to and that old log messages are being written. It appears there are ghost versions of our claims provider which cannot be eliminated. How can this be rectified?

Improve this question
4
  • Have you tried stopping and restarting the SharePoint Timer Windows Service to see if the behavior stops?
    – Erik Perez
    Commented Feb 2, 2015 at 17:44
  • I haven't as I am not the box admin. While I'm not familiar with those services I'm not understanding their connection to my issue.
    – M. Lanza
    Commented Feb 2, 2015 at 17:49
  • 1
    The SharePoint Timer Windows Service (SPTimerV4) may be holding a copy of your DLL in memory and you need to flush it by restarting that Windows service. This is where I have seen this behavior in the past building various custom solutions.
    – Erik Perez
    Commented Feb 2, 2015 at 17:58
  • So far it looks like it worked, Thanks. I'll note otherwise if that changes.
    – M. Lanza
    Commented Feb 2, 2015 at 18:11

1 Answer 1

Reset to default
2

The SharePoint Timer Windows Service (SPTimerV4) may be holding a copy of your DLL in memory and you need to flush it by restarting that Windows service.

Improve this answer
7
  • Unfortunately, I'm still seeing the old logs making me wonder about this post: blogs.msdn.com/b/kaevans/archive/2011/02/02/…
    – M. Lanza
    Commented Feb 2, 2015 at 18:37
  • 1
    I don't think the STS application pool gets recycled on solution deployments and it's the one responsible for running most of the claims provider code. Try running IISRESET after the solution deployment finishes
    – Choggo
    Commented Feb 2, 2015 at 18:50
  • I did try that, but doesn't a WSP have an IISRESET built into it as a package option?
    – M. Lanza
    Commented Feb 2, 2015 at 19:03
  • SharePoint recycles the Application pool (so it's not the same as an IISRESET) where you are deploying to. STS has its separate web application and pool and I'm not sure it gets recycled.
    – Choggo
    Commented Feb 2, 2015 at 19:20
  • 1
    You meant the Checkbox inside Visual Studio that says Reset Server huh? Are you currently using it? I don't have the habit of using it so I don't know how flaky it is/isn't - It is promising, if my guess regarding the STS pool is right.
    – Choggo
    Commented Feb 2, 2015 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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