The Visual Basic Team : VB2010

Spot the Bug! – The Key to using Anonymous Types (Jonathan Aneja)

VBTeam — Tue, 17 Nov 2009 07:54:00 GMT

This one’s going to be long, but for those of you who’ve felt the first 3 in this series were too easy I promise this one’s tougher J.

Let’s say you want to list all the customers from a table in a ComboBox, and update the UI based on which one is selected. To do this we’ll need to bring back two fields from the database – the customer’s name and the customer’s ID. When a customer is selected we want the ComboBox’s SelectedValue property to equal the customer’s ID.

Here’s some quick code that gets us up and running (using Northwind and LINQ to SQL):

Dim db As New NorthwindDataContext

Dim query = From row In db.Customers _

Select row.CompanyName, row.CustomerID

ComboBox1.DataSource = query.ToList()

ComboBox1.DisplayMember = "CompanyName"

ComboBox1.ValueMember = "CustomerID"

But now let’s say your boss looks at the app and says “I want you to add an ‘All Customers’ option as the first item in the list.” How would you do that? You’d need to insert an anonymous type into an existing sequence of anonymous types, which is tricky given that you can never actually use the type’s name.

Thankfully there’s a trick that uses generic parameter inference that allows us to do this (it relies on the fact that the compiler will share (or “unify”) the definition of multiple anonymous types when they have the same number of members, in the same order, of the same type, with the same names, and the same mutability):

Dim db As New NorthwindDataContext

Dim query = From row In db.Customers _

Select row.CompanyName, row.CustomerID

Dim allOption = New With {.CompanyName = "All Customers", _

.CustomerID = "-1"}

ComboBox1.DataSource = AddOptionForAll(query, allOption).ToList()

ComboBox1.DisplayMember = "CompanyName"

ComboBox1.ValueMember = "CustomerID"

...

Function AddOptionForAll(Of T)(ByVal sequence As IEnumerable(Of T), _

ByVal allOption As T) As IEnumerable(Of T)

'wrap individual element in an array and then union the two sequences

Return (New T() {allOption}).Union(sequence)

End Function

As long as we have an anonymous type that’s compatible with the anonymous type that the query generated, the compiler will determine that sequence and allOption are actually the same type and this should work fine.

Ok so let’s get to the bug – well in this case spotting it is pretty simple (it doesn’t compile J), but fixing it is tricky (though I’ve already given two pretty big hints). Here’s the text of the compiler error (it’s on the line that calls AddOptionForAll):

Data type(s) of the type parameter(s) in method 'Public Function AddOptionForAll(Of T)(sequence As System.Collections.Generic.IEnumerable(Of T), allOption As T) As System.Collections.Generic.IEnumerable(Of T)' cannot be inferred from these arguments because they do not convert to the same type. Specifying the data type(s) explicitly might correct this error.

What’s wrong and how do we fix it?

Answer: We actually told the compiler to generate two different anonymous type definitions, and thus it can’t unify them because the types really are different.

From earlier: “…the compiler will share (or “unify”) the definition of multiple anonymous types when they have the same number of members, in the same order, with the same names, and the same mutability”

The anonymous type that the query generates will have ReadOnly properties, whereas the anonymous type that we generated (allOption) will have Read/Write properties. The fix is to allOption immutable so that its structure will match the result of the query:

Dim allOption = New With {Key .CompanyName = "All Customers", _

Key .CustomerID = "-1"}

The “Key” modifier tells the compiler to make those properties ReadOnly and to override Equals and GetHashCode such that they only consider “Key” properties when deciding if two instances of the same anonymous type are equal. (the other hint was in the title J). For the query above, the compiler automatically inserts the “Key” modifier - i.e. what we wrote is exactly equivalent to this:

Dim query = From row In db.Customers _

Select New With {Key row.CompanyName, Key row.CustomerID}

So with a simple fix to the allOption line we’re now using the same anonymous type definition and everything works fine.

VB’s anonymous type syntax is very flexible and provides three different options: immutable, fully mutable, or partially mutable (i.e. some fields are ReadOnly while others are not). Even for a simple scenario like adding an option to a list, the better you understand how things work under the covers the easier it’ll be to debug problems later J.

Spot the Bug! – Is it in VB or XAML? (Jonathan Aneja)

VBTeam — Fri, 13 Nov 2009 03:39:00 GMT

What’s wrong with the following WPF code?

Class Window1

Sub OK_Click(sender As Object, e As RoutedEventArgs) Handles OK.Click

MsgBox("Button Clicked")

End Sub

End Class

<Window x:Class="Window1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Title="Window1" Height="300" Width="300">

<Grid>

</Grid>

</Window>

