> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

> HTH

> Corrado

> On Sat, May 24, 2008 at 12:59 AM, Corrado Cavalli <
> corradocava...@gmail.com> wrote:

>>  While not strictly WPF related, found this interesting tool to enforce
>> code styling

>> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

>> HTH

>> Corrado

> --
> Regards
> Marlon
> Blog - http://marlongrech.wordpress.com/
> WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

> http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmust...

> If you place the using directive within your namespace declaration,
> referenced assemblies won't be loaded until the class that uses them are
> loaded. Placing them outside the namespace declaration means they will be
> loaded the second the assembly is loaded. In most cases this means that
> every assembly that your application references is being loaded at start
> time. Simply moving your using directives inside of your namespace
> declaration can impact your app startup time significantly!

> On Fri, May 23, 2008 at 7:00 PM, Marlon Grech <marlongr...@gmail.com>
> wrote:

>> I already downloaded it, it is super cool!!!!!!!!!!!!!!!!!!!!!!!!!

>> On Sat, May 24, 2008 at 12:59 AM, Corrado Cavalli <
>> corradocava...@gmail.com> wrote:

>>>  While not strictly WPF related, found this interesting tool to enforce
>>> code styling

>>> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

>>> HTH

>>> Corrado

>> --
>> Regards
>> Marlon
>> Blog - http://marlongrech.wordpress.com/
>> WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

> *From:* wpf-disciples@googlegroups.com [mailto:
> wpf-disciples@googlegroups.com] *On Behalf Of *Corrado Cavalli
> *Sent:* 30 May 2008 17:12
> *To:* wpf-disciples@googlegroups.com
> *Subject:* RE: Interesting tool

> Thanks Mike, very helpful!

> Corrado

> *From:* wpf-disciples@googlegroups.com [mailto:
> wpf-disciples@googlegroups.com] *On Behalf Of *Mike Brown
> *Sent:* venerdì 30 maggio 2008 17:58
> *To:* wpf-disciples@googlegroups.com
> *Subject:* Re: Interesting tool

> I found how it relates to WPF.

> http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmust...

> If you place the using directive within your namespace declaration,
> referenced assemblies won't be loaded until the class that uses them are
> loaded. Placing them outside the namespace declaration means they will be
> loaded the second the assembly is loaded. In most cases this means that
> every assembly that your application references is being loaded at start
> time. Simply moving your using directives inside of your namespace
> declaration can impact your app startup time significantly!

> On Fri, May 23, 2008 at 7:00 PM, Marlon Grech <marlongr...@gmail.com>
> wrote:

> I already downloaded it, it is super cool!!!!!!!!!!!!!!!!!!!!!!!!!

> On Sat, May 24, 2008 at 12:59 AM, Corrado Cavalli <
> corradocava...@gmail.com> wrote:

> While not strictly WPF related, found this interesting tool to enforce code
> styling

> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

> HTH

> Corrado

> --

> Regards
> Marlon
> Blog - http://marlongrech.wordpress.com/
> WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

> <br

> ESP is one of the most awesome simulation platforms I have ever seen, and I
> will be "playing" with it for the next few months looking at integrating it
> with the work I do here in the UK. We have a really high end strategy
> platform (which was originally made for the McLaren F1 teams track strategy
> requirements)

> You can model nuclear war with it etc.. (so pretty hardcore)

> This is the WPF UI I just implemented for the product..
> http://www.smithbayes.com/whatwedo.html

> If you find out any more interesting bits about it, I will be grateful to
> hear it!

> Cheers

> *From:* wpf-disciples@googlegroups.com [mailto:
> wpf-disciples@googlegroups.com] *On Behalf Of *Mike Brown
> *Sent:* 30 May 2008 20:43

> *To:* wpf-disciples@googlegroups.com
> *Subject:* Re: Interesting tool

