Sunday, May 30, 2010

Assembly stuck in memory despite being replaced

I had a wonderful time this weekend trying to find out why is it that when I deployed a new version of my solution - one that included more debugging information than the previous one, nothing would come out - it would still print out the old data.
I went as far as to remove the solution entirely, make sure the GAC is clear from the assembly and then manually drag and drop my new assembly (thinking it is my WSP that is stuck with an old assembly) and still I get the old code running instead of the new one.
What didnt I do? I tried IISreset and all sort of tricks, but I could not reboot since it was not my server (partner company asking me to help out with some dev work on their server).
It turns out that if I could reboot it would have saved me all the time I spent - but then I would not have figured out the reason that was happening!

Curious? Well, here it is - I had a windows application running that used sharepoint object model to triger the timer job I was trying to redeploy. The windows application did not have a reference to the timer job code - it just used the OM to query the server what timer jobs are there and then let me choose one and execute it. So I never suspected it was the culprit - especsially since I used it to confirm the timer job was deleted after I removed the old solution.
But it was.
For some reason, just having it running, connected to sharepoint objects, somehow caused the old assembly to remain in memory\cache (I will not pretend to know why or how) and once I closed it I suddenly got the new code running!

There - if I saved someone the same frantic research I was doing this weekend, I am a happy man.

1 comment:

Ravi said...

Hi Sagi,

I guess OwsTimer will cache the assembly,
instead of iisreset, you could have tried resetting sharepoint timer windows service

i also had similar issue :)