The simple answer is no, the inquisitive reader can read on :)
Close to 2 year back I had posted about the two styles of coding using directives as follows
and outlined the benefits of the first style (using directives inside the namespace). This post is not to re-iterate them.
This post to figure out if either of the styles have any bearing in the loading order of assemblies. Obviously at the first look it clearly indicates that is shouldn't, but this has caused some back and forth discussions over the web.
Scot Hanselman posted about a statement on the Microsoft Style cop blog which states
"When using directives are declared outside of a namespace, the .Net Framework will load all assemblies referenced by these using statements at the same time that the referencing assembly is loaded.
However, placing the using statements within a namespace element allows the framework to lazy load the referenced assemblies at runtime. In some cases, if the referencing code is not actually executed, the framework can avoid having to load one or more of the referenced assemblies completely. This follows general best practice rule about lazy loading for performance.
Note, this is subject to change as the .Net Framework evolves, and there are subtle differences between the various versions of the framework."
This just doesn't sound right because using directives have no bearing to assembly loading.
Hanselman did a simple experiment with the following code
public class Program
public static void Main(string args)
Guid g = Guid.NewGuid();
Console.WriteLine("Before XML usage");
Console.WriteLine("After XML usage");
public static void Foo()
XmlDocument x = new XmlDocument();
and then he watched the loading time using process explorer and then he moved the using inside the namespace and did the same. Both loaded the System.Xml.dll after he hit enter on the console clearly indicating that for both the cases they got lazy loaded.
Let me try to give a step by step rundown of how the whole type look up of XmlDocument happens in .NETCF which in turn would throw light on whether using directives have bearing on assembly loading.
- When Main method is Jitted and ran the System.Xml.dll is not yet loaded
- When method Foo is called the execution engine (referred to as EE) tries to JIT the method. As documented the Jitter only JITs methods that are to be executed.
- The Jitter tries to see if the method Foo is managed (could be native as well due to mixed mode support) and then tries to see if it's already Jitted (by a previous call), since it's not it goes ahead with jitting it
- The jitter validates a bunch of stuff like whether the class on which the method Foo is being called (in this case Microsoft.Sample.Program) is valid, been initialized, stack requirements, etc...
- Then it tries to resolve the local variables of the method. It waits to resolve the local variable type reference till this point so that it is able to save time and memory by not Jitting/loading types that are referenced by methods that are never executed
- Then it tries to resolve the type of the variable which in this case if System.Xml.XmlDocument.
- It sees if it's already in the cache, that is if that type is already loaded
- Since it's not the case it tries to search for the reference based on the type reference information
- This information contains the full type reference including the assembly name, which in this case is System.Xml.dll and also version information,strong name information, etc...
- All of the above information along with other information like the executing application's path is passed to the assembly loader to load the assembly
- The usual assembly search sequence is used to look for the assembly and then it is loaded and the type reference subsequently gets resolved
If you see the above steps there is in no way a dependency of assembly loading on using directive. Hence at least on .NETCF whether you put the using outside or inside the namespace you'd get the referenced assemblies loaded exactly at the time of first reference of a type from that assembly (the step #5 above is the key).
Post a Comment