jaredpar's WebLog : VB

Interesting Late Binding Scenario with ToString

JaredPar MSFT — Mon, 24 Jan 2011 13:00:00 GMT

Not to long ago I received an email from a customer who wanted to report a bug in the VB.Net debugger. They believed that there was a bug invoking ToString on Integer types in the immediate window and provided the following sample as evidence

i = 100
? i
100 {Integer}
    Integer: 100
? i.ToString("c02")
{"Conversion from string "c02" to type 'Integer' is not valid."}
    _HResult: -2147467262
    _message: "Conversion from string "c02" to type 'Integer' is not valid."
    Data: {System.Collections.ListDictionaryInternal}
    HelpLink: Nothing
    HResult: -2147467262
    InnerException: {"Input string was not in a correct format."}
    IsTransient: False
    Message: "Conversion from string "c02" to type 'Integer' is not valid."
    Source: "Microsoft.VisualBasic"
    StackTrace: "   at Microsoft.VisualBasic.CompilerServices.Conversions.ToInteger(String Value)"
    TargetSite: {Int32 ToInteger(System.String)}

The customer expected the method Integer.ToString(String) to be invoked and found the conversion to Integer to be a bug. Surprisingly to the user, and several people on the team, this behavior is “By Design” [1]. To understand why we have to get a better picture of how exactly this is evaluated in the immediate window. There are two particular areas of importance here.

The static type of the variable i is Object not Integer. The first expression “i = 1” declares a variable named i in the context of the debugger and assigns it the value 100. The ability to declare variables in the debugger predates type inference and uses Option Explicit Off semantics resulting in a type of Object for the variable
The debugger does not inherit project settings for Option Strict and instead evaluates all expressions with Option Strict Off.

These two combine together to mean that almost every expression evaluated on a variable declared in the immediate window will be done in a late bound fashion. It also means the above code sample is most accurately represented by the following real code.

    Sub Main()
        Dim i As Object = 100
        Dim result = i.ToString("co2")
    End Sub

Compiling and running that code will indeed cause the exact same exception as viewed in the immediate window. But why?

Remember earlier I said that almost every expression would be evaluated it a late bound fashion. The compiler will use late binding when it can’t find a suitable method to bind to statically and late binding is otherwise allowed. In this case the type of the variable is Object and hence Object.ToString() can be bound to statically and indeed that’s what happens in this case. Further in VB.Net it’s possible to call a method that has no parameters without parens: ex i.ToString is legal. This results in the (“c02”) portion of the expression being interpreted as an indexer expression into the resulting string. Because Option Strict is off the compiler allows a silent narrowing conversion between String and Integer. The result of all of this is the code is actually evaluated as

    Sub Main()
        Dim i As Object = 100
        Dim result = i.ToString()(CInt("co2"))
    End Sub

I certainly found this interesting the first time I encountered it.

[1] Please don’t confuse me saying an issue is “By Design” with me thinking the behavior is ideal. It’s merely a statement that the behavior conforms to the specification at the time of this writing.

Why the debugging difference between C# and VB.Net return values?

JaredPar MSFT — Wed, 12 Jan 2011 13:00:00 GMT

A feature which seems to be getting more requests recently is support for seeing the return value of a function in the debugger without the need to assign it into a temporary. C++’s had this feature for some time but it’s been lacking in managed debugging scenarios. James Manning recently dedicated a couple of blog posts to the subject and noted that the feature appears to already partially exist for VB.Net

“With VB.NET, the function name shows up as an entry in ‘Locals’ and the debugger shows us the value it’s returning! The C# debugger has no such support, though – at the same ‘end of method’ breakpoint, only the parameter passed in is shown. So, clearly the CLR has enough support for the VB.NET debugger to support this feature, which would seem to be a pretty strong argument that the C# debugger certainly could implement this feature.”

Indeed C# could implement this feature but it’s not a CLR debugging feature that VB.Net is relying on but is rather an issue of VB6 legacy support. The VB6 language didn’t have a return statement. Instead values were returned by assigning the value to be returned to the name of the function. For example

    Function IsEven(ByVal i As Integer)
        If i Mod 2 = 0 Then
            IsEven = True
        Else
            IsEven = False
        End If
    End Function

While VB.Net added a Return statement it still supports this legacy syntax (and it allows the two to be mixed within a single function). The compiler models this by having a local of the same name of the function which is used to store the return value. Returns from the function are rewritten as assignments to this local and then a return of the same local. The debugger understands this hidden local and displays it during the debugging session. This gives VB.Net the appearance of supporting Return value display when in reality it’s just a positive side effect of legacy support.

Quick Note: In my experience when users ask for return value support in the debugger they typically want to see both

The return value of the current function they're stepping through
The return value of functions which are stepped over (more heavily requested)

VB.Net supports only the first one (via the described method) and C# supports neither.

I do agree it would be really nice if both languages supported #2 (it’s an incredibly useful feature in C++). It is possible to do without CLR support but it involves the compiler generating a temporary for every function / property evaluated in a statement and lots of copying values around. This can have a non-trivial impact on program performance even when not debugging and hence I think is unlikely to be done. If #2 does come around it will likely be through the CLR debugger APIs providing access to the return values much in the way it provides access to the current exception.

Advanced Multitargeting in VB.Net

JaredPar MSFT — Fri, 23 Jul 2010 12:00:00 GMT

Multi-targeting is a feature introduced in Visual Studio 2008 which allows developers to use new versions of Visual Studio to target earlier versions of the .Net platform. It allowed users to target both the new 3.5 and 3.0 and the previous 2.0 profile with the same IDE. Visual Studio 2010 continues this trend by adding support for CLR 4.0 and even allows for further sub-targeting through several framework profiles.

At a compiler level this works by providing binary compatibility with previous versions of the CLR (or producing an error when it’s not possible). It doesn’t warn developers about using new language constructs on older frameworks so long as they function in the target framework.

Take the following code sample as an example. It is taking advantage of implicit line continuations which is a feature introduced in VB.Net 10 and not available in Visual Studio 2008. Since it’s just syntactic sugar it compiles just fine in an application targeting 4.0 or any previous version of the framework.

Dim query =
    From it In col
    Where it Mod 2 = 0
    Select it * 3

In a limited set of scenarios though developers want to use Visual Studio 2010 to develop code which will also be compiled by a previous version of the compiler. Hence they want warnings in Visual Studio when new language constructs are used.

The 10.0 version of vbc.exe introduced a new switch named langversion to provide just that. It allows developers to specify a version of the language to target. The compiler will then issue an error when a language construct which was introduced in a later version is used. This switch is not available from the IDE though and must be manually specified in the project file. To do so edit the .vbproj file and add the following element under the main ItemGroup element.

  <PropertyGroup>
    <LangVersion>9</LangVersion>
  </PropertyGroup>

Once the project is reloaded errors will start appearing for new language constructs. Notice how our earlier sample now produces the errors for the usages of the new implicit line continuation construct.

Why is LINQ absent from debugger windows (Part 2)?

JaredPar MSFT — Wed, 02 Jun 2010 12:00:00 GMT

Some readers may remember an article I published almost half a year ago about LINQ being absent from the debugger windows. That post explored the initial design of the feature, it’s limitations and ultimately why it was absent but promised a future article on a slightly different approach. It’s quite late but I’ve finally had some time to write the second part of this article [1]

No, I didn’t forget about the article or really get too lazy. The pace of Dev10 really picked up shortly after publishing that article and the follow up was put on the back burner. This week I finally find myself with a bit of free time and decided to follow up on my promise.

First a quick refresher. Features in the Expression Evaluator are started on the basis of having complete parity with the feature as it exists in the language and then paired down based on cost. Having complete parity with LINQ is prohibitably costly due to it being much more of an ENC expression instead of an inspection one (the latter being the primary purpose of an expression evaluator). Now comes the compromise phase.

As stated in the previous article the most expensive portion of this design is adding ENC support to the Expression Evaluator. ENC is necessary for true parity because closures in C# and VB.Net are mutable and requiring altering program state to implement. The standard example is evaluating the following expression in the EE which modifies the value of a local variable.

((Action)(() => { local1 = 42; }))();

Properly implementing this requires program mutation not just inspection.

Now comes the compromise. How often do users really want to do this? In my observations the answer is rarely if ever. When I talk with customers about LINQ in the debugger windows almost every single answer comes down to allowing filtering / where expressions. These are inherently, but not strictly, non-mutating operations.

list.Where(x => x.Name == "Jared");

Cutting mutation is a huge advantage because we can forget about the impact into existing closures and alteration of program structure. Instead we can generate new closures which copy the initial state of the values and work from there. This removes all of the state tracking problems examined in the previous article.

