Replacing a dll in /bin

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is there a way to reduce the overhead of replacing a single dll in the /bin
directory?

I have 125 dlls in bin, but even if i only replace one small DLL it takes
about 1 minute to hit an aspx page afterwards.

Any advice or leads appreciated!

Thanks
 
I have the same problem, but it doesn't look like it has anything to
do with selectively replacing dlls.

The change in one DLL causes IIS to detect it doesn't have a current
copy of the web application in cache, so it reloads everything - even
if only one dll was changed. I haven't found a way to allieviate
this, and I've experienced it even with Microsoft web applications
such as MSCRM.

I've also found that if the web app is inactive long enough (say
overnight), that the next day the delay is back on first use of the
web app as IIS has to refresh its cache again, which it trashed
because of the inactivity.

The only thing I found that does work a little bit is if the
components of the application are separated into their own IIS
websites, but remain in the same IIS application pool. I've found
that when I change one of the dlls in such a sub-site (which also has
its dlls in its own folder), that it doesn't impact the other parts of
the application. All subsites have the same domain name, however, and
each is assigned its own unique port number (ie mydomain.com:5555,
mydomain.com:8081, etc)
 
Thanks Andy, it at least eases the pain to know that others are going through
the same thing. I'll check out the sub-folder solution. Do you know if msft
is doing anything to address this in Orcas / IIS 7? It seems like they made
an effort to fix some of the performance problems like this with bs 2005 SP1.
 
There's nothing to do. The DLLs are independent libraries of code, and the
application has an unknown number of dependencies upon these DLLs. That is,
for example, you can create DLLs that are dependent upon other DLLs, and app
code which is dependent upon multiple DLLs. Therefore, without parsing the
entire application to detect the entire chain of possible interdependencies,
there is no way to determine which DLLs need to be re-loaded.

For example:

DLL_A depends on DLL_B and DLL_C
DLL_B depends on DLL_C and DLL_D
DLL_C depends on DLL_E
DLL_D depends on DLL_E

Page_A calls code in DLL_A and DLL_D
Page_B calls code in DLL_A and DLL_B and UserControl_A
Page_C calls code in DLL_D and UserControl_A

UserControl_A calls code in DLL_C and contains UserControl_B
UserControl_B calls code in DLL_A and DLL_D

You replace DLL_C. Which code needs to be re-loaded?

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net
 
That makes sense. And I appreciate the complexity, that could become quite a
complicated dependecy graph. But it still seems like a problem that is
solvable.

In your example wouldn't you only need to check that the new DLL_C satisfies
the dependencies on it from DLL_A, DLL_B, and Usercontrol_A? I beleive you
could build up the dependency graph from the CLR metadata's AssemblyRef
information for the DLLs. I'm not sure how or if you could do that for the
web project's pages and usercontrols. But it seems like when you parse them
for the first time that you could store that dependency information as well.

Thanks
 
Back
Top