.NET Framework assemblies are typically compiled and deployed into a Windows DLL-based PE format. When the common language runtime's loader resolves a class implemented within this type of assembly, it calls the Windows LoadLibrary routine on the file (which locks its access on disk), and then maps the appropriate code data into memory for run-time execution. Once loaded, the DLL file will remain locked on disk until the application domain referencing it is either torn down or manually recycled.
Although ASP.NET cannot prevent the common language runtime from locking a loaded assembly DLL on disk, it can support you by ensuring that the physical DLLs in a Web application's private assembly cache are never actually loaded by the runtime. Instead, shadow copies of the assembly DLLs are made immediately prior to their use. These shadow assemblies--not the original files--are then locked and loaded by the runtime.
Because the original assembly files always remain unlocked, you are free to delete, replace, or rename them without cycling the Web server or having to use a registration utility. FTP and similar methods work just fine. ASP.NET maintains an active list of all assemblies loaded within a particular application's application domain and uses file-change monitoring code to watch for any updates to the original files.
Comma separated values in SQL Server
13 years ago