13

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?

3Dave
  • 28,657
  • 18
  • 88
  • 151
dwidel
  • 1,264
  • 1
  • 12
  • 22

4 Answers4

13

Nuke your temporary asp.net folder contents. Not sure why the update didn't automatically get compiled, though.

3Dave
  • 28,657
  • 18
  • 88
  • 151
  • Does this sort of deployment automatically compile? If so that could be the problem, as they just posted the dll, not the source. – dwidel Apr 19 '11 at 20:03
  • @dwidel, sometimes Asp.Net goofs and just doesn't copy the files into the Temporary Asp.Net Files folder. Blowing it away will ensure that it resolves itself. – Andy Apr 19 '11 at 20:08
  • @dwidel NEVER put your source on the server. @Andy is correct - this just happens sometimes. Thankfully it's rare. – 3Dave Apr 19 '11 at 20:34
  • 1
    It happens often enough that you may as well nerf your temp folder as part of your release script – Mark Walsh Jan 09 '15 at 17:02
5

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.

Tom A
  • 111
  • 1
  • 9
  • Thanks for this clarification. We had one website pointing to Framework and the other to Framework64. – Savage Nov 13 '18 at 15:26
0

You don't have to stop IIS to deploy your update, you just copy them over.

Also, if they copied only the DLL but your fix was in the .aspx file, then it won't show up. You should really do a full deployment.

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • The fix is definitely in the dll, I can use reflector to disassemble the dll and see the fix. – dwidel Apr 19 '11 at 19:39
  • 2
    This doesn't work for a surprisingly large number of cases. It depends on how the application was developed. IIS caches files and sometimes it requires blowing out the temp file. – ATL_DEV Feb 01 '13 at 08:09
0

We copied the project source code to a new folder and reopened the solution. This somehow tricked Visual Studio into not using the cached version of the DLL. Wish we knew why this worked, but that resolved it for us.

Michael
  • 2,825
  • 3
  • 24
  • 30