If we cut mutation, and hence ENC, we can move to a different approach for generating code. Instead of generating all of the types and methods in the current assembly with ENC, create a generated assembly in the target process which contains the new types and methods. This can be done through existing technologies like Reflection.Emit.

So How does that change the cost of the feature? If we look at the major feature list discussed in the previous article we’d only be left with the following

A metadata generation service to support the backing for closures and lambda expressions
Converting expressions typed in the EE to IL

Lets take a deeper look at this given our new proposed architecture.

Metadata Generation Service

The debugger and expression evaluator live in a different process than the debugee. Any generated lambda expression needs to be done in the debugee process. Yet all of the information needed to create the lambda exists in the debugger process. Implementing this feature requires that all of this data to be transferred between the processes. In effect we’d have to serialize both the metadata and IL of the trees and send them across the process boundary.

Creating a DLL to host the service, defining the interfaces and calling them from the EE all have costs. Yet many of these are done on every release and the cost is very much understood. Due to the regularity with which we do this we can cost this part with high confidence.

What’s expensive here is defining the format for the data transfer. Today we don’t directly generate IL in our compilers but instead use services exposed by the CLR to do so. We would need to define a new serialization format for transferring our representation of trees to the debugee process, deserializing this in the debugee and converting it to metadata and IL. This is actually very costly when you consider all of the details

Needs to work in both a 32 and 64 bit environment
The sheer amount of data as the number of nodes in our trees is quite large
Data is transferred from a native process to a managed one so the structure for serializing data gets defined twice
Versioning:
- This service must support both the current and new versions of the EE
- The serialization format must be able to handle the changes we make to our nodes over the course of several releases
Performance

Of all of these “versioning” is the biggest cost. All to often we don’t consider versioning when designing EE features and it comes back to haunt us in the long term. To implement such a large feature and not consider the versioning aspects would be a huge mistake.

The lack of previous work in this area and the overall size produces a feature with a high cost which has low confidence. Not what a manager wants to hear.

Converting Expressions in the EE to IL

The expression evaluator does not actually compile expressions down into IL. Instead it compiles it down to a low level semantic tree which is then directly interpreted by the expression evaluator.

This approach grants a lot of flexibility to the EE and allows us to evaluate expressions that are not necessarily valid at the current place in the program. For example the ability to directly evaluate object id expressions. This flexibility hurts us here because it creates a subset of expressions which are not, or at least very difficult to, translate to IL. How would an object id expression for instance be expressed in IL?

The problem is not just limited to object id expressions but also include a host of other items allowed in the EE. There are too many to list in this article but suffice it to say this is not a trivial problem to solve [2]. Any cost for this area would have at best a medium level of confidence.

The next problem with this approach is that our infrastructure which generates IL is heavily geared towards doing so for EXEs and DLLs. It has been so for every release of our code base and contains a lot of code very specific to this process. Converting this to be more general purpose is very costly at this point. It would entail almost a complete rewrite of those components.

Once again this cost in itself is not prohibitive but does add up. Really it amounts to a known type of refactoring with medium to high confidence.

Wait there’s more: Don’t forget testing

There are two costs to consider for the testing of this new feature. The first is the straight forward costs you get with any new features. This is a pretty standard and well understood process. The language side of the feature is not too difficult to test. The cost really starts adding up though when you consider all of the other parts which can go wrong: loading DLL’s into the process, 32 / 64 bit issues, making sure all instructions serialize, versioning, etc …

The second more hidden cost though is the impact of this new feature on existing ones. Consider again that today all expressions typed into the EE are interpreted. However with our current design if the expression was inside of a lambda expression it would be executed not interpreted. This is a completely different process and would require a completely different set of tests to verify it’s functionality.

In effect this would double the cost for QA for all existing features as they’d need to be tested inside a lambda expression. This is an enormous cost and one that cannot be ignored.

In summary

Here is a summary of the larger cost items

Define a version friendly serialization format for transferring metadata and IL across the native and managed boundaries
Implement both the native serializer and managed deserializer for this format
Implementing a metadata generation service
All of the work around getting this DLL into the target process
Finding solutions for generating IL for all expressions which don’t directly map to IL
Refactoring our existing compiler infrastructure to be friendly to generating IL for the EE
QA costs for testing this feature
QA work to double test every type of expression (inside and outside of a lambda)

This doesn’t take into account a lot of the smaller items I’ve ignored [3] or the items we’d only find once we started implementing. This is after all a very large feature and those always have hidden costs that aren’t found until implementation hits a certain point.

I’m very hesitant to put a strict time estimate on this feature (it would almost certainly be wrong given the hidden costs and the lack of confidence in estimating several areas). To put it in a bit of context though, I would estimate it as large and likely larger than any other feature I’ve worked on since I joined Microsoft.

Once again I’m not writing this blog post to justify why we won’t ever implement LINQ debugging. Instead I write this to justify why we haven’t done it up till this point. This is a feature which has clear customer value and a fair bit of demand and I want to help customers understand our decision making process in this area.

I’m still very hopeful this feature will make it into the product at a future release. Perhaps we’ll find a cheaper route we’re not currently considering. Or maybe a future feature we need will offset some of the costs here.

[1] This gap is certainly a personal record and one I hope to never beat

[2] One day I may write about these items because pretty much all exist to support a richer user experience.

[3] Anonymous types, transparent identifiers and VB generated delegates for starters

Nothing is private in the debugger (part 2)

JaredPar MSFT — Wed, 19 May 2010 12:00:00 GMT

In a previous post I discussed how accessibility is ignored when evaluating expressions in the debugger and the unexpected scenarios that it creates. One case I neglected to mention in that article is how this behavior works with the VB late binding engine.

The expression evaluator only relaxes accessibility rules when binding an expression. This is possible because the expression evaluator effectively hosts the compiler and can override items like accessibility checks.

In the case of late binding the compiler only participates in building an expression that will call into the VB runtime late binding engine. The accessibility determination for the target of late bound call occurs in the VB runtime and is not (currently) overidable by the expression evaluator.

Late bound access combined with static access can lead to additional confusing behavior. For example.

Class C1
    Private Field1 As Integer
    Public Property Property1 As Integer
End Class

Module Module1

    Sub Main()
        Dim v1 As New C1
        Dim v2 As Object = v1
        Stop
    End Sub

End Module

When the following code is run, all members are accessible from the v1 local. It is statically typed to C1 and hence the expression evaluator can ignore accessibility and access the values.

The local v2 references the same object instance so it’s reasonable to assume it can access the same values. However because it’s statically typed as object, calls like v1.Field1 actually turn into late bound calls and hence are subject to the rules of the late binder.

Evaluation of Field1 fails here because the late binder does not allow access to private fields. Property1 evaluates just fine though because it’s public.

We are considering changing this behavior in a future release. As usual no promises.

Nothing is private in the debugger

JaredPar MSFT — Mon, 17 May 2010 12:00:00 GMT

The goal of the debugger is to provide rich inspection capabilities for a process. The main method of inspection is through the evaluation of textual expressions which is handled by a language specific component known as the expression evaluator. This component is the data provider for a good portion of the debugger windows (watch, locals, autos, etc …)

The expression evaluators go to great lengths to ensure that expression in the debugger evaluate exactly as it would if the expression was typed at the current place in the file where the debugger was stopped. To do otherwise only leads to user confusion. Often making it harder to track down the issue you’re currently debugging and resulting in a loss in faith in the quality of the debugger and language.

Occasionally, or not so occasionally, the goals of providing high fidelity in evaluation and rich inspection conflict. When this occurs we have to weight the tradeoffs of confusing users by changing the semantics of the language vs. the resulting increased capabilities in the debugger.

One example is accessibility. Languages have strong notions of accessibility which is enforced by the compiler and CLR. In order to provide rich inspection though the debugger must be able to access all available data including items which are not accessible by the language. To do otherwise might arbitrarily hide that one piece of data a developer needs to solve the problem at hand. Hence accessibility is one case where the expression evaluators bend language rules and allow expressions to access data without accessibility checks.

One the surface this doesn’t seem like a big change. It’s an additive change allowing users to see more fields, properties and methods. In the majority case it’s as simple as that and leads to little confusion.

However even seemingly simple changes like removing accessibility checks can lead to very surprising behavior for our users. Recently our QA team filed a bug that illustrates this point.

Module Module1
    Class Base
        Private Field1 As Integer = 55
    End Class

    Class Derived
        Inherits Base
        Sub Method1()
            Field1 = 72
            Stop
        End Sub
    End Class

    Sub Main()
        Dim x As New Derived
        x.Method1()
    End Sub