Answer: The message box will be displayed twice! To understand why, open up the project in Reflector, and in the System_Windows_Mark_IComponentConnector_Connect method you’ll see these two lines:

    Me.OK = DirectCast(target, Button)

    AddHandler Me.OK.Click, New RoutedEventHandler(AddressOf Me.OK_Click)

Ok so we’re adding one handler here, but click the link to navigate to “OK”. You’ll see this is actually a property of type Button (that’s what the compiler does for WithEvents/Handles – the full story of how WithEvents works is its own blog entry…). In the Setter you’ll see this code:

    If (Not Me._OK Is Nothing) Then

        AddHandler Me._OK.Click, handler

    End If

So now we can clearly see there’s two AddHandler calls and thus the event gets handled multiple times by the same method (which is perfectly legal). One of them came from Handles OKButton.Click, and the other came from Click="OK_Click".

The key thing to realize is that if you wire up the eventhandler in XAML, don’t wire it up in code using Handles (and vice-versa). Thankfully in this scenario it’s obvious that there’s a problem because there’s a message box, but if the eventhandler was doing something more subtle (such as incrementing a counter or modifying some other state), this can lead to hard-to-diagnose bugs.

Spot the Bug! – Much ado about Nothing… Part 2! (Jonathan Aneja)

VBTeam — Fri, 06 Nov 2009 07:46:00 GMT

In yesterday’s post we saw that the use of the wrong comparison operator with Nothing in an If block can lead to surprising results. Let’s look at a slightly different case today:

Dim x As Integer = Nothing

If x = Nothing Then

MsgBox("A true statement - we land here")

Else

MsgBox("The statement is a lie - we land here")

End If

What gets printed? If the code is intended to print “A true statement…”, is there actually a bug in this code?

Answer: The code is correct according to its “specification” (I’m using the term loosely here J), so from a technical point of view there is no bug here. However, from a code readability and maintenance point of view, I’d argue that there is a bug.

The Nothing literal in VB means “default value for this type”, and for an Integer that would be 0. So the code above is exactly equivalent to this:

Dim x As Integer = 0

If x = 0 Then

MsgBox("A true statement - we land here")

Else

MsgBox("The statement is a lie - we land here")

End If

Now that’s way more readable than the version above, and dramatically reduces the potential for confusion. In general*, if you ever find yourself writing “= Nothing” in a conditional expression, you should either be changing the = to “Is” (as we saw yesterday), or you should change Nothing to the actual default value if possible.

The next post will have a real bug, I promise J

*Yes, there may be cases such as structure/generics/overloaded operators where you actually would want to say “= Nothing” – my point is that if you’re going to do this make sure you know what you’re doing, and insert a comment so that those reading your code also know what you’re doing J.

Spot the Bug! – Much Ado about Nothing… (Jonathan Aneja)

VBTeam — Wed, 04 Nov 2009 02:32:00 GMT