> Don't thank me yet...I haven't CONFIRMED an increase in app load time. I'm
> just conjecturing that the two might be interrelated. Of course, it would
> help if VS helped enforced that rule itself.

> Speaking of cool tools have you guys looked at ESP
> http://www.microsoft.com/esp

> Also am I the only one excited about multitouch in Windows 7...I've GOTTA
> go to PDC this year...just gotta.

> On Fri, May 30, 2008 at 2:22 PM, Brennon Williams <
> brennonwilli...@x-coders.com> wrote:

> Excellent information here… thanks Mike for the tip and Corrado for raising
> the tool.

> *From:* wpf-disciples@googlegroups.com [mailto:
> wpf-disciples@googlegroups.com] *On Behalf Of *Corrado Cavalli
> *Sent:* 30 May 2008 17:12

> *To:* wpf-disciples@googlegroups.com

> *Subject:* RE: Interesting tool

> Thanks Mike, very helpful!

> Corrado

> *From:* wpf-disciples@googlegroups.com [mailto:
> wpf-disciples@googlegroups.com] *On Behalf Of *Mike Brown
> *Sent:* venerdì 30 maggio 2008 17:58
> *To:* wpf-disciples@googlegroups.com
> *Subject:* Re: Interesting tool

> I found how it relates to WPF.

> http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmust...

> If you place the using directive within your namespace declaration,
> referenced assemblies won't be loaded until the class that uses them are
> loaded. Placing them outside the namespace declaration means they will be
> loaded the second the assembly is loaded. In most cases this means that
> every assembly that your application references is being loaded at start
> time. Simply moving your using directives inside of your namespace
> declaration can impact your app startup time significantly!

> On Fri, May 23, 2008 at 7:00 PM, Marlon Grech <marlongr...@gmail.com>
> wrote:

> I already downloaded it, it is super cool!!!!!!!!!!!!!!!!!!!!!!!!!

> On Sat, May 24, 2008 at 12:59 AM, Corrado Cavalli <
> corradocava...@gmail.com> wrote:

> While not strictly WPF related, found this interesting tool to enforce code
> styling

> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

> HTH

> Corrado

> --

> Regards
> Marlon
> Blog - http://marlongrech.wordpress.com/
> WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

> <br

> <br

> The IL that the C# compiler generates is the same in either case. In fact
> the C# compiler generates precisely nothing corresponding to each using
> directive. Using directives are purely a C#ism, and they have no meaning to
> .NET itself. (Not true for using *statements* but those are something
> quite different.)

> In IL, type names are fully qualified, so there's no use for a using
> directive concept. (Actually, strictly speaking, in the raw binary of IL
> type names are referenced by metadata tokens, which are indexes into the
> metadata tables in the assembly. But the names in those tables are fully
> qualified. Moreover, if you look at the IL source code format, types are
> always fully qualified.)

> The CLR doesn't actually have any intrinsic representation of a namespace
> per se. There are no namespace tables in the metadata. You can't ask an
> assembly for the list of namespaces it uses or defines. In the CLR,
> namespaces are really just a type naming convention. C# happens to offer
> some language support for this convention.

> I just ran a couple of experiments to demonstrate that the claim in that
> article is wrong.

> First experiment: I put a 'using System.Xml.Linq;' into a file in a WPF
> project that had a reference to the System.Xml.Linq assembly, but which
> doesn't actually use that assembly. Running ILDASM on the output, I could
> see that the presence of the using statement did not cause a reference to
> the System.Xml.Linq assembly. The C# compiler trims down the set of
> referenced assemblies only to those that you are really making use of. The
> presence of a using directive is not sufficient to count as "making use" –
> you actually have to write code that does something with a type in that
> assembly.

> Since a using directive on its own is not enough to cause the C# compiler
> to emit an assembly reference, it's clearly not going to cause it to load
> the assembly.

> Second experiment: I added a method that actually makes use of
> System.Xml.Linq, but only does so when a button click handler runs. My goal
> here was to see when exactly the assembly does get loaded in the case where
> it doesn't get completely eliminated by the compiler like it did in the
> first experiment.

