Difference between AppDomain.GetAssemblies and BuildManager.GetReferencedAssemblies

Question

Just wanted to know if there is any difference between the two, in the context of a fully trust asp.net mvc 2 application.

Answer 1

The .NET Framework defers loading assemblies into the current AppDomain until they're needed. For example, if you call into a third-party library only from SomeMethod(), the third-party DLL normally won't be loaded until the first time SomeMethod() runs.

AppDomain.GetAssemblies() gives you all assemblies which have already been loaded into the current AppDomain. BuildManager.GetReferencedAssemblies() (This method is only available in the .Net Framework System.Web.dll) returns a list of all assemblies referenced from Web.config and elsewhere, and it loads those assemblies into the current AppDomain.

Here's a worked-out example of the above.

1. SomeMethod() hasn't yet run.
2. Call AppDomain.GetAssemblies(), returns a set that does not include ThirdParty.dll.
3. Call SomeMethod().
4. Call AppDomain.GetAssemblies(), returns a set that includes ThirdParty.dll.

In this example, the CLR defers loading ThirdParty.dll into the current AppDomain until it's absolutely necessary. And since it's necessary for the execution of SomeMethod(), that's when it gets loaded.

Alternatively:

1. SomeMethod() hasn't yet run.
2. Call AppDomain.GetAssemblies(), returns a set that does not include ThirdParty.dll.
3. Call BuildManager.GetReferencedAssemblies(), returns a set that includes ThirdParty.dll.
4. Call AppDomain.GetAssemblies(), returns a set that includes ThirdParty.dll.

Here, even though you never called SomeMethod(), the call to BuildManager.GetReferencedAssemblies() loaded the third-party library into the current AppDomain on your behalf.

Of course, this is all subject to certain optimizations, etc., but the general idea holds.