Search results for 'app:weblogs' matching tag 'C#'

Migrating from Visual Studio 2010 beta 1 to beta 2 – solution file change required

skeet — Mon, 26 Oct 2009 05:00:00 GMT

Having installed Visual Studio 2010 beta 2 on my freshly-reinstalled netbook (now with Windows 7 and and SSD – yummy) I found that my solution file from Visual Studio 2010 beta 1 wasn’t recognised properly: double-clicking on the file didn’t do anything. Opening the solution file manually was absolutely fine, but slightly less convenient than being able to double-click.

After a bit of investigation, I’ve found the solution. Manually edit the solution file, and change the first few lines from this:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 10

to this:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010

It's just a case of changing "10" to "2010".

Hopefully between this and the linked SuperUser post, this should avoid others feeling the same level of bafflement :)

Unit Testing: Execution

DeborahK — Sun, 25 Oct 2009 05:00:00 GMT

Visual Studio 2008 (Professional Edition and above) provides a really nice set of tools for development and execution of unit tests.

[To begin with an overview of unit testing, start here.]

This prior post demonstrates how to build a unit test using the "Create Unit Tests..." feature of the Code Editor. This post demonstrates how to execute a unit test.

NOTE: This post assumes you have already generated or created at least one unit test.

To execute one or more unit tests:

1) Open your solution in Visual Studio.

The solution should include both the project(s) to test and the test project(s).

2) Select Test | Windows | Test View from the menu to view the Test View window. This window contains every method marked with the TestMethod attribute.

The solution used for the screenshot above has two LastNameTest unit tests: One for the VB example and one for the C# example. If you coded along from the prior unit testing post, you will only have one for whichever language you selected. If you have been creating unit tests for one of your projects, you may have hundreds of tests in this list.

To execute unit tests:

1) Select one or more tests from the list of tests in the Test View window.

You can add columns and sort the list or use the filter feature to make it easier to locate and select the desired tests to execute.

2) Click the Run Selection button in the upper left corner of the Test View window or right-click on any selected test and select "Run Selection" from the context menu.

The selected test(s) will then execute, displaying their status in the Test Results window:

When the test is complete, the Test Results window will look something like this:

Both of the tests shown in the above screenshot are marked as Inconclusive because the generated unit testing code used the Assert class Inconclusive method. The generated unit testing template is designed to prevent a false positive. It generates an inconclusive result until you update the unit test with correct valid and invalid values and remove the Inconclusive method call.

To see more information on the result of the test, double-click on a test result.

To run the test again, use the Run or Debug buttons at the top of the Test Results window.

If any of the tests don't pass, they are marked as Failed in the Test Results window as shown below.

Double click on any of the failed tests to view the test results:

The Error Stack Trace at the bottom of this window gives you further information on the source of the failure. Click on any link in the stack trace to jump to the associated location in the code.

You can also debug the code as the test is executing if you "Debug Selection" option instead of the "Run Selection" option.

After you update the unit tests with valid code and the tests pass, the Test Results will appear as follows:

Notice the color-coded green passing indicator.

Enjoy!

Unit Testing: An Introduction

DeborahK — Sun, 25 Oct 2009 05:00:00 GMT

If you have Visual Studio 2008 or later and have the Professional Edition or better (NOT the Express Editions), you have some very nice unit testing tools within your Visual Studio environment. These tools help you write, execute, and track your unit tests and code coverage. This post provides an introduction to using these tools.

If you are new to unit testing, the idea is to test the smallest possible units of your code. In most cases, the smallest units of code are the property procedures and methods of your classes.

For more general information about the purpose of unit testing, see this link.

NOTE: Unit testing is not meant to replace integration testing, system testing, or user testing.

In some development methodologies, such as Test Driven Development (TDD), unit tests are written before the code is written. You capture the basic requirements in the unit test and then write the code. The code is complete when the unit tests pass. Visual Studio 2010 has features to assist with this "unit test first" approach.

But this introduction demonstrates how to write unit tests for existing code. This technique is helpful if you follow a code-first approach or if you received code from another source or have old code that did not originally have unit tests.