End Module
Module Module2
    Public Field1 As Integer
End Module

QA noted that if they ran this code and typed Field1 in the watch window that the value showed 55 instead of 72. This was noted as a bug because Field1 was set to 72 on the line before.

Interestingly enough though is that this behavior, while very confusing, is actually “By Design”.

The reason why is that when evaluating expressions in the debugger nothing is private. Knowing this reconsider what it means to evaluate Field1 inside of Method1 with both instances being Public. The correct binding is Base::Field1 since the VB language prefers instance fields over Module fields if they are both accessible. The expression evaluator correctly evaluates this as 55.

However when the code was compiled accessibility checks were in place. This mean that Base::Field1 was not considered since it was private and inaccessible. The compiler instead correctly bound to Module2::Field1 and this is the field which is used when the code is running. Developers can verify this by evaluating Module2.Field1 in any of the debugger windows.

The many cases of ByRef

JaredPar MSFT — Thu, 21 Jan 2010 13:00:00 GMT

One of the overlooked or simply misunderstood features of the VB language is calling a function which has a ByRef parameter. Most languages support only a single method of passing parameters by reference [1], that is the scenarios directly supported by the CLR. The CLR has a lot of restrictions on the type of values it supports for ByRef parameters and these restrictions get in the way of VB’s goal to be a flexible language that strives to get out of the way of the user. Hence the compiler goes to great lengths to be flexible and support multiple avenues of ByRef passing, much beyond what the CLR natively allows.

This article will explore these different mechanisms. In order to reduce the code samples, I will be using the following 2 methods to explain the different mechanisms of ByRef Passing

    Sub FunctionWithInt(ByRef p1 As Integer)
        p1 = 42
    End Sub
    Sub FunctionWithObject(ByRef p1 As Object, ByVal p2 As Object)
        p1 = p2
    End Sub

CLR ByRef

The first is to simply use the CLR concept of passing by reference as defined by section 12.4.1.5.2 and 12.1.6.1 of the CLI specification. Any variable which meets any of the following criteria, does not require a type conversion, and is passed to a ByRef parameter will be passed directly in the CLR.

Argument of the current method
Local variable
Member Field of an object
Static Field
Array Element

No special code is needed or generated for this scenario.

Copy Back ByRef

While the CLR method of passing ByRef is very flexible, it disallows a number of useful scenarios. The most prominent of which is properties. Properties do not meet the CLR requirements for ByRef because under the hood they are simply a pair of function calls. The result of a function call cannot be directly passed by reference.

Without any language intervention this can be very confusing to users. Properties are very often simple get/set wrappers around fields and have almost the exact same usage scenarios. To the point that most users don’t see a functional difference between the two. Auto-implemented properties blur this line even further. Not being able to pass them ByRef creates an unacceptable inconsistency in their usage.

VB removes this inconsistency and allows properties to be passed by reference. This is implemented under the hood by means of a temporary variable. Temporaries are just local variables and hence can be passed by reference. The property value is assigned to a temporary which is then passed by reference and then after wards is copied back into the original property.

For example, take the following code sample

    Class C1
        Public Property P1 As Integer
        Public P2 As Integer
    End Class
    Sub CopyBackByRef()
        Dim v1 = New C1
        FunctionWithInt(v1.P1)
    End Sub

This will result in essentially the following code being generated

    Sub CopyBackByRef_Explained()
        Dim v1 = New C1
        Dim vbTemp = v1.P1
        FunctionWithInt(vbTemp)
        v1.P1 = vbTemp
    End Sub

This type of ByRef passing is used in the following 2 scenarios

The value is a Property containing both a getter and setter.
Passing the value to the function requires a conversion.

The first can be done with even the strictest Option settings. However #2 can only be used with Option Strict Off because it requires an implicit narrowing conversion.

Don’t Copy Back ByRef

So far we’ve only looked at scenarios where the user wants to actually see the value returned from the ByRef parameter. There are many scenarios where the language can infer the user does not care about the return value of the function. For example, what if I just want to pass a constant value?

    Sub DontCopyBackByRef()
        FunctionWithInt(42)
    End Sub

This code is legal in VB and represents another method of passing by ref. This is very similar to the copy back method of passing by reference. The only difference is that it never copies the value back. It essentially generates the following code

    Sub DontCopyBackByRef_Explained()
        Dim vbTemp = 42
        FunctionWithInt(vbTemp)
    End Sub

This type of ByRef is used in any scenario where the value being passed cannot be assigned to. For example

The result of function calls
Read Only Properties
Constant Values

Maybe Copy Back ByRef

Up until now we’ve examined cases where the compiler can examine both the value being passed and the parameter it is being passed to and make a determination about what direction the data needs to move in. What about late binding?

    Sub MaybeCopyBackByRef()
        Dim v1 As Object = Me
        Dim v2 = 13
        v1.FunctionWithInt(v2)
    End Sub

Here v1 is typed to object and hence FunctionWithInt is being accessed via late binding. In this case the compiler doesn’t know the actual method being invoked runtime. Hence it cannot know up front if the parameters are ByRef or ByVal and cannot make an up front decision on the variable passing mechanism.

In order to make late binding invokes flow as smoothly as normal method invokes, the compiler will generate code to conditionally update the original value based on the runtime information about the parameter. The late binder communicates this information via an array of Boolean values, one for each parameter passed to the function. The compiler will initialize this array with true for any values it knows are updatable and false for values that are not. The late binder will then examine every parameter to the function and set the corresponding index in the array to false if the method parameter is ByVal. If it is ByRef the returned value from the function will be copied back into the original parameter array.

The resulting code looks a bit like this. You can ignore all of the Nothing values as they are not important for this discussion.

    Sub MaybeCopyBackByRef_Explained()
        Dim v1 As Object = Me
        Dim v2 = 13
        Dim parameters = New Object() {v2}
        Dim isByRef = New Boolean() {True}
        NewLateBinding.LateCall(v1, Nothing, "FunctionWithInt", parameters, Nothing, Nothing, isByRef, True)
        If (isByRef(0)) Then
            v2 = CInt(parameters(0))
        End If
    End Sub

[1] Starting with version 4.0, C# now supports two versions of reference passing. In addition to the one available since 1.0 the ref modifier is now optional when making an interop call to a COM object: http://mutelight.org/articles/new-features-in-c-sharp-4.html

Dev Connection Talk Slides and Code

JaredPar MSFT — Wed, 02 Dec 2009 21:21:45 GMT

Thanks to everyone who attended my sessions at Dev Connections. I’ve posted the material for both of my talks on my SkyDrive account. This includes the slides and projects.

http://cid-dc25b20f65f628f8.skydrive.live.com/browse.aspx/Public/DevConnections2009

Please let me know if you have any questions or problems with the materials or any additional feedback about the sessions.

Speaking at Dev Connections in Las Vegas Next Week

JaredPar MSFT — Tue, 03 Nov 2009 16:51:04 GMT

Next week I will be speaking at Dev Connections in Las Vegas. I will be running the following sessions

VMS02: Future Directions for Visual Basic
VMS04: Microsoft Visual Basic IDE Tips and Tricks

Both of these talks will spend a bit of time talking about all of the progress and exciting new features we’ve added in Dev10. Given I primarily work on the IDE these days, expect a bit of IDE content to work it’s way into the Future Directions talk as well.

Why is LINQ absent from debugger windows?

JaredPar MSFT — Wed, 26 Aug 2009 15:00:00 GMT

As the owner of the VB.Net portion of the overall debugging experience, I frequently hear the request from customers to add LINQ support into the Watch / Immediate and Locals window. Virtually every other type of expression is available in the debugger windows so why leave one of the most popular ones out?

Quick Diversion: the specifics of this article are written from the point of view of the VB.Net expression evaluator. However, the limitations blocking LINQ support (in both the architecture and overall design) are very similar between VB.Net and C#.

As usual, the primary issue is cost and the cost for LINQ in the debugger windows is very high. To understand why the cost is so high though, we must start by getting a better understanding how a language service interacts with the debugging services of Visual Studio and the general philosophy around compiler features in the debugger.

Languages in Visual Studio typically provide the following major components to support the debugging experience.

Expression Evaluator (EE): This is the language specific component which provides all of the data used in the watch, locals and immediate window, data tips, conditional breakpoints and several other components. It’s primary input is an expression in string form which is converted to a value (typically an ICorDebugValue instance) and outputs a COM object capable of inspecting that value to the core debugger [1]. Everything typed into the debugger windows goes through the EE.

