While not strictly WPF related, found this interesting tool to enforce code styling
Thanks Mike, very helpful!
Excellent information here… thanks Mike for the tip and Corrado for raising the tool.
Karl is SO juiced about multitouch! I’ve got two of these machines.
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..
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Laurent Bugnion [MVP, MCP]
Sent: 30 May 2008 19:05
Subject: Re: Interesting tool
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.
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!
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
this.Loaded += new RoutedEventHandler(Window1_Loaded);
void Window1_Loaded(object sender, RoutedEventArgs e)
private static void ShowAssemblies()
var asmNames = from asm in AppDomain.CurrentDomain.GetAssemblies()
select asm.GetName().Name + Environment.NewLine;
private void button1_Click(object sender, RoutedEventArgs e)
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:
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
I found how it relates to WPF.