After that, the website launches the cached dll

Question

The situation is that I made a small bug fix for the class, so they just want to deploy the damaged dll. They stopped IIS, replaced the dll in the / bin folder of the iis directory for the website with the new one I gave them, and started iis again. There are several servers, but they just changed it to one to try. They still see the same error in the event log of the corresponding server. Looking at the stack trace, I can say that it launches the old dll.

They checked the GAC and do not see it there.

I checked the dll with a reflector to verify that I gave them the correct new dll.

This is the asp.net 2.0 website and the server is 2003. I am not sure how it was initially deployed, 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. Can he use one of them or build an old one or even just cache it in memory?

Answer 1

Name your temporary contents of the asp.net folder. I don’t know why the update was not automatically compiled.

Answer 2

We had the same problem, but with minor complications, we have many sites, so "cleaning up all the pace" and restarting IIS is not a good option for us. Therefore, we needed to be more selective in what was forced to update.

On our QA machine, under ... "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files" I tried searching for a file for the partial file name of what we are trying to release. The file was found in the folder like this: C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET files \ root \ 4503212x \ ad95664x, so I stopped the application pool, deleted the folder, restarted and everything turned around then - fine!

But ... We had the same problems with deployment to production, and there was no higher.

In short, the QA application pool was set to "enable 32-bit truth", but it was set to "False" for production, so the prod temp files were in: "C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319" instead of (\ Framework64 \ instead of \ Framework \).

If cleaning up temporary files does not work, double-check your frameworks or look for update files at the folder level C: \ Windows \ Microsoft.NET and below. You may be surprised.

Answer 3

You do not need to stop IIS to deploy your update, you just copy it.

In addition, if they copied only the DLL, but your patch was in the .aspx file, then it will not be displayed. You really have to complete the full deployment.