Interesting tool

[Corrado Cavalli]

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

http://blogs.msdn.com/sourceanalysis/archive/2008/05/23/announcing-the-release-of-microsoft-source-analysis.aspx

 

HTH

Corrado

[Marlon Grech]

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

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

[Mike Brown]

I found how it relates to WPF.

http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmustbeplacedwithinnamespace.aspx

 

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!

[Josh Smith]

FASCINATING!

[Corrado Cavalli]

Thanks Mike, very helpful!

 

Corrado

<br

[Laurent Bugnion [MVP, MCP]]

Wow I had no idea about that, and yet I consider myself a rather
experienced C# developer. How interesting. Thanks Mike!!

--
Laurent Bugnion [Microsoft MVP, MCP]
Software engineering, Blog: http://www.galasoft.ch
PhotoAlbum: http://www.galasoft.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Brennon Williams]

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

[Mike Brown]

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.

[Karl Shifflett]

Karl is SO juiced about multitouch!  I’ve got two of these machines.

<br

[Brennon Williams]

I am glad in a way that this is news to you guys as well...

My first thought was... awesome.. I had no idea... but it really does make
perfect sense and I cant believe I never tried it before...

And my second was.. I am going to look like I have the IQ of a tennis ball
for not knowing that ;-)

One of things I enjoy so very much about this group (besides the excellent
banter).. is the fact that these bits of information often escape my
attention... and these are very important.

I am in awe of the collective knowledge of all you guys..

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Laurent Bugnion [MVP, MCP]
Sent: 30 May 2008 19:05
To: wpf-di...@googlegroups.com
Subject: Re: Interesting tool

[Laurent Bugnion [MVP, MCP]]

Not knowing stuff is OK as long as you're writing the book, but when
it's published, you're supposed to be knowing EVERYTHING. Shame on you,
grasshopper :)

[Brennon Williams]

It’s wicked isn’t!

 

At the rate I am developing my MT device, I should have a commercial device within the next 12-18 weeks.

 

That is a 42” multi-touch device, including a working WPF framework to boot!

 

The best part… the cost…

 

I will announce that a little later on.. but it will be quite affordable.

[Brennon Williams]

Oh so true... thank god my book was not a dev book! ;-)

[Brennon Williams]

Hey Mike,

 

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

<br

[Mike Brown]

Whoa! That is friggin' awesome!

[rudigrobler]

hi Brennon...

That is one very cool UI! Now I have to get your book!

Cool stuff

Rudi

[Brennon Williams]

Thanks guys!

I cant take all the credit though... I am working with an awesome team at
SmithBayes.. and the best part.. its really fun stuff...

Man I love my job!

Cheers

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]

[Ian Griffiths]

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 3^rd 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-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Mike Brown
Sent: 30 May 2008 16:58
To: wpf-di...@googlegroups.com
Subject: Re: Interesting tool

 

I found how it relates to WPF.

<br

[Marlon Grech]

Ian.... I just have 1 word... IMPRESSIVE.... I must admit I just fell in love with you.... LOL (I hope that my wife does not see this email..... ow shit I forgot this is public ... ha ha ha)

Very very good Ian :D

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

[Mike Brown]

It didn't sound right, but seeing that it came from MSFT...I took it at face value. Like I said, I didn't test it myself, but it sounded like something worth investigating. Sounds like it's a remnant from 1.0 or something.

[Josh Smith]

Thanks for setting us straight Ian. :) 

Josh