This component lives in the MTA of Visual Studio and has almost no interaction with the UI / STA thread.
ENC Service: This is the component which is the work horse of ENC operations. It provides rude edit detection, metadata differencing and metadata + IL generation .

This component lives in the main STA of Visual Studio

The important thing to understand about the expression evaluator is that it’s purpose is primarily to provide an expression evaluation and data inspection service. How expression evaluation works is an article in itself but suffice it to say that it converts the string to a very low level AST then walks the nodes bottom up and evaluating the expressions using the ICorDebug APIs. The EE component has no UI and is simply a data provider for the core debugger services.

The design philosophy for Both VB.Net and C# is to have the highest level of fidelity between expressions evaluated in the EE and the actual running program. To do otherwise would lead to extremely confusing results for users. When spec’ing feature support in the VB.Net EE we start from the point of 100% fidelity, determine the problems with this design (if any) and then start the difficult process of making compromises.

LINQ expressions are very different than any other expression previously allowed in the EE window because of the features interaction with metadata. All LINQ expressions require the generation or manipulation of metadata to support the underlying lambda and/or closure. Adding support for this is one of the biggest hurdles to getting LINQ (and other features) into the EE.

Evaluating a LINQ expression is actually much closer to an ENC operation than a traditional EE one.

Currently the EE’s have no capacity for generating metadata, only interpreting it. Operations which mutate or generate metadata have traditionally only been allowed via the ENC service. Getting LINQ to work in the EE with true fidelity would require at least a minimal amount of ENC feature work.

Without getting into too much detail, lets enumerate the new major features necessary to evaluate a LINQ expression in the EE with true fidelity to the running program. To simplify things, we’ll start by assuming there is no other LINQ expression used in the current method and the method is only being executed at most once at any given time in the process.

A metadata generation service to support the backing for closures and lambda expressions
Convert expressions typed in the EE into IL [2]
ENC support for metadata to push the new metadata for closures and lambdas into the currently executing assembly
ENC support for method body IL to remove lifted variables from the current method and redirect the references inside the closure

Issues #1 and #2 are for the most part internal architecture issues and can be solved via normal processes of code base refactoring and adding new features to an existing component. I don’t mean to imply these problems are cheap (in fact they are relatively expensive) But fixing these is somewhat of an understood quantity.

Issues #3 and #4 are where the problems start. As implemented EE’s do not have capability to create or modify metadata in the running process (that is the job of the ENC service). EE’s do have access to the underlying CLR ENC APIs so it is possible to implement ENC operations in the EE. It’s just simply not been done yet.

Wait! Why not reuse our ENC implementation in the EE? Unfortunately the ENC service is currently tied heavily to our in memory IDE compiler and many other IDE / STA features. It in fact lives in a completely separate DLL, separate COM apartment and works on a different symbol table than the EE.

More fundamental though is that it’s designed for a completely different purpose. ENC is designed to track edits in live code, determining the differences and applying them to the running program. The hypothetical EE feature would be tracking expressions that modify a running DLL for which code is not guaranteed (and not likely) to be available and applying the difference to the running program. There are some similarities but the differences are significant enough to make code reuse have limited value.

Some people may wonder why it’s necessary to implement #4. Couldn’t we just avoid removing the variable from the current method and make the feature cheaper? This is possible but it would cause a significant fidelity difference in the feature. Any mutations of the local variable within the LINQ expression would not be visible on the stack frame as it would if the LINQ expression was present in the original program.

It’s easy to think of this ENC in the EE as just the same type of cost as #1 and #2 (in many ways it is). However taking advantage of the CLR ENC APIs in the EE also means that we inherit it’s limitations as well. ENC as as implemented in the CLR has many limitations which fly in the face of LINQ. In particular the following ENC limitations present major problems (ENC limitations reference).

Cannot add members to a value type. This prevents evaluating LINQ when stopped in a value type method
Cannot remove locals from a function. This is an implementation of LINQ but we could work around this problem by changing the IL to simply no longer accessing the local variables.
Cannot change anything in a generic type. This prevents evaluating LINQ when stopped in a generic type.
Cannot specify an initial value for newly added fields.
Allowable ENC operations differ between the top of the stack and operations elsewhere within the stack
Modification of a non-top stack frame cannot significantly edit the current function call. So if a LINQ expression captures a variable used in that call (think ref passing) it would likely be unable to be evaluated.

So even if we implemented everything possible on the language service side the resulting feature would be limited in several impactful ways. Additionally these limitations are somewhat orthogonal to the current limitations EE’s face and would require a bit of user education. And this is only for the most basic LINQ feature under unrealistic scenarios.

Lets now consider the problems of evaluating a LINQ expression when the current method already contains a LINQ expression that lifts at least 1 variable. Evaluating a new expression at the same scope would require the modification of the current closure to maintain fidelity as opposed to generating a new one. This brings along with it a couple more problems.

A lambda expression which uses 2 variables, 1 of which is captured in an existing lambda expression. To maintain fidelity we would have to modify an existing closure signature to contain the new variable.

Often times generated closures are generic so we would run straight into ENC limitation #3. Additionally we would need the newly added field to have the same value as it has in the current method which runs us into ENC limitation #4. Now also consider that a closure instance can live much longer than the method in which it was created. For those closures no stack value is available so what value should we give fields in that instance? Ideally it should have the value of the variable at the point the method exited but realistically that’s not possible.
A lambda expression which uses 1 variable in a method where an existing lambda expression captures that same variable and another. To maintain fidelity we would have to know about this and fake capture the second variable as well.

Now consider all of the problems above and consider the scenario where there are multiple threads and multiple instances of the current method active in the program. How to determine which closure instance belongs to which thread, and just as important which stack frame on which thread, with respect to initializing values?

None of the issues are an unsolvable problem but they do represent a significant cost to the feature. And once again even if we added all of these features to the EE, ENC limitations would significantly limit the usefulness of the resulting feature.

Does this mean that LINQ, or any future metadata requiring expression, will never be added to the debugger window? Absolutely not. We’ve just hit the difficult stage of making compromises on the level of fidelity in the feature. If you back off of true fidelity in a few small ways the resulting feature, while still very expensive, is significantly cheaper and removes many of the limitations imposed by ENC. This hypothetical feature will be discussed in my next article.

[1] For those interested the returned interface is IDebugProperty2

[2] Right now expressions are converted to a tree form slightly above IL and they are interpreted using the ICorDebug APIs. Converting all the way down to IL requires a lot more work

Extension Methods and ByRef targets

JaredPar MSFT — Thu, 11 Dec 2008 16:00:00 GMT

One of the seldom used, and often unknown, features of VB extension methods is that the argument of the extension method (the first parameter) can be passed by reference. This gives extension methods the power to change the reference that was used to invoke the value!

Obviously this can produce unexpected but often amusing behavior. The following sample prints “False”.

    <Extension()> _
    Public Sub EnsureNotNull(ByRef str As String)
        If str Is Nothing Then
            str = String.Empty
        End If
    End Sub

    Sub Example(ByVal p1 As String)
        p1.EnsureNotNull()
        Console.WriteLine("{0}", p1 Is Nothing)
    End Sub

    Sub Main()
        Example(Nothing)
    End Sub

I think people will look at this example and either cringe, call it terrible code or get excited. Personally I’m somewhere between cringing and getting excited (in fact I’m doing both). But before people think I’ve gone off the deep end I don’t plan on checking this in any time soon (and yes I think it’s a bad idea).

Why? The feature is fun to play with and can create some interesting samples but it can also just as easily lead to very bad and unanticipated behavior. For instance what if instead of making sure something wasn’t Nothing, the code made the argument Nothing?

<Extension()> _
Sub EvilMethod(ByRef p1 As Object)
    p1 = Nothing
End Sub

Sub Example2()
    Dim s As New Student()
    s.PrintClass()
    s.EvilMethod()
    s.PrintName()   ' Causes a NullReferenceException
End Sub

The code runs and throws an exception. A developer attaches a debugger, looks at the exception but immediately notes there are 2 other method calls just above. How could they succeed but the last throw a NullReferenceException??? Certainly this may be a fun joke but in production code a fellow developer would not be amused.

More importantly though the behavior when passing an extension method target by reference is flat out unexpected. Who expects what appears to an instance method call to be able to modify “Me/this?” Probably not too many people. Coding is difficult enough without creating patterns that will blow away anyone who owns your code down the line. Code should do it’s best to be clear and produce predictable results.

Still, an interesting feature to toy with.

Properly handling a WinForms Timer event

JaredPar MSFT — Mon, 27 Oct 2008 15:00:07 GMT