> I've got System.Xml.Linq at file scope. And I've done this in my
> codebehind:

> public partial class Window1 : Window

> {

>     public Window1()

>     {

>         InitializeComponent();

>         this.Loaded += new RoutedEventHandler(Window1_Loaded);

>     }

>     void Window1_Loaded(object sender, RoutedEventArgs e)

>     {

>         ShowAssemblies();

>     }

>     private static void ShowAssemblies()

>     {

>         var asmNames = from asm in AppDomain.CurrentDomain.GetAssemblies()

>                        select asm.GetName().Name + Environment.NewLine;

>         MessageBox.Show(string.Concat(asmNames.ToArray()));

>     }

>     private void button1_Click(object sender, RoutedEventArgs e)

>     {

>         ShowAssemblies();

>         UseLinq();

>         ShowAssemblies();

>     }

>     private void UseLinq()

>     {

>         XDocument doc = new XDocument();

>     }

> }

>  If that web site is correct, you would expect System.Xml.Linq to load
> straight away. But when it runs, the assembly list shown by the Loaded
> handler doesn't include that assembly. Nor is it present in directly before
> the call to UseLinq. But directly after UseLinq returns, and the assembly
> list is displayed for the 3rd time, only then does it include
> System.Xml.Linq.

> And my using statement is at file scope. Moving it changes nothing.

> Running in the debugger messes this up by the way –the debugger appears to
> pre-load all referenced assemblies. Again, this is unrelated to the position
> of the using statement.

> Running a Release build also changes things slightly. The UseLinq function
> ends up getting inlined on release builds, so the System.Xml.Linq assembly
> loads directly before the button click handler runs for the first time. But
> it's still absent when the Loaded handler runs, demonstrating that even in
> this case, it doesn't load at the same time as everything else. And if you
> want to turn off inlining, you can put this in front of the UseLinq
> definition:

