May, 2009

  • Kirill Osenkov

    Some resources about Visual Studio Extensibility

    • 1 Comments

    A couple of readers have posted questions about Visual Studio Extensibility, DTE, your own packages, commands, experimental hive etc. To be frank, I’m not an expert in this field, so instead of trying to answer these questions, I will point to some better resources for VSX (VS Extensibility):

  • Kirill Osenkov

    A simple sample for C# 4.0 ‘dynamic’ feature

    • 11 Comments

    Earlier I posted some code to start Visual Studio using C# 3.0:

    using System;
    using EnvDTE;
    
    class Program
    {
        static void Main(string[] args)
        {
            Type visualStudioType = Type.GetTypeFromProgID("VisualStudio.DTE.9.0");
            DTE dte = Activator.CreateInstance(visualStudioType) as DTE;
            dte.MainWindow.Visible = true;
        }
    }

    Now here’s the code that does the same in C# 4.0:

    using System;
    
    class Program
    {
        static void Main(string[] args)
        {
            Type visualStudioType = Type.GetTypeFromProgID("VisualStudio.DTE.10.0");
            dynamic dte = Activator.CreateInstance(visualStudioType);
            dte.MainWindow.Visible = true;
        }
    }

    At first, it looks the same, but:

    1. Referencing EnvDTE.dll is not required anymore – you also don’t need using EnvDTE – don’t need to reference anything!
    2. You declare the ‘dte’ variable to be weakly typed with the new dynamic contextual keyword
    3. You don’t have to cast the instance returned by Activator.CreateInstance
    4. You don’t get IntelliSense as you type in the last line
    5. The calls to dte are resolved and dispatched at runtime

    It’s a trade-off, but I still view dynamic as yet another useful tool in the rich C# programmer’s toolbox to choose from.

  • Kirill Osenkov

    Should Call Hierarchy display compiler-generated member calls?

    • 3 Comments

    [A quick reminder, Call Hierarchy is a new IDE feature in VS 2010]

    In the comments to the previous post, a reader is asking:

    But why are the query operator method calls ignored by the Call Hierarchy?

    var r = from i in new[] { 1, 2, 3 }

           where i > 1

           select i;

    The code snippet above calls Enumerable.Where and Enumerable.Select, and I reacon they should go into Call Hierarchy, which is not the case of the current beta. Any hint on this?

    This is actually a good question. We thought about this issue in the feature design meetings and the reasoning behind the decision not to show the LINQ methods was as follows. The foreach statement also calls GetEnumerator and MoveNext, lock calls Monitor.TryEnter (or something similar??), not to mention other places where compiler-generated code calls members (e.g. the yield return state machine, lambdas, etc). The question is simple: where do we stop? In other words, how deep do we go down the abstraction ladder?

    This also applies to things like calling += on events, which actually calls Delegate.Combine, calling a delegate calls the Invoke method, etc. etc. We decided that we will only show a member call in Call Hierarchy if the compiler actually sees the member’s symbol in the source code. Find All References also follows this pattern, e.g. if you look for Point, you will have two references in Point p = new Point(); and only one reference in var p = new Point(); – since the symbol doesn’t show up in your source code, we don’t mention it. This might be misleading actually, also when you’re looking for calls to a method, we won’t show you places where you create a delegate that points to this method (or method group).

    Do you think this reasoning is OK or would you like us to change the feature’s behavior? If yes, how exactly should it behave? Also keep in mind that changing this behavior at this point will be pretty costly (i.e. I will have to retest everything!). Not even to mention that our dev will have to change the implementation :)

    Thanks!

  • Kirill Osenkov

    Visual Studio 2010 Beta 1 is out!

    • 2 Comments

    In case you missed it (which I don’t believe), today we released Visual Studio 2010 Beta 1 to MSDN subscribers. On Wednesday, it will become available for everyone else to download.

    The build is much more stable and fleshed out then the early CTP preview – I’d say, the functionality of Visual Studio 2010 is at least 95% there already. Our next top priority is fixing performance and making VS fast, sleek and snappy. But it already got its new WPF “skin”, the brand-new WPF editor, historical debugger, architecture explorer, and of course, C# 4.0 and VB 10 new language and IDE features. Also, for the first time ever, F# is in the box just like C# and VB.

    In any case – go try it out and tell us what you think. If you have anything to say about the new C# Call Hierarchy toolwindow – let me know.

Page 1 of 1 (4 items)