The WinForms Timer class allows the user to perform a particular action at a set interval. Timer objects fire a Tick event at the set time which users can easily respond to. This is very useful if a developer wants to check for a particular condition say every 2 seconds ( for the remainder of this article I'm going to use 2 seconds as a practical example even though it's really any arbitrary time period).

Occasionally users are surprised to find that the Tick event will fire much faster than they are expecting. Instead of waiting for 2 seconds between calls, they event will fire almost immediately after one is finished processing.

What's going on here is a side effect of how this event works under the hood. The interval for the timer event is calculated in real world time. So quite literally every 2 seconds Windows will consider the internal reached and will issue a new tick message. The next time a WinForms event is not executing developer code a tick event is raised [1].

So imagine we had the following code.

Private Sub OnTimerTick() Handles m_timer.Tick
    RunSomeOperation()
End Sub

Consider what happens if RunSomeOperation takes longer than 2 seconds. The Tick event is fired in real time so while we're in the middle of RunSomeOperation, another Tick event is being queued up for processing. As soon as we leave OnTimerTick we're back in WinForms code which sees a Tick event and promptly raises it which puts us right back in OnTimerTick.

This is contrary to what most people expect. Most people expect the Tick event to fire 2 seconds after their code is finished executing.

To work around this developers should stop the timer when processing a timer event. Just before exiting the event handler, re-enable the timer. This will cause Windows to start calculating the interval from the start. This has the effect of making the timer event fire 2 seconds after developer code stops executing.

Private Sub OnTimerTick() Handles m_timer.Tick
    m_timer.Stop()
    Try
        RunSomeOperation()
    Finally
        m_timer.Start()
    End Try
End Sub

[1] This is not 100% true. It's really whenever the Application begins to pump messages again. Message pumping, more specifically when it does and does not occur, is too involved for this discussion.

VB Catch ... When: Why so special?

JaredPar MSFT — Thu, 09 Oct 2008 15:00:00 GMT

The VB Catch syntax has a particular feature not present in C#: When. It allows users to filter expressions based on something other than their type. Any arbitrary code can enter a When block to decide whether or not to handle an Exception

    Sub Sub1()
        Try
            DoSomeAction()
        Catch ex As Exception When Filter(ex)
            Stop
        End Try
    End Sub

Newsgroups often ask, "Why's this so special? I could effectively get the same behavior out of C# by doing the following."

static void Sub1()
{
    try
    {
        DoSomeAction();
    }
    catch (Exception ex)
    {
        if (Filter(ex))
        {
            throw;
        }
        HandleException();
    }
}

This is true to an extent. In both cases the code is handling an exception and making a decision, via calling Filter, as to whether or not to handle the exception. The subtle difference is when the Filter method is called.

In VB the When statement is actually implemented as an IL exception filter. When an exception is thrown, exception filters are processed before the stack is unwound. This means that if the Filter method created an error report that included the current stack trace, it would show the frame in which the exception occurred.

For example, in the code above if DoSomeAction() threw and the stack was examined in the Filter expression, the following stack would show up.

Notice how the DoSomeAction method is clearly visible? This is incredibly powerful for features like error reporting and investigation. It also allows you to set powerful breakpoints where the exact state of the error can be examined and not just the post mortem.

Alternatively, code executed in the C# block will occur after the stack is unwound. This gets rid of the culprit. As long as your not in optimized code you can usually use the stack trace properties to get the source of the exception but you won't be able to examine the live state of the error.

First MSDN article

JaredPar MSFT — Mon, 18 Aug 2008 15:00:10 GMT

The August issue of MSDN magazine will be carrying an article I wrote this spring. In it I toy around with using the deferred execution and lazy evaluation properties of LINQ to create more responsive UI code.

You can view the article here.

As usual I appreciate any feedback you have.

Making Equality easier

JaredPar MSFT — Tue, 03 Jun 2008 15:00:10 GMT

Recently I've done a bit of posting about the difficulties of properly implementing equality in VB (and DotNet in general). While most of the problems can be fixed with a standard snippet the one really hard to implement issue is GetHashCode(). The rules for GetHashCode() are both simple and seemingly contradictory

If two objects are equal (via Equals) their GetHashCode() should be equal
GetHashCode() shouldn't ever change

These rules imply that GetHashCode() is related to Equality. At a fundamental level though GetHashCode has nothing to do with Equality. Instead it is linked to bucketing and ultimately any hashing sturcture such as Dictionary, Hashtable, etc ...

Unfortunately it is impossible to separate these two from an API perspective because it is ingrained into the BCL. There is a way to separate this out at a functionality level and still satisfy all of the rules of the GetHashCode() and Equals()

    Public Overrides Function GetHashCode() As Integer
        Return 1
    End Function

This absolutely maintains both of the rules for GetHashCode(). This allows you to completely separate Equality and GetHashCode() in your implementation while not breaking any BCL rules or assumptions.

Of course this does come with a trade off. As said before GetHashCode() is primarily used as a bucketing mechanism. It will cause the performance of bucketing collections such as Dictionary or Hashtable to drop from close to O(1) to O(N). But once again this is not a bug but a conscious trade off.

Equality isn't easy

JaredPar MSFT — Mon, 12 May 2008 15:00:20 GMT

After my recent postings on the rules of Equality, I thought it would be a good idea to post a simple example of equality. The class in question, Example, has only one field of type Integer name m_field1. Two instances of Example are equal if m_field1 has the same value. So the real equality check is just a single Integer comparison.

Unfortunately, as my posts alluded to, even though the check is simple getting it right is not necessarily so. The equality portion of example takes roughly 20 lines of code while the actual equality check represents only 1 of those lines [1]. Not a good ratio. The good and bad news about the other 19 lines is they are boiler plate so once you know them you don't have to think about them. For my own purposes I've converted those 19 lines into a snippet which automates the process but doesn't make it any easier on the eye.

Class Example
    Implements IEquatable(Of Example)

    Private ReadOnly m_field1 As Integer
    Public Sub New(ByVal field As Integer)
        m_field1 = field
    End Sub

    Public Function Equals1(ByVal other As Example) As Boolean Implements System.IEquatable(Of Example).Equals
        If other Is Nothing Then
            Return False
        End If

        Return m_field1 = other.m_field1
    End Function

    Public Overrides Function Equals(ByVal obj As Object) As Boolean
        Return Equals1(TryCast(obj, Example))
    End Function

    Public Overrides Function GetHashCode() As Integer
        Return m_field1.GetHashCode
    End Function

    Public Shared Operator =(ByVal left As Example, ByVal right As Example) As Boolean
        Return EqualityComparer(Of Example).Default.Equals(left, right)
    End Operator

    Public Shared Operator <>(ByVal left As Example, ByVal right As Example) As Boolean
        Return Not EqualityComparer(Of Example).Default.Equals(left, right)
    End Operator

End Class

Module Module1

    Sub AssertTrue(ByVal cond As Boolean)
        Debug.Assert(cond, "failure")
    End Sub

    Sub AssertFalse(ByVal cond As Boolean)
        Debug.Assert(Not cond, "failure")
    End Sub

    Sub Main()
        Dim v1 As New Example(1)
        Dim v2 As New Example(2)
        Dim v3 As New Example(1)

        AssertFalse(v1 Is v2)
        AssertFalse(v1 Is v3)
        AssertTrue(v1 Is v1)
        AssertFalse(v1 = v2)
        AssertTrue(v1 = v3)
        AssertFalse(v1 = Nothing)
        AssertFalse(Nothing = v1)
        AssertTrue(v1 <> v2)
        AssertTrue(v1 <> Nothing)
        AssertTrue(EqualityComparer(Of Example).Default.Equals(v1, v3))
        AssertFalse(EqualityComparer(Of Example).Default.Equals(v1, v2))
    End Sub

End Module

[1] Before VB criticism enters, C# has roughly the same ratio for the same sample.

IEquatable(Of T) and GetHashCode()

JaredPar MSFT — Fri, 09 May 2008 15:00:53 GMT

This is a bit of a follow up to a previous post we discussed how to properly implement equality in VB. Several users commented/asked that IEquatable(Of T) could be used in place of overriding Equals(). Since IEquatable(Of T) doesn't define a GetHashCode() method the user didn't need to define it and hence run into all of the problems associated with GetHashCode() usage.

Unfortunately this is not the case. Several parts of the framework link IEquatable(Of T).Equals and Object.GetHashCode() in the same way that Object.Equals() and Object.GetHashCode() are linked.

