Do Windows Servers (2008) cache .net assemblies somehow?

Question

A co-worker of mine is having the following issue (so some relevant details may require further vetting):

The server is Windows 2008 Server. There is a Windows Service that is running (exe (.net), that also utilizes a .NET assembly). There is some bug with the dll and/or exe. Some debug messages were added to and removed from the dll. This new version of the dll and its recompiled exe were ftp'd over to this server, the service was stopped, the existing dll and exe were renamed, and replaced with the new, and the service started.

We still see debug messages that were removed from the dll. They don't exist in the new code.

The server was restarted.

Is the old dll getting cached somewhere? somehow? Thank you.

---

UPDATE

The following just happened:

1. the recently renamed assembly.old was physically removed (this was the one and only copy)
2. old debug messages still in there!
3. service uninstalled/reinstalled (though we think we could have gotten away with a restart)
4. works.

So, knowing what happened before this (which included a restart of the OS), and what happened now, somehow/someway Windows is tracking the dll's(?) and when the one copy was renamed, windows defies the update and associates (in it's mind) that assembly.old will be assembly.dll. Not the new assembly.dll that was put in its place?

Because assembly.dll and assembly.old in same directory, after OS restart - old dll continually looked at. assembly.dll and no assembly.old - works.

The thing that baffles me is how do you control this? Or where is the documentation on this?

Other info: 64-bit version of the server. A VM.

Answer 1

This may be due to how .NET locates assemblies, documented here:

How the .NET Runtime Locates Assemblies
http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=VS.100%29.aspx

Note the following:

"The compiler records static references in the assembly manifest's metadata at build time. Dynamic references are constructed on the fly as a result of calling various methods, such as System.Reflection.Assembly.Load."

If your reference is static, you may examine the executing assembly's metadata for the manifest. The manifest may be examined using ILDASM or some other tool such as ILSpy. If it is dynamic, the location process is complex and sophisticated.

My experience has been that if multiple CLR versions exist (e.g., both 2.0 and 4.0), the result may be unexpected. There are several additional factors, such as:

• machine configuration and application configuration;
• if the application is all managed code, or has some unmanaged code (COM/Interop);
• if the executing/calling assembly and called assemblies are platform independent ("any cpu"), or platform-specific (x86 or x64).

It is also possible to run both 2.0 and 4.0 CLR code in a process at the same time (side-by-side execution).

I would think that this should be reproducible in a development environment, and it is unrealistic to expect the consumer to know or deal with all possible scenarios.

.NET In-Process Side-by-Side Execution
http://msdn.microsoft.com/en-us/library/ee518876%28VS.100%29.aspx

Assemblies: locating, binding and deploying
http://www.codeproject.com/KB/install/assemblydeployment.aspx

When you run Microsoft SysInternals' Process Explorer, select the service process, and the .NET Assemblies tab, it should show you all of the various loaded assemblies so you can validate that the correct file is loaded:

Answer 2

Well you answered your own question there. You dropped a new DLL onto your disk, yet when you run some code it still seems to be using the old DLL. Therefore, there must be a copy of the old DLL still lingering around in your memory somewhere.

Try this -- create a shortcut, and use this as the command to run:

%windir%\system32\rundll32.exe advapi32.dll,ProcessIdleTasks

Name it whatever you want... something like "Memory Cache Flusher". Run it in between test runs of your program.