LONG IIS Delay when changing Managed DLLs

Posted on 2008-10-30
Medium Priority
Last Modified: 2013-12-14

I have an application where the entry point is a fairly simple .aspx page, and .cs code behind. The code behind links to other managed dlls - in the bin directory - using Assembly.Load. Which dll it links to is dependant on input from the browser, and dlls can be added, removed, changed etc extremely rapidly while developing an application.

The issue I have is, that whenever a DLL is changed, the next Web interaction - the next time the .aspx is run - there is a delay of a couple of minutes, I assume while Windows does something because it knows that a managed DLL has been changed. Please note that 'changed' here also means 'touched', i.e. recompiling c# code without changing the code, i.e. wirthout changing the contents of the .DLL causes this as well.

This does not seem to be IIS starting up or anything - if I restart the machine for example I get a delay of say 20 seconds the first time the .aspx is run. It is the delay of 2 or so minutes whenever a DLL is changed that is causing the issue/that I do not understand.

The dll that has been changed may not even be used on this submission/connection to the .aspx page - and the delay still occurs.

If anyone could explain why this occurs, that would be great! If anyone could explain how to resolve this - for example, some way to make Windows process or whatever only the dlls that have actually been changed - that would be even better!

I am fairly new to ASP.NET and C#, and I apologise if I have used any unclear etc terms as a result. In case it matters this occurs both on Windows XP Professional and Vista Home Premium. I am using the csc compiler from Visual C# Express Edition 2008 - i.e. I am compiling the dlls from the command line, not via the Visual Studio interface.

Thanks in advance,

Question by:glenn_groves
  • 2
LVL 37

Accepted Solution

samtran0331 earned 1000 total points
ID: 22846846
Any changes to the \bin folder will cause your application to restart.IIS doesn't restart, but the worker process running your app does.Also, IIS and ASP.Net have a caching mechanism that caches your app on the web server, for IIS/ASP.Net 2.0/3.0, it is located at:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET FilesEverytime IIS thinks your app might have changed, it restarts the worker process and then goes through that cache to see what it needs to update.It doesn't matter that your app is compiled from VS or a command line...pre-compiled or using the JIT compiler....the caching and application restarts is the way IIS and ASP.Net work.If you go into the folder I mentioned above, you should see a folder inside of it with the name of your app....and inside of that folder, will be more folders (they will be named off some GUID created by windows)...those folders are the "versions" that IIS thinks need to be cached...and if you have more than one or two of these folders....IIS is keeping too many versions of your app....and each time it thinks it detects a change, it goes through all those foldersIf you delete all those folders (IIS needs to be stopped or do it right after a re-boot...or from a command line type: iisreset)....you will notice some decrease in that delay...but overall that delay is always going to happen because IIS will restart your app and then do the cache checking whenever it thinks your app has changed.It is annoying from a development standpoint, but of course, once in production...it won't go through that process nearly as often

Author Comment

ID: 22901017
Thanks for the explanation! Now that I know what is going on I have found a way around it while developing.

I have added an 'appbin' folder that all 'changeable' dlls are placed into. Before compiling into 'appbin' I do an iisreset. That adds about 5 seconds to the compile time. The next Web interaction takes a few seconds while IIS sets up again (or something). Those extra 8 or so seconds delay are much better than the extra 2-odd minutes delay I was getting when IIS rebuilt the cache after I compiled into 'bin'.

When actually going live I will need to change just one routine - that does a LoadFrom to load the DLLs in the appbin - to look at the bin directory instead of appbin, and move the contents of appbin into bin.

While this is possibly not as tidy as it could be, it is very workable, so the issue I was having with performance/delays when developing is effectively resolved.

Thank you!

Author Closing Comment

ID: 31511571
Thank you! Much appreciated!

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Prologue It is often required to host multiple websites on a single instance of IIS, mostly in development environments instead of on production servers. I am sure it is not much a preferred solution on production servers but this is at least a pos…
International Data Corporation (IDC) prognosticates that before the current the year gets over disbursing on IT framework products to be sent in cloud environs will be $37.1B.
The viewer will learn how to use and create keystrokes in Netbeans IDE 8.0 for Windows.
The viewer will learn how to synchronize PHP projects with a remote server in NetBeans IDE 8.0 for Windows.

600 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question