The prime example of this is EqualityComparer(Of T). This class is used to provide instances of IEqualityComparer(Of T) for any given type. Under the hood it tries to determine the best way checking for equality in types. If T implements IEquatable(Of T) it will eventually create an instance of GenericEqualityComparer(Of T) [1]. The methods of IEqualityComparer(Of T) are implemented as follows (boundary cases removed)

Equals(left, right): return left.Equals(right)

Equals in this case is IEquatable(Of T).Equals

GetHashCode(obj): return obj.GetHashCode()

This implicitly links IEquatable(Of T).Equals to Object.GetHashCode(). Therefore if you implement IEquatable(Of T) you should also override GetHashCode(). The best way to view this is "if you implement IEquatable(Of T) you should override Equals and GetHashCode."

What's even more unfortunate is there is no feedback to indicate this relationship exists. If you override Equals or GetHashCode both the C# and VB compilers will issue a warning/error. Implementing IEquatable(Of T) produces no such warning.

[1] Unfortunately this is a private type so you will need to use Reflector to view the type.

Properly Implementing Equality in VB

JaredPar MSFT — Mon, 28 Apr 2008 15:04:06 GMT

Many developers want to implement equality functions for their objects. DotNet made equality a deep part of the framework and added support all the way up to System.Object with Equals and GetHashCode. In addition to the strongly enforced method semantics of GetHashCode and Equals there are also several other hard to enforce patterns that developers must follow in order to properly integrate into the rest of the DotNet framework. We'll explore those rules today.

Before even talking about how to implement equality we need to define the types of equality.

Reference equality: Are these two objects really the exact same object.
Object/value equality: Depends on what the object author thinks equality means. Can be anything from reference equality up to, comparing fields, to were they created in the same app domain.

In VB these are two very separate types of equality. Reference equality is expressed through the "Is" operator. Object equality is done directly through operator=, operator<> and Equals. This is also indirectly exposed via GetHashCode, EqualityComparer(Of T) and other framework patterns.

When implementing object/value Equality there are four methods that are important to consider in order to fit expected patterns. What's even more important is understanding which ones must be implemented together. If an author overrides any of the functions in the following pairs they must override both.

Equals/GetHashCode
Operator=/Operator!=

To make it easier, my rule of thumb is to override all four or none.

Equals

This is the bread and butter of object/value equality. The author has free reign to decide what is and what is not equal. However there are a few rules authors must follow in order to fit into the rest of the framework.

Do not throw an exception from Equals. Many components call Equals in a loop and there is no way for them to handle or recover from an exception. If the object is not equal just return False
The object passed in is typed to object. It is perfectly valid for the framework to pass in an object that is completely unrelated to the type defining Equals. The type author must account for and handle this case.
The framework can pass in Nothing as a parameter to Equals and this is valid.

#2 and #3 may seem a bit off at first but it is implemented with a standard pattern as seen below.

Class C1
    Public Overrides Function Equals(ByVal obj As Object) As Boolean
        Dim other = TryCast(obj, C1)
        If other Is Nothing Then
            Return False
        End If
        ...
    End Function
End Class

It's very important that you use "Is" to compare other in the above example. Imagine if you slip up and type "=" instead. You're about to override Operator= and this will cause "other=Nothing" to call operator=. If this is a valid C1 instance operator= will almost certainly call Equals and then you'd have a stack overflow. Our implementation of Operator= below will avoid this problem.

GetHashCode

This is both the easiest and trickiest function to override because it has very subtle semantics which cause very hard to find bugs in code. The simple rule is "If two objects are equal in the sense of value equality they must return the same value in GetHashCode()".

Why? Many classes use the hash code to classify an object. In particular hash tables and dictionaries tend to place objects in buckets based on their hash code. When checking if an object is already in the hash table it will first look for it in a bucket. If two objects are equal but have different hash codes they may be put into different buckets and the dictionary would fail to lookup the object.

The better version of the GetHashCode rule has a small suffix on the simple rule. "Only calculate the hash code based off of primitive fields which are ReadOnly". This is not an absolute requirement as long as you are careful when you are code. But as previously stated, when coding it's best not to trust yourself to do the right thing. Not doing this will get you into trouble when dealing with Hashtables and dictionaries.

For instance take this not so small example. In this case value equality is based solely off of Field1 which is a modifiable field. Once Field1 is changed you may or may not be able to access the value in the dictionary because GetHashCode() will change. This example is contrived but it does happen in the real world and it can be incredibly difficult to track down.

Class C2
    Public Field1 As Integer

    Public Sub New(ByVal f1 As Integer)
        Field1 = f1
    End Sub
    Public Overrides Function GetHashCode() As Integer
        Return Field1.GetHashCode()
    End Function
    Public Overrides Function Equals(ByVal obj As Object) As Boolean
        Dim other = TryCast(obj, C2)
        If other Is Nothing Then
            Return False
        End If
        Return other.Field1 = Field1
    End Function
End Class

Module Module1

    Sub Main()
        Dim map = New Dictionary(Of C2, String)
        Dim v1 = New C2(44)
        map.Add(v1, "avalue")
        Console.WriteLine(map(v1))
        v1.Field1 = 2
        Console.WriteLine(map(v1))  ' Potentially throws
    End Sub

End Module

If Field1 were ReadOnly there would be no way to hit this problem. Then again we'd also not be able to change Field1.

Operator=

When implementing equality overriding operator= allows you to use the more pleasant and reliable version of syntax comparison: a=b vs. a.Equals(b). I say more reliable because using a.Equals(b) has an inherent dependency on "a" being a non-Nothing object. "Operator=" makes no assumption and should operate correctly in the presence of Nothing.

Operator= has virtually the same rules as Equals. Mainly don't throw from operator=. Operator= is usually just defined in terms of Equals() and since it also has to respect the no throw rule once we get there we are in good shape. Getting to Equals() can be tricky though because one or both of the arguments can be Nothing. In addition make sure not to use "=" to check for Nothing because you're back to the stack overflow problem.

What's great here is there is a simple solution that you should use every time you define Operator=. EqualityComparer(Of T) knows all of these rules and in the face of both parameters being non-Nothing will call Equals() just like we want. This makes the definition of Operator= boiler plate (I define very Operator= the exact same way)

Public Shared Operator =(ByVal left As C2, ByVal right As C2) As Boolean
    Return EqualityComparer(Of C2).Default.Equals(left, right)
End Operator

What's even better is that EqualityComparer(Of T) understands the stack overflow problem which can occur in equality comparison and avoids it.

Operator <>

Operator<> has the same rules as Operator= and luckily the same easy type of answer.

Public Shared Operator <>(ByVal left As C2, ByVal right As C2) As Boolean
    Return Not EqualityComparer(Of C2).Default.Equals(left, right)
End Operator

Wrapping Up

I started this article thinking it would be a few paragraphs of simple rules. But as I kept going I kept remembering the subtleties and problems I encountered in the past.

For my own projects I avoid implementing equality unless it's truly needed because of the problems with properly implementing GetHashCode(). The one exception is when I define immutable objects. Immutable objects have no problems with GetHashCode() since they are unchangable so Equality is straight forward.

Me, MyBase, MyClass and MyPost on the subject

JaredPar MSFT — Fri, 25 Apr 2008 18:09:08 GMT

Recently we had a good discussion on an internal alias about the use of Me, MyClass and MyBase in VB. Me, MyBase and MyClass are all ways to access instance member data in a VB class or structure. There was a little bit of confusion on the actual workings and meanings of the keywords in various contexts and I want to use this post to shed light on the different meanings.

The Basics

The keywords are used to alter the way in which instance members of a class/structure are accessed. In particular they affect the way Overridable/MustOverride/Overrides functions are evaluated. Methods defined with Overridable/Overrides/MustOverride are defined as virtual by the CLR. For the purpose of this post all of these definitions are mostly equal. This discussion will be useless without and example so here's the code to discuss.

Class GrandParent
    Public Overridable Sub Sub1()
        Console.WriteLine("GrandParent.Sub1")
    End Sub
End Class

Class Parent
    Inherits GrandParent
    Public Overrides Sub Sub1()
        Console.WriteLine("Parent.Sub1")
    End Sub
End Class

Class Child
    Inherits Parent
    Public Overrides Sub Sub1()
        Console.WriteLine("Child.Sub1")
    End Sub
End Class

In this case Sub1 is a virtual method and there are three instances of it (one per class). By default virtual methods are called based on the runtime type of the object. The CLR will essentially walk the hierarchy from current type to object looking for the first class which defines a particular method and call that version. It doesn't matter what the variable type is declared as, just what type it actually is.

Dim v1 As GrandParent = New Parent
v1.Sub1()   ' Calls Parent.Sub1
Dim v2 As GrandParent = New GrandParent
v2.Sub1()   ' Calls GrandParent.Sub1

