the same thing. I'll check out the sub-folder solution. Do you know if msft
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.
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?
Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
@discussions.microsoft.com> wrote in message
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
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.