Build the Code

The business object tested in this post is a simplified Customer class that uses the business object base class defined in this post.

The Customer class is shown below.

In C#:

public class Customer: BoBase
{
    private int? _CustomerId;
    public int? CustomerId
    {
        get { return _CustomerId; }
        internal set
        {
            if (_CustomerId == null || !_CustomerId.Equals(value))
            {
                string propertyName = "CustomerId";
                // Perform any validation here
                if (!_CustomerId.Equals(value))
                {
                    _CustomerId = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }

    private string _LastName;
    public string LastName
    {
        get { return _LastName; }
        set
        {
            if (_LastName == null || _LastName != value)
            {
                string propertyName = "LastName";
                // Perform any validation here
                if (_LastName != value)
                {
                    _LastName = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }

    private string _FirstName;
    public string FirstName
    {
        get { return _FirstName; }
        set
        {
            if (_FirstName == null || _FirstName != value)
            {
                string propertyName = "FirstName";
                // Perform any validation here
                if (_FirstName != value)
                {
                    _FirstName = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }

    private string _EmailAddress;
    public string EmailAddress
    {
        get { return _EmailAddress; }
        set
        {
            if (_EmailAddress == null || _EmailAddress != value)
            {
                string propertyName = "EmailAddress";
                // Perform any validation here
                if (_EmailAddress != value)
                {
                    _EmailAddress = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }
}

In VB:

Public Class Customer
Inherits BOBase

    Private _CustomerId As Integer?
    Public Property CustomerId() As Integer?
        Get
            Return _CustomerId
        End Get
        Friend Set(ByVal value As Integer?)
           If _CustomerId Is Nothing OrElse _
                    Not _CustomerId.Equals(value) Then
              Dim propertyName As String = "CustomerId"
              ' Perform any validation
              If Not _CustomerId.Equals(value) Then
                 _CustomerId = value
                 SetEntityState(EntityStateType.Modified, propertyName)
                End If
            End If
        End Set
    End Property

    Private _FirstName As String
    Public Property FirstName() As String
        Get
            Return _FirstName
        End Get
        Set(ByVal value As String)
            If _FirstName Is Nothing OrElse _
                                _FirstName IsNot value Then
                Dim propertyName As String = "FirstName"
                ' Perform any validation
                If _FirstName IsNot value Then
                    _FirstName = value
                    SetEntityState(EntityStateType.Modified, _
                                                  propertyName)
                End If
            End If
        End Set
    End Property

    Private _LastName As String
    Public Property LastName() As String
        Get
            Return _LastName
        End Get
        Set(ByVal value As String)
            If _LastName Is Nothing OrElse _
                                 _LastName IsNot value Then
                Dim propertyName As String = "LastName"
                ' Perform any validation
                If _LastName IsNot value Then
                    _LastName = value
                    SetEntityState(EntityStateType.Modified, _
                                                  propertyName)
                End If
            End If
        End Set
    End Property

    Private _EmailAddress As String
    Public Property EmailAddress() As String
        Get
            Return _EmailAddress
        End Get
        Set(ByVal value As String)
            If _EmailAddress Is Nothing OrElse _
                             _EmailAddress IsNot value Then
                Dim propertyName As String = "EmailAddress"
                ' Perform any validation
                If _EmailAddress IsNot value Then
                    _EmailAddress = value
                    SetEntityState(EntityStateType.Modified, _
                                                  propertyName)
                End If
            End If
        End Set
    End Property
End Class

The first if statement in each of the property procedures for the Customer class checks whether the current value is null or was changed. If the property is changed, you want to revalidate it, set it as modified, and generate a PropertyChanged event (which is handled in the SetEntityState method).

NOTE: C# uses a != operator to judge whether the value was changed. VB cannot use the <> operator because VB propagates null values. So if either value is null (nothing) the result is false. (See this msdn entry for more information.) To prevent this problem, IsNot is used in the VB code to determine if the value was changed.

The null check allows for possible validation of required fields (that is, fields that cannot be null or empty). If you know you will never need a null validation check, you can leave the null check off the first if statement.

The propertyName variable defines a name that you can use in any validation error messages and it is the name used in the PropertyChanged event.

You can then perform any necessary validation. In this simple example, no validation was added. If you want to see an example of some validation, check out this post.

Finally, if the value was changed, the backing variable is set to the new value and the SetEntityState method is called to mark the business object as "dirty" and to generate the PropertyChanged event.

Define the Testing Scenarios

So let's start with the test of the LastName property. Looking at the requirements, the following testing scenarios are required:

Initial null value; set to null value (should perform validation but not set the dirty flag)
Initial null value; set to valid string (should perform validation and set the dirty flag)
Initial null value; set to empty string (should perform validation and set the dirty flag)
Initial string value; set to null value (should perform validation and set the dirty flag)
Initial string value, set to different string value (should perform validation and set the dirty flag)
Initial string value, set to same string value (should not perform validation and not set the dirty flag)
Initial string value, set to empty value (should perform validation and set the dirty flag)

And if you have validation code, you will have more scenarios to test valid and invalid values. But this is enough to give you the general idea.

So now let's generate the unit test for the LastName property using the tools provided in Visual Studio (Professional Edition or above).

Generate the Unit Test

The following are the steps for generating the unit test for a particular property procedure or method:

1) Open the Code Editor for the code you want to test.

2) Right-click and select Create Unit Tests... from the context menu.

The following dialog will appear:

3) Select the properties, methods, or constructors you wish to test.

If you were in a specific property procedure or method, that procedure or method is automatically checked in this dialog. You can select to generate tests for any properties, methods, or constructors using this dialog.

Notice the Output project combobox on this dialog. Using this combobox, you can create a new C# unit test, new VB unit test, or select any existing unit test project if you already have some in your solution. This allows you to add unit tests to existing unit testing projects at any point in the development process.

4) Click OK.

5) If you are creating a new C# or VB project, enter the project name and click Create.

6) The test project is then added to your Solution Explorer.

If you created a VB test project, the result is the same, but with a CustomerTest.vb file within the BoTest project.

View the Generated Code

Visual Studio automatically creates an first cut of your unit testing code.

In C#:

Double-click on CustomerTest.cs to view the code.

/// <summary>
///A test for LastName
///</summary>
[TestMethod()]
public void LastNameTest()
{
    Customer target = new Customer(); // TODO: Initialize to an appropriate value
    string expected = string.Empty; // TODO: Initialize to an appropriate value
    string actual;
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual);
    Assert.Inconclusive("Verify the correctness of this test method.");
}

In VB:

Double-click on CustomerTest.vb to view the code.

'''<summary>
'''A test for LastName
'''</summary>
<TestMethod()> _
Public Sub LastNameTest()
    Dim target As Customer = New Customer ' TODO: Initialize to an appropriate value
    Dim expected As String = String.Empty ' TODO: Initialize to an appropriate value
    Dim actual As String
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual)
    Assert.Inconclusive("Verify the correctness of this test method.")
End Sub

The TestMethod attribute defines this method as a unit test. It is then picked up by the other unit testing tools within Visual Studio.

The generated code includes some ToDo notes, defining where you should change the code.

The Assert class is a key aspect of your unit tests. It provides many methods that you can use to assert whether your test produced expected results.

The generated code uses two of the Assert class methods. The AreEqual method determines whether the expected and actual values are equal. If not, it fails the test.

The Inconclusive method always causes the test to fail. This is added to all generated code to ensure that the test will fail until you modify the test with valid values.

At this point, you can try to execute this unit test, or update it first and then execute it.

See the following posts for more information:

Unit Testing: Execution
Unit Testing: Code Coverage
Unit Testing: Testing Properties

Enjoy!

Iterating atomically

skeet — Fri, 23 Oct 2009 05:00:00 GMT

The IEnumerable<T> and IEnumerator<T> interfaces in .NET are interesting. They crop up an awful lot, but hardly anyone ever calls them directly - you almost always use a foreach loop to iterate over the collection. That hides all the calls to GetEnumerator(), MoveNext() and Current. Likewise iterator blocks hide the details when you want to implement the interfaces. However, sometimes details matter - such as for this recent Stack Overflow question. The question asks how to create a thread-safe iterator - one that can be called from multiple threads. This is not about iterating over a collection n times independently on n different threads - this is about iterating over a collection once without skipping or duplicating. Imagine it's some set of jobs that we have to complete. We assume that the iterator itself is thread-safe to the extent that calls from different threads at different times, with intervening locks will be handled reasonably. This is reasonable - basically, so long as it isn't going out of its way to be thread-hostile, we should be okay. We also assume that no-one is trying to write to the collection at the same time.

Sounds easy, right? Well, no... because the IEnumerator<T> interface has two members which we effectively want to call atomically. In particular, we don't want the collection { "a", "b" } to be iterated like this:

Thread 1	Thread 2
MoveNext()
	MoveNext()
Current
	Current

That way we'll end up not processing the first item at all, and the second item twice.

There are two ways of approaching this problem. In both cases I've started with IEnumerable<T> for consistency, but in fact it's IEnumerator<T> which is the interesting bit. In particular, we're not going to be able to iterate over our result anyway, as each thread needs to have the same IEnumerator<T> - which it won't do if each of them uses foreach (which calls GetEnumerator() to start with).

Fix the interface

First we'll try to fix the interface to look how it should have looked to start with, at least from the point of view of atomicity. Here are the new interfaces:

public interface IAtomicEnumerable<T>
{
IAtomicEnumerator<T> GetEnumerator();
}

public interface IAtomicEnumerator<T>
{
bool TryMoveNext(out T nextValue);
}

One thing you may notice is that we're not implementing IDisposable. That's basically because it's a pain to do so when you think about a multi-threaded environment. Indeed, it's possibly one of the biggest arguments against something of this nature. At what point do you dispose? Just because one thread finished doesn't mean that the rest of them have... don't forget that "finish" might mean "an exception was thrown while processing the job, I'm bailing out". You'd need some sort of co-ordinator to make sure that everyone is finished before you actually do any clean-up. Anyway, the nice thing about this being a blog post is we can ignore that little thorny issue :)

The important point is that we now have a single method in IAtomicEnumerator<T> - TryMoveNext, which works the way you'd expect it to. It atomically attempts to move to the next item, returns whether or not it succeeded, and sets an out parameter with the next value if it did succeed. Now there's no chance of two threads using the method and stomping on each other's values (unless they're silly and use the same variable for the out parameter).

It's reasonably easy to wrap the standard interfaces in order to implement this interface:

/// <summary>
/// Wraps a normal IEnumerable[T] up to implement IAtomicEnumerable[T].
/// </summary>
public sealed class AtomicEnumerable<T> : IAtomicEnumerable<T>
{
    private readonly IEnumerable<T> original;

    public AtomicEnumerable(IEnumerable<T> original)
    {
        this.original = original;
    }

    public IAtomicEnumerator<T> GetEnumerator()
    {
        return new AtomicEnumerator(original.GetEnumerator());
    }

    /// <summary>
    /// Implementation of IAtomicEnumerator[T] to wrap IEnumerator[T].
    /// </summary>
    private sealed class AtomicEnumerator : IAtomicEnumerator<T>
    {
        private readonly IEnumerator<T> original;
        private readonly object padlock = new object();

        internal AtomicEnumerator(IEnumerator<T> original)
        {
            this.original = original;
        }

        public bool TryMoveNext(out T value)
        {
            lock (padlock)
            {
                bool hadNext = original.MoveNext();
                value = hadNext ? original.Current : default(T);
                return hadNext;
            }
        }
    }
}

Just ignore the fact that I never dispose of the original IEnumerator<T> :)

We use a simple lock to make sure that MoveNext() and Current always happen together - that nothing else is going to call MoveNext() between our TryMoveNext() calling it, and it fetching the current value.

Obviously you'd need to write your own code to actually use this sort of iterator, but it would be quite simple:

T value;
while (iterator.TryMoveNext(out value))
{
// Use value
}

However, you may already have code which wants to use an IEnumerator<T>. Let's see what else we can do.

Using thread local variables to fake it

.NET 4.0 has a very useful type called ThreadLocal<T>. It does basically what you'd expect it to, with nice features such as being able to supply a delegate to be executed on each thread to provide the initial value. We can use a thread local to make sure that so long as we call both MoveNext() and Current atomically when we're asked to move to the next element, we can get back the right value for Current later on. It has to be thread local because we're sharing a single IEnumerator<T> across multiple threads - each needs its own separate storage.

This is also the approach we'd use if we wanted to wrap an IAtomicEnumerator<T> in an IEnumerator<T>, by the way. Here's the code to do it:

public class ThreadSafeEnumerable<T> : IEnumerable<T>
{
    private readonly IEnumerable<T> original;

    public ThreadSafeEnumerable(IEnumerable<T> original)
    {
        this.original = original;
    }

    public IEnumerator<T> GetEnumerator()
    {
        return new ThreadSafeEnumerator(original.GetEnumerator());
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    private sealed class ThreadSafeEnumerator : IEnumerator<T>
    {
        private readonly IEnumerator<T> original;
        private readonly object padlock = new object();
        private readonly ThreadLocal<T> current = new ThreadLocal<T>();

        internal ThreadSafeEnumerator(IEnumerator<T> original)
        {
            this.original = original;
        }

        public bool MoveNext()
        {
            lock (padlock)
            {
                bool ret = original.MoveNext();
                if (ret)
                {
                    current.Value = original.Current;
                }
                return ret;
            }
        }

        public T Current
        {
            get { return current.Value; }
        }

        public void Dispose()
        {
            original.Dispose();
            current.Dispose();
        }

        object IEnumerator.Current
        {
            get { return Current; }
        }

        public void Reset()
        {
            throw new NotSupportedException();
        }
    }
}

I'm going to say it one last time - we're broken when it comes to disposal. There's no way of safely disposing of the original iterator at "just the right time" when everyone's finished with it. Oh well.

Other than that, it's quite simple. This code has the serendipitous property of actually implementing IEnumerator<T> slightly better than C#-compiler-generated implementations from iterator blocks - if you call the Current property without having called MoveNext(), this will throw an InvalidOperationException, just as the documentation says it should. (It doesn't do the same at the end, admittedly, but that's fixable if we really wanted to be pedantic.

Conclusion

I found this an intriguing little problem. I think there are better ways of solving the bigger picture - a co-ordinator which takes care of disposing exactly once, and which possibly mediates the original iterator etc is probably the way forward... but I enjoyed thinking about the nitty gritty.

Generally speaking, I prefer the first of these approaches. Thread local variables always feel like a bit of a grotty hack to me - they can be useful, but it's better to avoid them if you can. It's interesting to see how an interface can be inherently thread-friendly or not.

One last word of warning - this code is completely untested. It builds, and I can't immediately see why it wouldn't work, but I'm making no guarantees...

dynamic and indexer

Matthieu MEZIL — Wed, 21 Oct 2009 05:00:00 GMT

Remember one year ago, I wrote a post on how to use reflection with dynamic keyword. At this moment, I sent an email to MS to add an indexer in dynamic. I don’t know if my email changed any thing but I am very happy to see that from .NET 4.0 Beta 2, we are now able to use it.

So in my sample, instead of

result = dynamicSpBase.get_Item(name);

I can now directly write this:

result = dynamicSpBase[name];

Great!

Populating a DataGridView from Xml Data

DeborahK — Tue, 20 Oct 2009 05:00:00 GMT

If you are using XML in a WinForms application you may find the need to display the XML data in a DataGridView.

Let's take this XML:

<states>
    <state name="California">
        <abbreviation>CA</abbreviation>
        <year>1850</year>
        <governor>Schwarzenegger</governor>
    </state>
    <state name="Wisconsin">
        <abbreviation>WI</abbreviation>
        <year>1848</year>
        <governor>Doyle</governor>
    </state>
</states>

Displaying XML in a DataGridView sounds easy, but if you just set the DataGridView DataSource to the XML data, you will get something like this:

Notice how it has lots of yuck in it: attribute details, node properties, and so on for every node in the XML. So how do you get something more like this:

The trick is to use anonymous types.

The code is provided here in VB and C# and then described in detail below.

NOTE: Be sure to set a reference to System.Core and System.Xml.Linq

In C#:

XElement statesXml = XElement.Parse("<states>" +
    "<state name='California'>" +
        "<abbreviation>CA</abbreviation>" +
        "<year>1850</year>" +
        "<governor>Schwarzenegger</governor>" +
    "</state>" +
    "<state name='Wisconsin'>" +
        "<abbreviation>WI</abbreviation>" +
        "<year>1848</year>" +
        "<governor>Doyle</governor>" +
    "</state>" +
   "</states>");

var query = from st in statesXml.Descendants("state")
            select new
            {
                Name = st.Attribute("name").Value,
                Abbrev = st.Element("abbreviation").Value,
                Year = st.Element("year").Value,
                Governor = st.Element("governor").Value
            };
DataGridView1.DataSource = query.ToList();

In VB:

Dim statesXml As XElement = _
    <states>
        <state name="California">
            <abbreviation>CA</abbreviation>
            <year>1850</year>
            <governor>Schwarzenegger</governor>
        </state>
        <state name="Wisconsin">
            <abbreviation>WI</abbreviation>
            <year>1848</year>
            <governor>Doyle</governor>
        </state>
    </states>

Dim query = From st In statesXml...<state> _
            Select New With { _
                  .Name = st.@name, _
                  .Abbrev = st.<abbreviation>.Value, _
                  .Year = st.<year>.Value, _
                  .Governor = st.<governor>.Value}
DataGridView1.DataSource = query.ToList

The first part of this code builds the XML. The C# code uses the XElement.Parse function to build the XML; VB uses XML literals. This part of the code is not necessary if you are reading the XML from another source, such as a file.

The second part of the code leverages Linq to XML to process the set of state XML elements. For each element, it uses the Select New syntax to create an anonymous type. The syntax defines an unnamed (anonymous) type with properties Name, Abbrev, Year, and Governor.

[To view an overview of anonymous types, start here.]

The last line converts the results of the query to a generic list and assigns it to the DataSource property of the DataGridView. Visual Studio uses the anonymous type property names as the text for the column titles and populates the rows with each state element.

Use this technique any time you have XML that you want to display in a DataGridView.

Enjoy!

Error when trying to open XAML options in VS 2008

Anonymous — Tue, 20 Oct 2009 05:00:00 GMT

Hi All,

After installing Silverlight 3.0 tools with VS 2008 SP1 i was not able to open XAML options in VS 2008 IDE.

I was submitted a ticket in MS Connect website, and the fix is:
1) Close all VS 2008 instances.
2) Open VS 2008 Command prompt
3) Type : devenv /resetskippkgs

This is the fix for the problem by resetting all IDE packages.

Ticket url:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=496402

Hope it helps.

Regards,
Mostafa arafa

Session management in WCF service - client & server

Anonymous — Tue, 20 Oct 2009 05:00:00 GMT

Hi Folks,

I got the following email from one of my blog readers, here is his email:
"
Hi.. Marafacs,
I have a problem about WCF chat based on client-server. How to make a deal between server and client? So server can send message, show active client list, kick user.
Thanks for response.
"

To do this, you have first to configure your WCF to accept only client calls with sessions, and this is can be achieved by configuring the WCF with Service Throttling and configuring MaxConcurrentCalls,MaxConcurrentInstances and MaxConcurrentSessions.

Read this section to know how to configure this - page 331:
http://books.google.com/books?id=-AUyj6S7etwC&pg=PA331&dq=how+to+get+active+sessions+in+WCF&ei=tsTdStrhKITUNc_B9IEP#v=onepage&q=&f=false

To know, how the client can generate sessions and unique identifiers to the server, check below KB article, this is related to instance context sharing:

http://msdn.microsoft.com/en-us/library/aa354514.aspx

Hope this helps.

Regards,
Mostafa arafa

Visual Studio 2010 Beta 2 released

Joacim — Tue, 20 Oct 2009 05:00:00 GMT

Yesterday Microsoft had a big announcement day. At the same time as Steve Ballmer held his keynotes at the SharePoint Developers Conference (see the video) Microsoft released Visual Studio 2010 Beta 2 for MSDN subscribers, the public release will be tomorrow, October 21st. They also announced that the official release date of Visual Studio 2010 and the .Net 4.0 Framework will be on March 22nd, 2010.

Visual Studio has been given a new blue-purple logo and at the same time the MSDN web site has also been given a face lift using this blue-purple color scheme. If you have visited the Visual Basic Developer Center recently you may have already seen the preview of the new MSDN look. In my opinion it’s much nicer compared to the old red color scheme it had before.

With the beta release Microsoft also released Visual Studio 2010 Tools for SharePoint.

Microsoft have compiled a lot of 2010 resources on the VB and C# Developer Centers: VB 2010 Resources, C# 2010 Resources. They have also released a number of How do I videos. Note, the first two links will be available very soon, if they aren’t already.

How Do I: Use auto-implemented properties?
How Do I: Use implicit line continuations in VB 10?
How Do I: Use highlight reference in the Visual Studio 2010 IDE?
How Do I: Use Code Snippets in the Visual Studio IDE?
How Do I: Use Generate from Usage in Visual Studio 2010?
How Do I: Enhance performance in the Visual Studio 2010 IDE when editing VB code?
How Do I: Step with the debugger in Visual Studio?
How Do I: Refactor my code in Visual Studio (Part 1 and Part 2)

I have looked forward to this beta release for a long time now, even though I have used Beta 1 since it was released back in May, beta 2 is much more promising simply because everything should be in place by now. Microsoft will probably not add any new features but rather just fix any bugs that are reported and concentrate on performance issues. So I can now start doing some real world testing and finally concentrate on to fully learn the new features of the framework. This of course also means that you can expect to see a lot more posts about VS2010 on this blog in the near future.

Have fun, I know I will. :)

Lambda Expressions: Execution

DeborahK — Fri, 16 Oct 2009 05:00:00 GMT

Lambda expressions can be assigned to a delegate variable. The lambda expression is then executed when the delegate is called.

[To begin with an overview of lambda expressions, start here.]

In the following example, a lambda expression is assigned to a variable (f).

In C#:

Func<int,string> f = x => (x + x).ToString();
Debug.WriteLine(f(5));
Debug.WriteLine(f(10));

In VB:

Dim f = Function(x as Integer) (x + x).ToString()
Debug.WriteLine(f(5))
Debug.WriteLine(f(10))

The lambda expression in this example is a Func<int, string> [Func(Of Integer, String) in VB] meaning it takes one integer input parameter and returns a string. The lambda expression simply takes the input value, adds it to itself, and returns the result as a string.

[For more information on Func delegates, see this post.]

When the expression is defined, it is not executed. It is not executed until it is called.

The first Debug.WriteLine statement calls the lambda expression, passing in a 5. The result displays "10" in the debug window.

The second Debug.WriteLine statement calls the lambda expression again, passing in a 10. The result displays "20" in the debug window.

Lambda expressions are executed when they are called, not when they are constructed. This is important to consider, especially when the lambda expression contains local variables.

Local variables used in a lambda expression are “captured” or “lifted”. The variable value used is the value at execution time. The variable lifetime extends to the lifetime of the delegate.

The following code updates the original example to use a local variable.

In C#:

int y = 0;
Func<int,string> f = x => (x + y).ToString();
y = 10;
Debug.WriteLine(f(5));

In VB:

Dim y As Integer = 0
Dim f = Function(x) (x + y).ToString()
y = 10
Debug.WriteLine(f(5))

The lambda expression in this example takes the input value, adds it to the current value of the local variable (y), and returns the result as a string.

The Debug.WriteLine statement in this example calls the lambda expression, passing in a 5. At the point of executing the Debug statement, y is 10, so the result displays "15" in the debug window.

For another example of using lambda expressions with local variables, see this post.

Enjoy!