Changing the call

If the CLR will always call a virtual Sub/Function based on the runtime type of an object how can I access the parent function? This is where MyBase comes in. MyBase allows you to call the version of the virtual method defined in the parent class. Essentially it tells the CLR call this method/property as if my runtime type was my base type.

Class Child2
    Inherits Parent
    Public Overrides Sub Sub1()
        MyBase.Sub1()   ' Calls Parent.Sub1
        Console.WriteLine("Child2.Sub1")
    End Sub
End Class

MyClass is similar to MyBase. Instead of telling the CLR the current type is the base type, it tells the CLR the runtime type is the type where MyClass is used. This allows developers to call their type's version of a virtual method no matter who derives from them. In the following example it doesn't matter how many, or who derives from Child3, Sub2 will always call the version of Sub1 defined in Child3.

Class Child3
    Inherits Parent
    Public Overrides Sub Sub1()
        Console.WriteLine("Child3.Sub1")
    End Sub
    Public Sub Sub2()
        MyClass.Sub1()
    End Sub
End Class

So, why not MyChild?

The short answer is, it's not verifiable. When writing MyBase we can verify that indeed there is a sub/function/property matching the call site in the base class. If no such method exists it will result in an error. MyClass is similarly easy to verify. With MyChild however there would be no useful way of guaranteeing a particular sub/function/property was defined on the child class.

One way you can verify a child class contains a particular property/sub/function is to make it MustOverride. However in this case there is no actual definition in the original type. In fact, if you try and access a MustOverride method with MyClass it will generate a compile time error. Therefore every call must at least occur in the child class or lower rendering MyChild superfluous.

What about non-virtual methods and properties?

The primary intent of MyBase/MyClass is to call virtual methods in a non-virtual way. However they can also be used to call non-virtual methods. From the perspective of the user calling a non-virtual method with MyBase/MyClass/Me has no discernable difference. If you crack open the generated IL you can see a small difference in the op code but the short story is it won't affect your program.

BinaryInsert Part2

JaredPar MSFT — Mon, 07 Apr 2008 22:09:36 GMT

Previously I discussed a potential missing API in List(Of T).BinaryInsert. One of the items I mentioned was it had better performance because it was O(Log N) vs Insert and Sort which is O(NLogN). Several users correctly pointed out this was incorrect and that Insert() had the additional overhead of an Array.Copy() which is O(N)ish. But most agreed O(N) + O(LogN) was better than O(NLogN).

Given that I already missed a key portion, I decided to write a test program to try out the various methods. Caveat: I'm not a performance guy. While I find performance intriguing and interesting it is by no means my specialty. Any single performance test is unlikely to capture all real world scenarios. However I did find the results a bit surprising. At the bottom of the post is the test code I wrote.

Here is the summary output.

Force Jit
BinaryInsert:     00:00:00.0051167
Insert Then Sort: 00:00:00.0000251
Range (0-99)
BinaryInsert:     00:00:00.0000266
Insert Then Sort: 00:00:00.0000316
Random 10
BinaryInsert:     00:00:00.0000053
Insert Then Sort: 00:00:00.0000034
Random 100
BinaryInsert:     00:00:00.0000294
Insert Then Sort: 00:00:00.0000235
Random 1000
BinaryInsert:     00:00:00.0004917
Insert Then Sort: 00:00:00.0001526
Random 10000
BinaryInsert:     00:00:00.0261899
Insert Then Sort: 00:00:00.0018287
Random 100000
BinaryInsert:     00:00:02.4289054
Insert Then Sort: 00:00:00.0237019

As you can see, based on my sample program, BinaryInsert is much slower than Insert and Sort. I ran the profiler against this and verified the suspicion that List(Of T).Insert() took the vast majority of the time.

Perhaps there is a reason BinaryInsert is missing.

Module Module1

    Function BinaryInsert(Of T)(ByVal enumerable As IEnumerable(Of T), ByVal comp As IComparer(Of T)) As TimeSpan
        Dim list As New List(Of T)
        Dim watch As New Stopwatch()

        watch.Start()
        For Each value In enumerable
            list.BinaryInsert(value, comp)
        Next
        watch.Stop()
        Return watch.Elapsed
    End Function

    Function InsertAllThenSort(Of T)(ByVal enumerable As IEnumerable(Of T), ByVal comp As IComparer(Of T)) As TimeSpan
        Dim list As New List(Of T)
        Dim watch As New Stopwatch()

        watch.Start()
        For Each value In enumerable
            list.Add(value)
        Next
        list.Sort(comp)
        watch.Stop()
        Return watch.Elapsed
    End Function

    Sub TestBoth(Of T)(ByVal title As String, ByVal enumerable As IEnumerable(Of T))
        TestBoth(title, enumerable, Comparer(Of T).Default)
    End Sub

    Sub TestBoth(Of T)(ByVal title As String, ByVal enumerable As IEnumerable(Of T), ByVal comp As IComparer(Of T))
        Dim copy = New List(Of T)(enumerable)
        Dim ellapsedBinary = BinaryInsert(New List(Of T)(copy), comp)
        Dim ellapsedSort = InsertAllThenSort(New List(Of T)(copy), comp)

        Console.WriteLine(title)
        Console.WriteLine("BinaryInsert:     {0}", ellapsedBinary)
        Console.WriteLine("Insert Then Sort: {0}", ellapsedSort)
    End Sub

    Function Range(ByVal start As Integer, ByVal count As Integer) As List(Of Integer)
        Dim list = New List(Of Integer)
        For i = start To count - 1
            list.Add(i)
        Next
        Return list
    End Function

    Function Random(ByVal count As Integer) As List(Of Integer)
        Dim rand As New Random()
        Dim list = New List(Of Integer)
        For i = 0 To count - 1
            list.Add(rand.Next())
        Next
        Return list
    End Function

    Sub Main()
        TestBoth("Force Jit", New Integer() {1})
        TestBoth("Range (0-99)", Range(0, 100))
        TestBoth("Random 10", Random(10))
        TestBoth("Random 100", Random(100))
        TestBoth("Random 1000", Random(1000))
        TestBoth("Random 10000", Random(10000))
        TestBoth("Random 100000", Random(100000))
    End Sub

End Module

Have a IComparable(Of T) but need an IComparer(Of T)?

JaredPar MSFT — Thu, 03 Apr 2008 04:33:52 GMT

IComparable(Of T) is an interface saying "I can compare myself to other objects of the same type". And IComparer(Of T) is an interface saying "I can compare two objects of this type.". Often API's which need to perform comparisons will take an instance of IComparer(Of T) instead of IComparable(Of T).

Doing the opposite is limiting in a few ways. The first is it locks developers into the behavior defined by the type author essentially preventing them from deciding to compare in a different way. The second is if the type author didn't didn't implement IComparable(Of T), we must define a wrapper class that does. This is even more awkward because collections now contain instances of the wrapper. Also there is one wrapper overhead per instance in the collection.

Now back to the original problem, we have a type which implements IComparable(Of T) but don't have an IComparer(Of T) wrapper class. Luckily the .Net Framework provides a solution. Comparer(Of T).Default. It provides a quick IComparer(Of T) wrapper that automatically delegates to IComparable(Of T) if the type defines it.

Example usage: Previously we defined a BinaryInsert method for List(Of T). It required an explicit IComparer(Of T) be passed even for simple types like Int32. We can fix this by using the Comparer(Of T) class.

    <Extension()> _
    Public Sub BinaryInsert(Of T)(ByVal list As List(Of T), ByVal value As T)
        list.BinaryInsert(value, Comparer(Of T).Default)
    End Sub

Missing API: List(Of T).BinaryInsert

JaredPar MSFT — Mon, 31 Mar 2008 17:26:42 GMT

One API that seems to be missing from List(Of T) is a BinaryInsert method. Especially since there is already a BinarySearch method.

Binary insert is a method for inserting a value into an already sorted list. Since the list is already sorted we can do a binary search to find the appropriate place to insert. The insert keeps the list sorted so the cost of a binary insert is just the cost of the search which is O(Log(N)).

An alternative method for keeping a sorted list sorted is to insert and then resort. Most sorting algorithms have a cost of O(N*Log(N)). In other words it's N times more expensive.

Yet this API doesn't exist. No matter. We can quickly fix this problem with a couple of extension methods.

