The situation is I made a minor bug fix to a class, so they want to just deploy the dll affected. They stopped IIS, replaced the dll in the /bin folder of the iis directory for the web site with the new one I gave them, and started iis again. There are multiple servers, but they just changed it on one to try it out. They are still seeing the same error in the eventlog of the server in question. Looking at the stack trace I can tell it is running the old dll.
They've checked the GAC and don't see it there.
I've checked the dll with reflector to verify I gave them the correct new dll.
This is an asp.net 2.0 website and the server is 2003. I'm not sure how it was deployed originally but it has a copy of the old dll in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\NAME_services#################\assembly\dl3###################\ and in D:\xxxx\Sites\NAME\Services\obj\Release. Could it be using one of these or building the old one or even just caching it in memory?
We had same problem but with minor complications, we have many many sites so a "clearing all temp" and restart IIS is not a good option for us. So we needed to be more selective in what to force a refresh on.
On our QA machine, under ... "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files" I did a file explorer search for the partial file name of what we are trying to release. The file was found in a folder something like: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\4503212x\ad95664x, so I stopped app pool, deleted the folder, restarted and all was deployed then - great!
But .... We had same trouble deploying to production and the above did not work.
Long story short, the QA app pool was set to "enable 32 bit true", but production was set to "False" so the prod temp files resided in: "C:\Windows\Microsoft.NET\Framework64\v4.0.30319" instead (\Framework64\ instead of \Framework\ ).
If clearing temp files is not working - double check your frameworks, or look for files to refresh at the C:\Windows\Microsoft.NET folder level and below. you may be surprised.
Nuke your temporary asp.net folder contents. Not sure why the update didn't automatically get compiled, though.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With