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?

  • Have you tried stopping and restarting the SharePoint Timer Windows Service to see if the behavior stops? – Erik Perez Feb 2 '15 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. – Mario Feb 2 '15 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 Feb 2 '15 at 17:58
  • So far it looks like it worked, Thanks. I'll note otherwise if that changes. – Mario Feb 2 '15 at 18:11
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.

  • Unfortunately, I'm still seeing the old logs making me wonder about this post: blogs.msdn.com/b/kaevans/archive/2011/02/02/… – Mario Feb 2 '15 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 Feb 2 '15 at 18:50
  • I did try that, but doesn't a WSP have an IISRESET built into it as a package option? – Mario Feb 2 '15 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 Feb 2 '15 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 Feb 2 '15 at 19:35

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.