Public Module Extensions

    <Extension()> _
    Public Sub BinaryInsert(Of T)(ByVal list As List(Of T), ByVal value As T, ByVal comp As IComparer(Of T))
        list.BinaryInsert(value, comp, 0, list.Count)
    End Sub

    <Extension()> _
    Public Sub BinaryInsert(Of T)(ByVal list As List(Of T), _
                                  ByVal value As T, _
                                  ByVal comparer As IComparer(Of T), _
                                  ByVal iStart As Integer, _
                                  ByVal iEnd As Integer)
        While iStart < iEnd
            Dim len = iEnd - iStart
            Dim iMiddle = iStart + (len \ 2)
            Dim comp = comparer.Compare(value, list(iMiddle))
            If 0 = comp Then
                iStart = iMiddle
                Exit While
            ElseIf comp < 0 Then
                iEnd = iMiddle
            Else
                iStart = iMiddle + (len Mod 2)
            End If
        End While
        list.Insert(iStart, value)
    End Sub

End Module

Dealing with Exceptions in a Future

JaredPar MSFT — Mon, 11 Feb 2008 19:36:22 GMT

Besides waiting, the another important issue when dealing with Futures is how to deal with exceptions thrown by the user specified code.

Option 1: Ignore the Exception

Don't take any actions in the future code and force users to write exception free code. IMHO this is not the best way to approach the problem. The code will be running in the thread pool and unhandled exceptions in the thread pool result in the taking down of an appdomain/process. In addition Futures are designed to be simple. Adding a try/catch around every lambda is not practical and/or readable.

Option 2: Catch and Swallow

Catch the exception on the background thread and swallow it. Silently failing is in many cases worse than actually crashing. Behavior will become flaky and the user/developer won't have any indication there is an error.

Option 3: Re-throw the Exception when Wait is called

Catch and save the exception when it occurs on the background thread. Then when Wait() is called on a Future re-throw the exception. This makes exception handled deterministic.

It's also very similar to the exception handling semantics of calling a method. The only difference is that users must handle the exception at the point of method completion vs invocation. For synchronous methods this is just the same point.

The big downside to this approach is the stack trace information is lost from the exception. Re-throwing will instead add the stack trace at the point of the re-throw. Not having stack trace information makes it very difficult to actually track down the source of an error.

Option 4: Re-throw a new Exception when Wait is called

This is very similar to Option #3. The only difference is when the user calls Wait, throw a new exception and make the original exception an inner exception of the new one. We'll call this exception FutureException. This has the advantages of option 3 and in addition will preserve the stack trace information from the original exception.

There is a downside to this approach though. Users can no longer have different catch blocks to handle the different types of exceptions that can be thrown.

            try
            {
                Future.Create(() => SomeOperation());
            }
            catch (IOException ex)
            {
                // ...
            }
            catch (InvalidOperationException ex)
            {
                // ...
            }

Instead the user can only catch a Future exception and examine the inner result to take corrective action.

            try
            {
                Future.Create(() => SomeOperation());
            }
            catch (FutureException ex)
            {
                var type = ex.InnerException.GetType();
                if (type == typeof(IOException))
                {
                    // ...
                }
                else if (type == typeof(InvalidOperationException))
                {
                    // ...
                }
            }

This doesn't actually limit any functionality but users may find the syntax uncomfortable. VB users can still do exception filtering but this is not at option for C# users.

        Try
            Future.Create(Function() SomeOperation())
        Catch ex As Exception When ex.InnerException.GetType() Is GetType(IOException)

        End Try

The FutureException class is straight forward. A simple implementation of the exception snippet will do the trick.

    [global::System.Serializable]
    public class FutureException : Exception
    {


        public FutureException() { }
        public FutureException(string message) : base(message) { }
        public FutureException(string message, Exception inner) : base(message, inner) { }
        protected FutureException(
          System.Runtime.Serialization.SerializationInfo info,
          System.Runtime.Serialization.StreamingContext context)
            : base(info, context) { }
    }

Tuples Part 1

JaredPar MSFT — Thu, 03 Jan 2008 19:25:51 GMT

A tuple in computer science can be described as a set of name/value pairs. In some cases it can be described as simply a set of values that are accessible via an index [1]. Previously I discussed how to create a Tuple inside of PowerShell. This series will focus on the use of Tuples in DotNet and how to use PowerShell to generate DotNet code.

This series will also distinguish between mutable and immutable tuples. As DotNet is shifting it's focus on parallel programming, immutable types are becoming more important. Therefore this serious will focus on Tuples as immutable types and later examine mutable tuples.

In Visual Studio 2005, both C# and VB acquired tuples as a part of the programming language in the form of Anonymous Types. These fit all of the properties of a tuple. The one difference is in VB, anonymous types are mutable by default. This can be changed though by using the Key keyword.

However anonymous types are lacking one quality which severely lessens their usefulness. Their type cannot be described. This prevents them from being used as parameters, fields, generic parameters [2] etc ... Unless you use late binding or terribly awkward casts this is limiting.

To get around this, we will be defining a set of generic tuple class supporting 1-N name value pairs. The great downside is because we will be predefining these types the names in the name value pair will be fixed. We will be using A-N for 1-N pairs.

This is very limiting in itself because it's reducing the expressiveness of a type. Anonymous types are much more expressive since they have names. Now types will have properties A,B, etc ...

For me this still works. In my code, I only end up using tuples when I need to pass data around between tightly coupled classes, or just within the same class. Since the creation and use are so close loosing the full expressiveness of the name is not that limiting.

In addition, our tuple implementation will leverage type inference as much as possible such that the following code can be written.

            var tuple = Tuple.Create("foo");
            Console.WriteLine(tuple.A);

Why write a script to generate these classes? Wouldn't it just be easier to just do this by hand??? Yes and no. If you are doing a fixed set of short used classes then yes, do it by hand. These scripts evolved out of my use of tuples. Once I would settle on a structure and I would think of a new feature I needed. Typically I have tuples defined up to 5 fields. Retyping out a new feature got tiresome and error prone. With a scripting solution I could add a new feature and tests in just a few minutes. The series is very representative of the way my solution changed over time. Simple at first but I added features as the situation dictated. Having a scripting solution saved me a lot of time.

Next up, generating the basic structure.

[1] In this case, the index just becomes the name and hence a name/value pair.

Getting my Fortune

JaredPar MSFT — Mon, 03 Dec 2007 20:57:46 GMT

Fortune is a Unix command that gets a random message from a set of databases and displays it on the screen. These messages have a wide variety but tend to be funny, quirky or famous quotes (most are indeed geeky).

Nearly all unix systems have a version of Fortune. Windows doesn't have any version by default. It provides no real functionality other than humor and amusement but it's something I miss. Most users add it to their .profile script so they get a new fortune every time they log in.

There are a couple of heavy weight options to get fortune on my machine but I prefer something a bit lighter. I did a quick search and discovered that Doug Hughes implemented a fortune web service. This is just above as light weight as it gets so I implemented a simple PSCmdlet, get-fortune, to do the work (code below).

Now I can just add a quick get-fortune to my profile script.

C:\Users\jaredp> get-fortune pets
Does the name Pavlov ring a bell?

<Cmdlet(VerbsCommon.Get, "Fortune")> _
Public Class GetFortune
    Inherits PSCmdlet

    Public Const TopicHelpMessage = "Restricts fortune output to the specified topic"

    Private m_topic As String = String.Empty
    Private m_minimumLength As Integer
    Private m_maximumLength As Integer
    Private m_timeout As Integer = 100000

    <Parameter( _
               Position:=0, _
               HelpMessage:=TopicHelpMessage, _
               ValueFromPipeline:=True, _
               ValueFromPipelineByPropertyName:=True)> _
    Public Property Topic() As String
        Get
            Return m_topic
        End Get
        Set(ByVal value As String)
            m_topic = value
        End Set
    End Property

    <Parameter(Position:=1)> _
    Public Property MinimumLength() As Integer
        Get
            Return m_minimumLength
        End Get
        Set(ByVal value As Integer)
            m_minimumLength = value
        End Set
    End Property

    <Parameter(Position:=2)> _
    Public Property MaximumLength() As Integer
        Get
            Return m_maximumLength
        End Get
        Set(ByVal value As Integer)
            m_maximumLength = value
        End Set
    End Property

    <Parameter(Position:=3)> _
    Public Property Timeout() As Integer
        Get
            Return m_timeout
        End Get
        Set(ByVal value As Integer)
            m_timeout = value
        End Set
    End Property

    Protected Overrides Sub ProcessRecord()
        Dim proxy As New DougHughes.fortune
        Dim topic = m_topic
        If topic Is Nothing Then
            topic = String.Empty
        End If

        proxy.Timeout = m_timeout
        WriteObject(proxy.getFortune(topic, m_minimumLength, m_maximumLength))
    End Sub

End Class