Microsoft has this neat mailing list called “Spot the Bug” where developers can send interesting snippets of code that look correct but actually have subtle bugs in them. The puzzles are a lot of fun and I’ve always thought it’d be a fun thing to try here on the team blog. Over the past year or so I’ve been keeping a list of interesting bug reports and emails where people have been tripped up by some of VB’s hidden subtleties (though admittedly many of these could apply to C# as well).

The format’s gonna be a bit of an experiment – let me know if you prefer to see the answer in the same post or posted a day later. Alright let’s get started…

Spot the Bug:

The following code is intended to print “Yes” – will it?

Dim x As Integer? = Nothing

If x = Nothing Then

MsgBox("Yes: x contains null")

Else

MsgBox("No: x does not contain null, and has a real value")

End If

Answer: No! We’re using the equality operator to compare a nullable integer with Nothing – this results in null propagation, i.e. the result of the expression is Nothing. An If-statement attempts to convert its condition to a Boolean, so basically we’re left with this:

If Nothing Then

Else

'Obviously we'll always land here

End If

This can be really surprising when working with nullables, so we’ve decided to add a warning for this case in VB10:

The warning explains the fix – use “Is” instead of = to avoid the null propagation and get the semantics you expect:

Dim x As Integer? = Nothing

If x Is Nothing Then

MsgBox("Yes: x contains null")

Else

MsgBox("No: x does not contain null, and has a real value")

End If

Check back for a similar case but with a bit of a twist tomorrow...

Visual Basic “How Do I” Videos

VBTeam — Thu, 22 Oct 2009 01:23:11 GMT

We’ve started two new “How Do I” videos series on the Visual Basic Developer Center. More to come, but here’s the latest!

Announcing Visual Studio 2010 Beta 2!

VBTeam — Tue, 20 Oct 2009 17:35:00 GMT

There were a lot of Microsoft announcements that happened yesterday! Many of these happened during Steve Ballmer’s keynote at the SharePoint Developers Conference (Video, Twitter). Here is the list:

Visual Studio 2010 Beta 2 and compatible versions of IronRuby/IronPython
Visual Studio 2010 Tools for SharePoint (Keynote, Dev Center)
New Visual Studio logo and brand (blue & purple infinity sign)
Visual Studio 2010 SKU Simplification to Professional, Premium, Ultimate
MSDN.com website refresh
Visual Studio 2010 Launch date on 3/22/2010

MSDN subscribers can download Beta 2 now! We will be opening up Beta 2 for everyone to download starting this Wednesday.

In honor of VS 2010 Beta 2, we have a lot of great content prepared. The following MSDN page aggregates our VB 2010 content.

Visual Basic 2010 Resources

We hope you will enjoy trying out the next release! We definitely look forward to hearing your feedback. Here are some places where you can contact us:

For Questions: Visual Basic Forums
For Bugs: Microsoft Connect
For General Observations or Comments: In the Comments to this Blog

Thanks!
Lisa

Getting Loopy (Matt Gertz)

VBTeam — Thu, 08 Oct 2009 00:50:00 GMT

In my last post, I talked about the hidden costs that can occur whenever you call out to methods, particularly in loops. In looking at my examples, reader KG2V commented that another thing that folks need to be aware of is avoiding the assumption that the world (or, in this case, a list) is a static thing. It’s a good point and it deserves some attention, particularly given that different languages will react in different ways to change.

To illustrate this point, let’s assume that we have a form with a ListBox on it, and that we also have a button on the form that, when clicked, runs the following VB code:

' Bad -- don't do this

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

For i As Integer = 0 To ListBox1.Items.Count - 1

ListBox1.Items.RemoveAt(i)

End Sub

Ostensibly, we want to remove all of the items from the ListBox. (Yes, normally we’d use Clear() to do that, but stay with me for a moment; I’ll switch to more “real” cases in a few paragraphs.) But if we run this code, we’ll get an exception. Why? Because whenever we remove an object, all of the indices of the objects after it will decrease by 1. Let’s assume that there are three objects in the list - A, B, and C – so that Count=3:

· When i = 0, we’ll remove the object at index 0, which is A. B now moves to index 0, and C now moves to index 1.

· When i = 1, we’ll remove the object at index 1, which is C. There is nothing after C, so nothing else changes.

· When i =2, we’ll remove the object at index 2, which is… nothing. There’s only one object left, which is B, and it’s at index 0. So, we get an out-of-bounds exception.

In VB (as was pointed out to me in the comments section of my last point), the value of Count is only assessed once, right when the loop is encountered, so we will always loop through (in this case) three times.

But is the lack of reevaluation of Count the only issue? Maybe not. Let’s try the same method in C#, in which Count is evaluated on every iteration:

// Bad -- don't do this.

private void button1_Click(object sender, EventArgs e)

{

int i;

for (i = 0; i < listBox1.Items.Count; i++)

{

listBox1.Items.RemoveAt(i);

}

· When i = 0, we’ll remove the object at index 0, which is A. B now moves to index 0, and C now moves to index 1.

o Now, we’ll loop back to the top. The value of i becomes 1, and the value of Count becomes 2. The stop condition is not met, so we keep going.

· When i = 1, we’ll remove the object at index 1, which is C. There is nothing after C, so nothing else changes.

o Again, we loop back to the top. The value of i becomes 2, and the value of Count becomes 1. The stop condition is met, and we exit the loop.

So, although no exception is thrown, the method also fails in C# -- B is left behind. So, the problem isn’t whether or not Count is evaluated; it’s that the elements in the list are changing indices on each deletion.

Sometimes doing things backwards is good

This is why, in the case where multiple removals need to be made on an indexed list, a smart programmer (all of whom are yawning right now as they read this) will work backwards. That is, they start with the largest index and work down towards zero. For example, imagine that we want to remove the 4^th, 7^th, and 9^th element from a list. We don’t want to do it this way:

' Bad -- don't do this

ListBox1.Items.RemoveAt(4)

ListBox1.Items.RemoveAt(7)

ListBox1.Items.RemoveAt(9)

Once we’ve removed the 4^th item, then the element at 7 will have moved to 6 and the element at 9 will have moved to 8. After we’ve removed the new 7^th item, the element at 8 will move to 7, and so on. We’d either be removing the wrong elements or we’d crash. It’s far better to do them in reverse order:

ListBox1.Items.RemoveAt(9)

ListBox1.Items.RemoveAt(7)

ListBox1.Items.RemoveAt(4)

None of the indices up front will be affected by changes that are occurring behind them in the list – their indices won’t change, and this will work fine.

This issue comes up when you are (for example) deleting items from a listbox that supports multiselection. You basically have two ways to get the selected items in a listbox: you can use the SelectedIndices member function, which returns a collection of indices, or you can use SelectedItems, which returns a collection of selected items. Given either collection, there’s no way to say “remove all of these.” There is a “Remove” command on the resulting collections, but if you use it, you’ll just be removing the item from *that* collection and not from the ListBox, which has its own collection of items – essentially, you’ll just deselect the items.

So, what do you do? At first, it looks like you have two options; you could try removing them from the master list based on item, or based on object. Let’s look at removal based on the item:

' Bad -- don't do this

For Each index As Integer In ListBox1.SelectedIndices

ListBox1.Items.RemoveAt(index)

This won’t work. The selected indices are in numerical order (no matter in which order you selected them), so you’ll be sliding indices on each deletion and will subsequently delete the wrong things. You won’t crash if you overreach on an index, because the For…Each loop will check for Nothing when it does a MoveNext internally and will exit gracefully, but this is actually worse since it may take longer before you notice a problem!

This won’t work either, and will potentially crash:

' Bad -- don't do this

For index As Integer = 0 To ListBox1.SelectedIndices.Count - 1

ListBox1.Items.RemoveAt(ListBox1.SelectedIndices(index))

Again, the indices for the downstream objects will decrease, you’ll delete the wrong things, and you’ll likely crash.

You can, however, iterate down instead, as long as you are confident that the selected indices are in numerical order (as they will be in this case):

' This works:

For index As Integer = ListBox1.SelectedIndices.Count - 1 To 0 Step -1

ListBox1.Items.RemoveAt(ListBox1.SelectedIndices(index))

Having found something that works via iteration, let’s now consider the enumeration angle instead. In general, I prefer to enumerate lists whenever possible instead of iterating through them. This is not one of those times, though. Consider this code, which will fail:

' Bad -- don't do this

For Each item In ListBox1.SelectedItems

ListBox1.Items.Remove(item)

“Well, c’mon, why doesn’t this work?” I hear you cry. “I don’t care about indices in this case, I’m not even using them; I’m just removing specific items.” True, but if you run this code, you will indeed get an exception essentially stating that the collection has been modified and the list of selected items is no longer valid for enumeration. We can’t work around this by assigning the collection of selected items to another variable and enumerating on that, since that just creates a reference to the same collection. In order for it to work, you’ve have to get the references out of the collection itself so that the ListBox is no longer part of the equation on the removal loop’s assessment.

' Really, this is just silly -- don't ever do this

Dim selItems As New Collection

For Each item In ListBox1.SelectedItems

selItems.Add(item)

For Each item In selItems

ListBox1.Items.Remove(item)

Functionally, this will work; however, you shouldn’t do it for two reasons:

· First of all, it’s stupid – you have to loop through twice. Occasionally, I do need to clone lists, like when creating an editable list from a read-only list – I’ve done that in a previous blogpost on this site, in fact. But my motives are not so noble here; I’m using this for no other reason than allowing enumeration to work.

· Second, each call to RemoveItem has a hidden cost – namely, the list has got to go find that item. In this case, you can bet that there’s good hashing going on that doesn’t make that as painful as it might be, but do you really want to count on that, given the better numeric alternative above?

No, just there’s really no good way to do removal by enumeration that I’ve ever found. And since each object is totally clueless about whether it itself is selected or not, you can’t even enumerate through the collection yourself and delete it if it’s marked as selected.

Of course, I’ve just talked about deletions, since they are more interesting than additions due to the crash potential. However, additions can also mess you up in a loop due to similar index changes, and I’ve actually run into cases where a list may have both insertions and deletions done, so that I wasn’t even able to leverage the change in list size as a clue to figure out what had happened to the data. The bottom line is, whenever doing an operation within a loop, you need to understand whether or not that operation will collide with your loop conditions and assumptions. Generally, you control this in your code, but in multithreaded environments, where changes to an existing store of data might be made from a different thread “simultaneously” with your thread, you really need to understand how thread-safe your code is with respect to data changes. (But that is a story for another time.)

‘Til next time,

--Matt--*

Hidden Costs (Matt Gertz)

VBTeam — Tue, 06 Oct 2009 22:54:00 GMT

(Note: there was a grievous error in this post based on a bad assumption on my art regarding VB. Not feeling the need to hide my ignorance :-), I have instead made a number of edits in this post to bring it back to some semblance of reality.)

One thing that gets me annoyed with myself is realizing that the product or service I’ve just bought has some hidden costs that I didn’t anticipate. It might be as complicated as realizing that my plane ticket has all sorts of byzantine surcharges and luggage costs, or as simple as making budgeting for a new killer gaming PC and forgetting about the sales tax – it seems that there are always extra costs out there that will come back to bite you. Being (as I have said in past postings to this blog) an inherently lazy person, and being fully caught up in our “I must have the sparkly thing right now” culture, I’m apt to overlook the fine print in any purchase agreement unless I really force myself to slow down and pay attention to the details.

One of the times I really have to pay attention is when I’m reviewing code here at Microsoft. As a member of the release team that makes the final decisions as to what last-minute fixes are safe enough to be applied to an imminent release, it’s my job to take a look at the proposed fix and make sure that it doesn’t introduce more problems than it purports to solve – i.e., that it doesn’t add hidden costs.

On the rare occasion that I find a problem in someone’s code, it’s usually something that’s obviously dysfunctional – a case where a variable isn’t initialized properly, or where a different team has simultaneously made a change that will render this change dangerous. But some of the problems are more subtle, and might not be obvious if only minimal testing and review has been done. Consider the following code (very similar to a case I reviewed here at work the other day):

Public MyList As New List(Of String)

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Dim s As New System.Text.StringBuilder

For i As Integer = 0 To MyList.Count - 1

s.Append(MyList(i))

End Sub

Edit: This is an error in my blog post – I hadn’t realized that VB, unlike many other languages, only gets the value of the stop condition once (thanks to Phil Wells for pointing this out). To make my point, I would have to be using code like this:

Dim s As New System.Text.StringBuilder

Dim i As Integer = 0

Do While i < MyList.Count() - 1

s.Append(MyList(i))

i += 1

Loop

The method Count() might still have a hidden cost, but in the For Loop case, I’m at least only hitting it once. The fact that VB only analyzes the stop condition once leads to a different issue to be aware of that I’ll cover in my next blog.

Seems pretty simple, yes? When a button is clicked, the code iterates through the strings in a list and appends them to a StringBuilder, creating (for whatever reason) one long string containing all of the contents. And, to cursory appearances, it will function correctly.

However, the code has hidden costs. You see, written this way, the value MyList.Count is going to be reevaluated on every iteration of the “For” loop, even though the value itself isn’t changing. Furthermore, my indexing into MyList, which is always with reference to the beginning of the list, will also have a non-zero impact. This impacts the performance of the code and will make my customers unhappy over the sloth-like operation of my application.

In this case, the cost isn’t really high, as Count() is a property wrapping something that’s stored as a private integer member, and index referencing also has tricks to speed it up, but there’s still a cost and it can add up. It’s even worse if the Count() call has to be calculated! Consider this really awful code where I’ve created my own “List” type:

Public Class MyLameObject

' For some unknown reason, I'm creating my own linked list instead of using a List(Of) generic.

' Please don't do this for real!

Public data As String

Public NextMLO As MyLameObject

Public Sub Insert(ByVal mlo As MyLameObject)

If NextMLO IsNot Nothing Then

NextMLO = mlo

Else

mlo.NextMLO = NextMLO.NextMLO

NextMLO.NextMLO = mlo

End If

End Sub

Public Function Count() As Integer

Dim ct As Integer = 0

Dim current As MyLameObject = Me

Do While current IsNot Nothing

ct += 1

current = current.NextMLO

Loop

Return ct

End Function

Public Function Item(ByVal index As Integer) As MyLameObject

If index >= Count() OrElse index < 0 Then Return Nothing

Dim current As MyLameObject = Me

For i As Integer = 0 To index - 1

current = current.NextMLO

Return current

End Function

End Class

Public MyLameObjectHeader As New MyLameObject

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _

Handles Button1.Click

Dim s As New System.Text.StringBuilder

For i As Integer = 0 To MyLameObjectHeader.Count - 1

s.Append(MyLameObjectHeader.Item(i))

End Sub

Perhaps as a school assignment, I’ve created a singly-linked list which contains objects of type “MyLameObject” (instead of using optimized collections that we provide). I’ve also created a member function called “Count” which returns the number of objects in my list (starting from the current node) and another member function called “Item” which returns me a reference to a specific object in the list, as indexed from the current node. The code will compile and it will “work.” But, oh! It has so many hidden costs, and if the definition of MyLameObject exists in an assembly for which I don’t have the source code, I might not even realize it!

First, let’s look at button click handler. It’s calling Count() on every single iteration, and there will be a number of iterations equal to the value returned from Count(). Count(), in turn, walks the entire list every time it’s called. So, that means that if my list contains 1000 items, that means that I’ll be referencing a MyLameObject one million times! (This is what they refer to as an “O(n²) problem” in computer science classes.)

But wait, it gets worse: ~~the code for Item() calls Count() also on each iteration to verify that the index is not out of bounds – that brings us up to a count of 1001000 MyLameObject references~~.

Edit: As noted above, that isn’t true for VB, though it would be for many other languages

And, of course, Item() itself needs to walk the list to actual get to the desired item, on every iteration – that adds 500500 more object hits (using the n(n+1)/2 formula) , for a grand total of ~~1501500~~ 1500500 object hits. And all that just to concatenate 1000 strings! That, I fear, is going to slow down my code’s performance somewhat.

Now, of course I could add code to get track of values for Count(), and that would reduce my cost to a third of what it was. I could use some clever hashing algorithm to more easily get to the items while still being able to use method calls. I could enumerate the list myself instead of relying on “Count” or on “Item,” and that would really cut my costs down dramatically. Or, best of all, I could avoid reinventing the wheel and using the classes that VB.NET already supplies for me, since we do our best to optimize them.

But that’s not the point that I’m trying to make here. The point is, whenever you call a function, you are at its mercy performance-wise – you are stuck with whatever hidden costs it contains. You might not even be able to determine what these hidden costs are if you don’t own the code you’re calling, except by experimentation. And if you call that function iteratively, you’re just compounding the problem.

Now, you can’t avoid making calls into code you don’t own – at some level, we all use libraries or assemblies that are handed to us. But you can be smart about how you use them~~. Consider *this* code:~~

~~Dim s As New System.Text.StringBuilder~~

~~Dim count As Integer = MyList.Count~~

~~For i As Integer = 0 To count - 1~~

~~s.Append(MyList(i))~~

~~Next~~

~~Now, I’m only calling Count() once, so I minimize the impact of its cost! Or,~~

Edit: As above, this doesn’t actually make a difference in VB. Of course, you still have the cost of “Count(),” whatever it may be. In this case, it’s just a property read; if it’s some home-grown collection or data repository, Count() (or it’s analog) could be a lot more costly.

Consider this even better example that you can use on collections that support IEnumerable (as all System.Collections types do):

Dim s As New System.Text.StringBuilder

For Each data As String In MyList

s.Append(data)

Yeah! Now I’m firing on all cylinders! Now I don’t have to worry about indexing costs either – I’m just walking the list, collecting my strings in the fastest way possible. Really, the only cost I have to deal with is the cost of actually appending the data (which is in fact why I’m using the highly-optimized StringBuilder class instead of just concatenating strings using a much more costly s &= data line).

So, rule of thumb: whenever calling any method, expect hidden costs (magnified if you’re in a loop) and work to minimize them. Call the methods outside of the loop if they are providing data that will remain the same throughout the loop, such as a count, and avoid them altogether if there’s an alternative way to iterate through the data that doesn’t implicitly involve resetting your position. Your customers will appreciate the time savings!

‘Til next time,

--Matt--*

Testing Events for Nothing/Null (Doug Rothaus)

VBTeam — Fri, 25 Sep 2009 20:10:00 GMT

While helping some Windows API folks with some sample code this week, I stumbled upon...uh...I mean “carefully researched” an issue that you might find handy.

You may be aware that the RaiseEvent statement automatically checks to verify if an event handler exists before raising the event. If the event is Nothing, then there’s no event handler and RaiseEvent terminates. If the event is not Nothing, then RaiseEvent triggers the event.

However, what if you want to follow a different code path if the event is Nothing? Unfortunately, the RaiseEvent statement doesn’t return a value that could indicate whether the event was fired. So, what’s a developer to do?

The answer? When the VB compiler sets up your event, it creates a private variable for the event in the form of <event name>Event. So, if I set up an event named TriggerMe, the VB compiler creates an event variable named TriggerMeEvent. You can test this variable for Nothing. It’s as simple as that! (Note: You won't see this variable using Intellisense, but you can find it when debugging or through reflection.)

Here’s a quick example:

Public Event SolutionFound As EventHandler

Private Sub OnSolutionFound()

If SolutionFoundEvent IsNot Nothing Then

RaiseEvent SolutionFound(Me, New EventArgs())

Else

' No event handler has been set.

MsgBox("There is no event handler. That makes me sad.")

End If

End Sub

Properties vs Fields – Why Does it Matter? (Jonathan Aneja)

VBTeam — Sat, 05 Sep 2009 00:01:47 GMT

The other day I got an email from a developer asking an interesting question about VB10’s Auto-implemented Properties feature.

“I am, however, somewhat confused regarding the properties feature you mentioned - i.e. turning 11 lines of get/set/backing variable into one line. Wouldn't this be exactly the same as the existing functionality of creating a public variable? I see no benefit for using a property in this case, except perhaps for the sake of what some would consider best practice.”

On the surface there doesn’t seem to be a big difference between this:

Public Property Name() As String

And this:

Public Name() As String

Clearly both will expose an object’s state to the outside world, and can be read/modified using the exact same syntax. Which then begs the question, why would I ever use a property if I have no special logic in the Getter/Setter?

Let’s consider some reasons:

1. Fields can’t be used in Interfaces

You can’t enforce the existence of a field in an object’s public contract through an interface. For properties though it works fine.

2. Validation

While your application currently may not require any validation logic to set a particular value, changing business requirements may require inserting this logic later. At that point changing a field to a property is a breaking change for consumers of your API. (For example if someone was inspecting your class via reflection).

3. Binary Serialization

Changing a field to a property is a breaking change if you’re using binary serialization. Incidentally, this is one of the reasons VB10’s auto-implemented properties have a “bindable” backing field (i.e. you can express the name of the backing field in code) – that way, if you change an auto-implemented property to an expanded property, you can still maintain serialization compatibility by keeping the backing field name the same (in C# you’re forced to change it because it generates backing fields with unbindable names).

4. A lot of the .NET databinding infrastructure binds to properties but not fields

I’ve heard arguments on both sides as to whether or not that’s a good thing, but the reality is that’s the way it works right now.

5. Exposing a public field is an FxCop violation

For many of the reasons listed above :)

One argument I’ve heard for using fields over properties is that “fields are faster”, but for trivial properties that’s actually not true, as the CLR’s Just-In-Time (JIT) compiler will inline the property access and generate code that’s as efficient as accessing a field directly.

For these reasons and more, in most cases you’re better off using a property rather than exposing a public field. Thankfully VB10 will make this a lot easier :)

TechEd Video: Future Directions for Visual Basic, by Anders Hejlsberg and Jonathan Aneja

VBTeam — Sat, 20 Jun 2009 18:35:00 GMT

As part of the new VB/C# co-evolution strategy, Visual Studio Technical Fellow Anders Hejlsberg has broadened his role. In addition to being Chief Architect for C#, he now sets the direction for both the VB.NET and C# languages.

At TechEd, Anders participated in both the VB.NET and C# language presentations. In watching these sessions, you can see that the future trends and directions for the VB.NET and C# languages are now the same.

TechEd NA 2009 Session Video: "Future Directions for Visual Basic" by Anders Hejlsberg and Jonathan Aneja

In this talk, we discuss the future direction of the Visual Basic language both in the near and long term. Exciting features from the next release are demonstrated and discussed, including extensions to LINQ support, syntax simplifications, and improvements to the IDE. Larger trends that are likely to deeply influence the direction of the language are also covered, including dynamic binding, meta-programming, and scripting. Finally, we discuss how all these tie together into the roadmap for Visual Basic going forward.

The C# TechEd US video is not publicly available. For the corresponding C# presentation, please watch the following from PDC:

PDC 2008 Session Video: "The Future of C#" by Anders Hejlsberg

In this talk Microsoft Technical fellow and C# Chief Architect Anders Hejlsberg outlines the future of C#. He describes the many forces that influence and shape the future of programming languages and explain how they fit into C#.

Implicit Line Continuation (Kathleen McGrath)

VBTeam — Fri, 19 Jun 2009 23:32:53 GMT

In the second part of my interview with Doug Rothaus, he describes the new implicit line continuation feature in Visual Basic 2010. Learn about the most common scenarios that no longer require the underscore character (_) in the topic, Statements in Visual Basic.

See the Video: implicit Line Continuation

--Kathleen McGrath
http://blogs.msdn.com/kathleen

Auto-Implemented Properties (Kathleen McGrath)

VBTeam — Sat, 13 Jun 2009 00:46:04 GMT

In this interview, Doug Rothaus, a programming writer on the Visual Studio User Education team, describes the auto-implemented properties in Visual Basic 2010. He also demonstrates some of the code examples in his Help topic: Auto-Implemented Properties.

See the Video: Auto-Implement Properties.

--Kathleen

Try Out Dotfuscator in VS 2010 Beta 1!

VBTeam — Thu, 11 Jun 2009 04:03:43 GMT

The team at PreEmptive Solutions recently posted a great blog article that walks through all the latest features in VS 2010's Dotfuscator Software Services - Community Edition (previously known as Dotfuscator CE). Browse through the article to learn what's new, or download the beta to follow along in the IDE.

What's New with Dotfuscator in Visual Studio 2010 Beta 1 by Bill Leach

VS2010 Beta1 Extensibility News (Lisa Feigenbaum)

VBTeam — Wed, 10 Jun 2009 19:47:50 GMT

I recently received this letter from the Visual Studio Extensibility team, that I thought would be interesting to readers of this blog. Whether you're building Visual Studio extensions or downloading them from others, there's news here for you.

News from the Visual Studio Extensibility team…

Are you building new tools to simplify your life or change the way people work? Check out the opportunities to create innovative extensions for Visual Studio 2010.

Examples of cool things you can do:

· Overlay rich metadata on top of the editor to bring new information to your fingertips

· Develop new project templates to accelerate your work (examples: New Project Dialog)

· Create innovative user interface elements using the WPF Shell

· Upload your extension to the Visual Studio Gallery (http://visualstudiogallery.com) to find it in the Extension Manager

Other things you should know:

· With v2 of the Visual Studio Gallery that went live on 5/14, you can use the Extension Manager to find products from the ecosystem from within Visual Studio

*(with Beta1, the Extension Manager will only surface extensions posted to the Gallery in the VSIX file format; Beta2 will include the MSI format)

· We just released the new SDK along with the new Shell redistributables, look for them at the dev center: http://msdn.com/vsx

· If you’re developing extensions for VS 2010, you’ll want to stay tuned to the dev center for more information

Fun things to help you get started – these can be found in the Extension Manager (Tools>Extension Manager): search for Editor Extensions

DemoDashboard Sample:

The DemoDashboard sample is a WPF “dashboard” designed for folks presenting demos in VS2010 to get real-time audience feedback via Twitter. Use this sample to give presentations, build your own widgets, etc. The wiki on the CodePlex site will give you all the info you need to get started. You can share the feedback you get with your followers on Twitter.

get it: Tools>Extension Manager

or from the Gallery: here

source: http://demodashboard.codeplex.com

RegEx Editor Sample

This sample was built to ease the your pain when working with regular expressions. It shows re-hosting of the editor in a window and provides a nice starting point for similar projects.

get it: Tools>Extension Manager

or from the Gallery: here

source: http://editorsamples.codeplex.com

Custom Intellisense Sample

This sample provides a custom WPF-based UI for Intellisense -- with databinding and other cool features. You might want to use it as-is, you might want to personalize it, you might want to build new features for it – the choice is yours.

get it: Tools>Extension Manager

or from the Gallery: here

source: http://editorsamples.codeplex.com

Image Insertion Sample

This sample is all about visualizing resources inline, it provides some nice transparency effects when you’re dragging an image from the solution explorer, and will automatically resize text to fit the image.

get it: Tools>Extension Manager

or from the Gallery: here

source: http://editorsamples.codeplex.com

FAQ:

What is the Extension Manager and how do I find it?

The Extension Manager in Visual Studio enables developers to discover Visual Studio Extensions from within the product itself. It consumes data directly from the Visual Studio Gallery, giving developers direct access to partner and community products that extend and enhance Visual Studio. If you have a free or free trial version of your product hosted on the Visual Studio Gallery, a developer will be able to download and install that product directly from within the IDE. (In Beta1, the in-product experience will show only extensions uploaded as a VSIX. In Beta 2 we will expand the in-product experience to also include extensions uploaded as MSI and reference links to other download sites.)

The Extension Manager enables a developer to install, upgrade, uninstall, enable, and disable extensions, making it easier to manage a portfolio of extensions.

To find the Extension Manager: Tools>Extension Manager.

So this means the Visual Studio Gallery can now host downloads?

Yes, we’re excited to announce that the Visual Studio Gallery can now host your downloads. Keep in mind that at this time the gallery does not include a commerce framework so we recommend creating a free or free trial version of your product that can be hosted on the Visual Studio Gallery. Of course we still support reference links for users who prefer to host their own downloads.

What else is new @ the Visual Studio Gallery?

Thanks to some great work by the MSDN team we’ve moved the Visual Studio Gallery to be part of MSDN. Some of the benefits:

· The new navigation model supports all types of Visual Studio Extensions and has sections for Tools, Controls, and Templates

· The integration with MSDN now gives users a chance to take advantage of a shared profile across all MSDN properties. Contributing to the gallery can enhance your MSDN reputation giving high quality contributors the recognition they deserve.

· Visual Studio Gallery contributions offer an optional discussion board to separate your reviews and give contributors an opportunity to post updates, respond to feedback, & discuss bugs.

· All entries include a usage chart to give contributors a sense of which of their products are getting the most traffic on the Visual Studio Gallery.

What’s the deal with the VSIX file format I’ve heard about?

Both the new Visual Studio Gallery and the Extension Manager work with .VSIX files, which is a new deployment model for extensions, similar to a renamed .ZIP file. This transition provides Visual Studio users a new low-overhead, reliable way to deploy Visual Studio Extensions. There’s tooling available to help you with this, and you can find instructions and other helpful tips at the Visual Studio Extensibility Dev Center: http://msdn.com/vsx.

Questions?

Email catherine.crim@microsoft.com