>     [System.Runtime.CompilerServices.MethodImpl
> (System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]

> But however you slice it, the System.Xml.Linq assembly always loads some
> time later than all the other assemblies, and it makes precisely no
> difference whether the using directive is inside or outside the namespace.

> So I'm afraid whoever wrote that article didn't know what they were talking
> about on point 2, and didn't bother to check their facts, sadly.

> And while they carefully qualified their claim with disclaimer that things
> change from one version of .NET to the next, I'm afraid in this case that
> doesn't help – moving the using directives around doesn't actually change
> anything, because as far as IL and the CLR is concerned, it doesn't care
> where the thing goes. Using directives are purely a C#ism, and have no
> bearing on the output of the compiler. (Unless of course you contrive an
> example where moving the using directive actually changes the meaning of the
> code. In that case you will of course get different compiler output, but the
> fact remains that there's no way to tell from the original IL which using
> directives went where, or indeed whether the original source code didn't use
> using at all, and instead did everything with fully-qualified type names.
> You just can't tell from the compiler output.)

> And that makes sense when you think about it – this has to be a source
> analysis rule, because you couldn't possibly implement it as an IL-driven
> FxCop rule. FxCop can only detect things that make a difference to the
> compiler output.

> So point 2 is invalid. I think point 3 is just point 1 restated for the
> multiple namespace case... So there's really only one argument in that page,
> and to be honest, I think it's kind of weak. It's true, but it seems like a
> pretty contrived edge case. I know some people happen to have a stylistic
> preference for the proposed style (e.g. Chris Anderson prefers it). The
> argument seems a bit like a post-hoc justification for a personal stylistic
> preference.

> So all of you on this thread who "didn't know" about this were right all
> along, because it turns out to be rubbish. Stick to your guns, and construct
> experiments! :D

> --

> Ian Griffiths – professional pedant

> *From:* wpf-disciples@googlegroups.com [mailto:
> wpf-disciples@googlegroups.com] *On Behalf Of *Mike Brown
> *Sent:* 30 May 2008 16:58
> *To:* wpf-disciples@googlegroups.com
> *Subject:* Re: Interesting tool

> I found how it relates to WPF.

> http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmust...

> If you place the using directive within your namespace declaration,
> referenced assemblies won't be loaded until the class that uses them are
> loaded. Placing them outside the namespace declaration means they will be
> loaded the second the assembly is loaded. In most cases this means that
> every assembly that your application references is being loaded at start
> time. Simply moving your using directives inside of your namespace
> declaration can impact your app startup time significantly!

> On Fri, May 23, 2008 at 7:00 PM, Marlon Grech <marlongr...@gmail.com>
> wrote:

> I already downloaded it, it is super cool!!!!!!!!!!!!!!!!!!!!!!!!!

> On Sat, May 24, 2008 at 12:59 AM, Corrado Cavalli <
> corradocava...@gmail.com> wrote:

> While not strictly WPF related, found this interesting tool to enforce code
> styling

> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

> HTH

> Corrado

> --

> Regards
> Marlon
> Blog - http://marlongrech.wordpress.com/
> WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

> <br

> Very very good Ian :D

> On Tue, Jun 3, 2008 at 11:30 PM, Ian Griffiths <i...@interact-sw.co.uk>
> wrote:

>>  Sorry guys, but the assembly loading thing is just wrong.

>> The IL that the C# compiler generates is the same in either case. In fact
>> the C# compiler generates precisely nothing corresponding to each using
>> directive. Using directives are purely a C#ism, and they have no meaning to
>> .NET itself. (Not true for using *statements* but those are something
>> quite different.)

>> In IL, type names are fully qualified, so there's no use for a using
>> directive concept. (Actually, strictly speaking, in the raw binary of IL
>> type names are referenced by metadata tokens, which are indexes into the
>> metadata tables in the assembly. But the names in those tables are fully
>> qualified. Moreover, if you look at the IL source code format, types are
>> always fully qualified.)

>> The CLR doesn't actually have any intrinsic representation of a namespace
>> per se. There are no namespace tables in the metadata. You can't ask an
>> assembly for the list of namespaces it uses or defines. In the CLR,
>> namespaces are really just a type naming convention. C# happens to offer
>> some language support for this convention.

>> I just ran a couple of experiments to demonstrate that the claim in that
>> article is wrong.

>> First experiment: I put a 'using System.Xml.Linq;' into a file in a WPF
>> project that had a reference to the System.Xml.Linq assembly, but which
>> doesn't actually use that assembly. Running ILDASM on the output, I could
>> see that the presence of the using statement did not cause a reference to
>> the System.Xml.Linq assembly. The C# compiler trims down the set of
>> referenced assemblies only to those that you are really making use of. The
>> presence of a using directive is not sufficient to count as "making use" –
>> you actually have to write code that does something with a type in that
>> assembly.

>> Since a using directive on its own is not enough to cause the C# compiler
>> to emit an assembly reference, it's clearly not going to cause it to load
>> the assembly.

>> Second experiment: I added a method that actually makes use of
>> System.Xml.Linq, but only does so when a button click handler runs. My goal
>> here was to see when exactly the assembly does get loaded in the case where
>> it doesn't get completely eliminated by the compiler like it did in the
>> first experiment.

>> I've got System.Xml.Linq at file scope. And I've done this in my
>> codebehind:

>> public partial class Window1 : Window

>> {

>>     public Window1()

>>     {

>>         InitializeComponent();

>>         this.Loaded += new RoutedEventHandler(Window1_Loaded);

>>     }

>>     void Window1_Loaded(object sender, RoutedEventArgs e)

>>     {

>>         ShowAssemblies();

>>     }

>>     private static void ShowAssemblies()

>>     {

>>         var asmNames = from asm in AppDomain
>> .CurrentDomain.GetAssemblies()

>>                        select asm.GetName().Name + Environment.NewLine;

>>         MessageBox.Show(string.Concat(asmNames.ToArray()));

>>     }

>>     private void button1_Click(object sender, RoutedEventArgs e)

>>     {

>>         ShowAssemblies();

>>         UseLinq();

>>         ShowAssemblies();

>>     }

>>     private void UseLinq()

>>     {

>>         XDocument doc = new XDocument();

>>     }

>> }

>>  If that web site is correct, you would expect System.Xml.Linq to load
>> straight away. But when it runs, the assembly list shown by the Loaded
>> handler doesn't include that assembly. Nor is it present in directly before
>> the call to UseLinq. But directly after UseLinq returns, and the assembly
>> list is displayed for the 3rd time, only then does it include
>> System.Xml.Linq.

>> And my using statement is at file scope. Moving it changes nothing.

>> Running in the debugger messes this up by the way –the debugger appears to
>> pre-load all referenced assemblies. Again, this is unrelated to the position
>> of the using statement.

>> Running a Release build also changes things slightly. The UseLinq function
>> ends up getting inlined on release builds, so the System.Xml.Linq assembly
>> loads directly before the button click handler runs for the first time. But
>> it's still absent when the Loaded handler runs, demonstrating that even in
>> this case, it doesn't load at the same time as everything else. And if you
>> want to turn off inlining, you can put this in front of the UseLinq
>> definition:

>>     [System.Runtime.CompilerServices.MethodImpl
>> (System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]

>> But however you slice it, the System.Xml.Linq assembly always loads some
>> time later than all the other assemblies, and it makes precisely no
>> difference whether the using directive is inside or outside the namespace.

>> So I'm afraid whoever wrote that article didn't know what they were
>> talking about on point 2, and didn't bother to check their facts, sadly.

>> And while they carefully qualified their claim with disclaimer that things
>> change from one version of .NET to the next, I'm afraid in this case that
>> doesn't help – moving the using directives around doesn't actually change
>> anything, because as far as IL and the CLR is concerned, it doesn't care
>> where the thing goes. Using directives are purely a C#ism, and have no
>> bearing on the output of the compiler. (Unless of course you contrive an
>> example where moving the using directive actually changes the meaning of the
>> code. In that case you will of course get different compiler output, but the
>> fact remains that there's no way to tell from the original IL which using
>> directives went where, or indeed whether the original source code didn't use
>> using at all, and instead did everything with fully-qualified type names.
>> You just can't tell from the compiler output.)

>> And that makes sense when you think about it – this has to be a source
>> analysis rule, because you couldn't possibly implement it as an IL-driven
>> FxCop rule. FxCop can only detect things that make a difference to the
>> compiler output.

>> So point 2 is invalid. I think point 3 is just point 1 restated for the
>> multiple namespace case... So there's really only one argument in that page,
>> and to be honest, I think it's kind of weak. It's true, but it seems like a
>> pretty contrived edge case. I know some people happen to have a stylistic
>> preference for the proposed style (e.g. Chris Anderson prefers it). The
>> argument seems a bit like a post-hoc justification for a personal stylistic
>> preference.

>> So all of you on this thread who "didn't know" about this were right all
>> along, because it turns out to be rubbish. Stick to your guns, and construct
>> experiments! :D

>> --

>> Ian Griffiths – professional pedant

>> *From:* wpf-disciples@googlegroups.com [mailto:
>> wpf-disciples@googlegroups.com] *On Behalf Of *Mike Brown
>> *Sent:* 30 May 2008 16:58
>> *To:* wpf-disciples@googlegroups.com
>> *Subject:* Re: Interesting tool

>> I found how it relates to WPF.

>> http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmust...

>> If you place the using directive within your namespace declaration,
>> referenced assemblies won't be loaded until the class that uses them are
>> loaded. Placing them outside the namespace declaration means they will be
>> loaded the second the assembly is loaded. In most cases this means that
>> every assembly that your application references is being loaded at start
>> time. Simply moving your using directives inside of your namespace
>> declaration can impact your app startup time significantly!

>> On Fri, May 23, 2008 at 7:00 PM, Marlon Grech <marlongr...@gmail.com>
>> wrote:

>> I already downloaded it, it is super cool!!!!!!!!!!!!!!!!!!!!!!!!!

>> On Sat, May 24, 2008 at 12:59 AM, Corrado Cavalli <
>> corradocava...@gmail.com> wrote:

>> While not strictly WPF related, found this interesting tool to enforce
>> code styling

>> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

>> HTH

>> Corrado

>> --

>> Regards
>> Marlon
>> Blog - http://marlongrech.wordpress.com/
>> WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

>> <br

> --
> Regards
> Marlon
> WPF Blog - http://marlongrech.wordpress.com/
> Other Blog - http://dotnetalgos.wordpress.com/

> The IL that the C# compiler generates is the same in either case. In fact
> the C# compiler generates precisely nothing corresponding to each using
> directive. Using directives are purely a C#ism, and they have no meaning to
> .NET itself. (Not true for using *statements* but those are something
> quite different.)

> In IL, type names are fully qualified, so there's no use for a using
> directive concept. (Actually, strictly speaking, in the raw binary of IL
> type names are referenced by metadata tokens, which are indexes into the
> metadata tables in the assembly. But the names in those tables are fully
> qualified. Moreover, if you look at the IL source code format, types are
> always fully qualified.)

> The CLR doesn't actually have any intrinsic representation of a namespace
> per se. There are no namespace tables in the metadata. You can't ask an
> assembly for the list of namespaces it uses or defines. In the CLR,
> namespaces are really just a type naming convention. C# happens to offer
> some language support for this convention.

> I just ran a couple of experiments to demonstrate that the claim in that
> article is wrong.

> First experiment: I put a 'using System.Xml.Linq;' into a file in a WPF
> project that had a reference to the System.Xml.Linq assembly, but which
> doesn't actually use that assembly. Running ILDASM on the output, I could
> see that the presence of the using statement did not cause a reference to
> the System.Xml.Linq assembly. The C# compiler trims down the set of
> referenced assemblies only to those that you are really making use of. The
> presence of a using directive is not sufficient to count as "making use" –
> you actually have to write code that does something with a type in that
> assembly.

> Since a using directive on its own is not enough to cause the C# compiler
> to emit an assembly reference, it's clearly not going to cause it to load
> the assembly.

> Second experiment: I added a method that actually makes use of
> System.Xml.Linq, but only does so when a button click handler runs. My goal
> here was to see when exactly the assembly does get loaded in the case where
> it doesn't get completely eliminated by the compiler like it did in the
> first experiment.

> I've got System.Xml.Linq at file scope. And I've done this in my
> codebehind:

> public partial class Window1 : Window

> {

>     public Window1()

>     {

>         InitializeComponent();

>         this.Loaded += new RoutedEventHandler(Window1_Loaded);

>     }

>     void Window1_Loaded(object sender, RoutedEventArgs e)

>     {

>         ShowAssemblies();

>     }

>     private static void ShowAssemblies()

>     {

>         var asmNames = from asm in AppDomain.CurrentDomain.GetAssemblies()

>                        select asm.GetName().Name + Environment.NewLine;

>         MessageBox.Show(string.Concat(asmNames.ToArray()));

>     }

>     private void button1_Click(object sender, RoutedEventArgs e)

>     {

>         ShowAssemblies();

>         UseLinq();

>         ShowAssemblies();

>     }

>     private void UseLinq()

>     {

>         XDocument doc = new XDocument();

>     }

> }

>  If that web site is correct, you would expect System.Xml.Linq to load
> straight away. But when it runs, the assembly list shown by the Loaded
> handler doesn't include that assembly. Nor is it present in directly before
> the call to UseLinq. But directly after UseLinq returns, and the assembly
> list is displayed for the 3rd time, only then does it include
> System.Xml.Linq.

> And my using statement is at file scope. Moving it changes nothing.

> Running in the debugger messes this up by the way –the debugger appears to
> pre-load all referenced assemblies. Again, this is unrelated to the position
> of the using statement.

> Running a Release build also changes things slightly. The UseLinq function
> ends up getting inlined on release builds, so the System.Xml.Linq assembly
> loads directly before the button click handler runs for the first time. But
> it's still absent when the Loaded handler runs, demonstrating that even in
> this case, it doesn't load at the same time as everything else. And if you
> want to turn off inlining, you can put this in front of the UseLinq
> definition:

>     [System.Runtime.CompilerServices.MethodImpl
> (System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]

> But however you slice it, the System.Xml.Linq assembly always loads some
> time later than all the other assemblies, and it makes precisely no
> difference whether the using directive is inside or outside the namespace.

> So I'm afraid whoever wrote that article didn't know what they were talking
> about on point 2, and didn't bother to check their facts, sadly.

> And while they carefully qualified their claim with disclaimer that things
> change from one version of .NET to the next, I'm afraid in this case that
> doesn't help – moving the using directives around doesn't actually change
> anything, because as far as IL and the CLR is concerned, it doesn't care
> where the thing goes. Using directives are purely a C#ism, and have no
> bearing on the output of the compiler. (Unless of course you contrive an
> example where moving the using directive actually changes the meaning of the
> code. In that case you will of course get different compiler output, but the
> fact remains that there's no way to tell from the original IL which using
> directives went where, or indeed whether the original source code didn't use
> using at all, and instead did everything with fully-qualified type names.
> You just can't tell from the compiler output.)

> And that makes sense when you think about it – this has to be a source
> analysis rule, because you couldn't possibly implement it as an IL-driven
> FxCop rule. FxCop can only detect things that make a difference to the
> compiler output.

> So point 2 is invalid. I think point 3 is just point 1 restated for the
> multiple namespace case... So there's really only one argument in that page,
> and to be honest, I think it's kind of weak. It's true, but it seems like a
> pretty contrived edge case. I know some people happen to have a stylistic
> preference for the proposed style (e.g. Chris Anderson prefers it). The
> argument seems a bit like a post-hoc justification for a personal stylistic
> preference.

> So all of you on this thread who "didn't know" about this were right all
> along, because it turns out to be rubbish. Stick to your guns, and construct
> experiments! :D

> --

> Ian Griffiths – professional pedant

> *From:* wpf-disciples@googlegroups.com [mailto:
> wpf-disciples@googlegroups.com] *On Behalf Of *Mike Brown
> *Sent:* 30 May 2008 16:58
> *To:* wpf-disciples@googlegroups.com
> *Subject:* Re: Interesting tool

> I found how it relates to WPF.

> http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmust...

> If you place the using directive within your namespace declaration,
> referenced assemblies won't be loaded until the class that uses them are
> loaded. Placing them outside the namespace declaration means they will be
> loaded the second the assembly is loaded. In most cases this means that
> every assembly that your application references is being loaded at start
> time. Simply moving your using directives inside of your namespace
> declaration can impact your app startup time significantly!

> On Fri, May 23, 2008 at 7:00 PM, Marlon Grech <marlongr...@gmail.com>
> wrote:

> I already downloaded it, it is super cool!!!!!!!!!!!!!!!!!!!!!!!!!

> On Sat, May 24, 2008 at 12:59 AM, Corrado Cavalli <
> corradocava...@gmail.com> wrote:

> While not strictly WPF related, found this interesting tool to enforce code
> styling

> http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-th...

> HTH

> Corrado

> --

> Regards
> Marlon
> Blog - http://marlongrech.wordpress.com/
> WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

> <br