I'm sure you've all seen the "Use: Regular expressions" option in the Visual Studio search dialog, but maybe you haven't taken advantage of it. You can use this feature to do some pretty powerful search and replace operations in Visual Studio.

I used this feature today and thought I'd share. I had a situation where I was trying to find every  control (label, textblock, button or tabitem) in the XAML of my WPF UI that did not have a localized string assigned to it. I knew that the controls that were localized looked something like the following:

    <TextBlock Text="{x:Static Member=Strings:UserStringTable.LblDescription}"... />
    <Label Content="{x:Static Member=Strings:UserStringTable.LblDescription}"... />
    <TabItem Header="{x:Static Member=Strings:UserStringTable.LblDescription}"... />

(i.e. that they all referenced a static member called Strings:UserStringTable) and those that didn't looked something like this:

    <TextBlock Text="Description:"... />
    <Label Content="Description:"... />
    <TabItem Header="Description"... />

So how can use Visual Studio to find all of those controls (TextBlock, Label, TabItem, Button, etc) with one search string and exclude the items that have already been localized? The answer is regular expressions in Visual Studio.

I know that most WPF controls have at Text, Content, Header or ToolTip attribute for assigning text that should be shown to the user. I also know that localized strings begin with ="{. Knowing that, I can put together a regular expression to find only those controls that need to be localized.

Here's the Visual Studio Search dialog I used to accomplish that search (the regular expression I used is described below--if you're already familiar with how regular expressions work and their syntax, feel free to skip past my diatribe on the breakdown of my regular expression search string):

So what am I telling the search dialog to look for in this regular expression?

( Content| Text| Header)\=\"[^{]

First let's describe the regular expression tokens we're using in this string:

So now let's break down the regular expression I used in the search above. Here's the regular expression again:

( Content| Text| Header)\=\"[^{]

Here's what it says, piece by piece:

So, if I have XAML that had the following controls in it:

    <TextBlock Text="{x:Static Member=Strings:UserStringTable.LblDescription}"... />
    <Label Content="{x:Static Member=Strings:UserStringTable.LblDescription}"... />
    <TabItem Header="{x:Static Member=Strings:UserStringTable.LblDescription}"... />
    <TextBlock Text="Description: "... />
    <Label Content="Description: "... />
    <TabItem Header="Description"... />

The only strings it should find are:

    <TextBlock Text="Description: "... />
    <Label Content="Description: "... />
    <TabItem Header="Description"... />

You can get pretty powerful with regular expressions in Visual Studio, especially when it comes to search and replace.

More information can be found on the web about how to do this. The MDSN documentation for the Visual Studio regular expression syntax can be found at http://msdn.microsoft.com/en-us/library/2k3te2cs(v=vs.80).aspx. The Visual Studio syntax is a modified version of the standard regular expression syntax that most regular expression engines use, especially when it comes to replacing text, but in most cases if you apply what you already know about regular expressions it should work. Not to worry, if you have something wrong in the syntax Visual Studio will let you know in a hurry.

For more Live-Recordings or to attend an upcoming Visual Studio User Group Meeting visit www.VSTSMN.com

In our previous TPL Dataflow posts we introduced the TPL Dataflow Library and showed you some of the capabilities of ActionBlock<T>, a dataflow block available in TPL Dataflow that allows you to buffer up messages and process those messages concurrently. We also took a slight detour and discussed how we can control the lifetime of our tasks through some of the completion mechanisms available via the IDataflowBlock interface. In this post we'll continue the main Async CTP TPL Dataflow discussion and introduce another TPL Dataflow block called TransformBlock<Tin, Tout>.

TransformBlock<Tin, Tout>, for those familiar with LINQ, is somewhat similar to Select in that it takes an input, transforms that input in some manner, and then produces an output. Like ActionBlock<T>, a TransformBlock<Tin, Tout> buffers all of its input data and processes that input data asynchronously using a function that we provide. By default TransformBlock<Tin, Tout> processes its data sequentially with a MaxDegreeOfParallelism equal to 1. This of course can be controlled using ExecutionDataflowBlockOptions.

The interesting thing to note about TransformBlock<Tin, Tout> is that in addition to receiving buffered input and processing it, TransformBlock<Tin, Tout> will take all of its processed output and buffer that as well. Are you starting to see a theme here?

Let's take a look at an example using TransformBlock<Tin, Tout> that transforms each integer into its double.

class Program

{

    static void Main(string[] args)

    {

        var transform = new TransformBlock<int, int>(i => i * 2);

        for (int i = 0; i < 10; i++) transform.Post(i);

        Console.ReadLine();

    }

Not a very interesting example, really. We provided a Func<> to TransformBlock<Tin, Tout> that returns each input multiplied by 2. As we expect the data is posted to the block and buffered for processing. TransformBlock<Tin, Tout> executes the provided Func<> and the results are then buffered for further processing by some other mechanism in our application. But how do we know that our input and output are being buffered? Let's take advantage of the debugger and find out for sure.

Using the Visual Studio Async CTP create a console app containing the following code and run it under the Visual Studio Debug configuration.

class Program

{

    static void Main(string[] args)

    {

        var transform = new TransformBlock<int, int>(i =>

            {

                Console.WriteLine(i * 2);

                return i * 2;

            });

        for (int i = 0; i < 10; i++) transform.Post(i);

        Debugger.Break();

        Thread.Sleep(1000);//Give the TransformBlock some time to process the input

        Debugger.Break();

        Console.ReadLine();

    }

Notice that the Visual Studio debugger stopped at the Debugger.Break statement. Now hover over the transform instance variable and you'll see that the current InputCount showing that immediately after posting all of the data 10 items have been buffered for processing.

Also note that the OutputCount shows zero items because we broke into the debugger just prior to processing the data.

Now continue executing in Visual Studio until the second Debugger.Break statement and hover your mouse pointer over the transform instance variable again to verify the current state of TransformBlock<Tin, Tout>. You can see that the OutputCount is now equal to 10, indicating that the processing occurred and that 10 items were processed and queued up in the output buffer.

Still not a very interesting example. How do we know that each input was actually doubled and placed into the output queue? So let's make sure that TransformBlock<Tin, Tout> did indeed process our data. Run the example again until the debugger breaks at the second Debugger.Break statement. This time hover over the transform instance variable and drill down into the instance to the OutputQueue, and notice that it indeed contains the double of each of our inputs.

There are variety of capabilities available on these TPL Dataflow blocks that further enhance your ability to process data using parallel patterns. We've only scratched the surface here with the introduction of the TPL Dataflow ActionBlock<T> and TransformBlock<Tin, Tout> along with some of their capabilities. In our next post we'll introduce additional features and capabilities of TPL Dataflow, including the ability to link different dataflow blocks together to create arbitrary dataflow networks that asynchronously propagate data through a series of processing steps to get our data into its desired form.

In our previous posts we introduced the concept of TPL Dataflow and even showed how you can take advantage of ActionBlock<T> to process incoming data in parallel. We also showed how you can control the degree of parallelism applied in a parallel dataflow through the use of the ExecutionDataflowBlockOptions MaxDegreeOfParallelism property. In this post we'll introduce the concept of task completion in a parallel dataflow.

Often times when dealing with these types of data loads in your applications you may want to post a large amount of asynchronous data for processing and then be notified when that processing has completed. We can do this easily in TPL DataFlow because each TPL Dataflow block has a lifetime, and each block type exposes mechanisms that allow us to monitor and control that lifetime such that we can wait for the tasks to complete all of their processing, or be notified when they have completed their processing. This can be accomplished via mechanisms on the Completion property exposed by ActionBlock<T>. The Completion property is a property hanging off of one of the core interfaces implemented by all TPL Dataflow blocks called IDataFlowBlock. As such, all TPL Dataflow blocks, including ActionBlock<T> expose the IDataFlowBlock.Completion property. Using the IDataflowBlock.Completion.Wait() statement we can wait for processing to complete after we've submitted all of our data.

Let's illustrate this in an example. In this example we'll use IDataflowBlock.Completion.Wait to wait for processing to complete. One interesting thing to note is that the Wait method will wait forever because it will never know that ActionBlock<T> is no longer receiving data. To circumvent this, we can tell ActionBlock<T> when we've finished posting data by issuing ActionBlock<T>'s base interface IDataflowBlock.Complete method. This will notify ActionBlock<T> that it will never be giving it more data, so once it's finished processing its queue it can shut itself down, thus notifying us that it has completed processing by releasing the Completion.Wait() call that our main thread is blocking on.

class Program

{

    static void Main(string[] args)

    {

        var action = new ActionBlock<int>(i =>

        {

            Thread.Sleep(500);

            Console.WriteLine(i);

        }, new ExecutionDataflowBlockOptions { MaxDegreeOfParallelism = 4 });

        for (int i = 0; i < 10; i++) action.Post(i);

        action.Complete();

        Console.WriteLine("Posting Complete!");

        action.Completion.Wait();

    }

}

Besides IDataflowBlock.Complete and IDataflowBlock.Completion, IDataflowBlock also provides a Fault completion mechanism as well. Say for instance we are preprocessing and validating the incoming data before we queue it to our ActionBlock<T> in the example above. If we encounter invalid data during processing we may want to issue a IDataflowBlock.Fault() telling the ActionBlock<T> that we've encountered an invalid state and that is should discontinue processing.

In our next post we will pick up where we left off in our previous post and describe additional dataflow blocks available in TPL Dataflow.

Note: If you want to try these examples out make sure to add a reference to the new System.Threading.Tasks.DataFlow library in your project. Keep in mind; by default the Visual Studio Async CTP bits will be installed in your My Documents library under Microsoft Visual Studio Async CTP, so make sure to browse to that location under the Samples folder to add a reference to the System.Threading.Tasks.DataFlow assembly.

Many of you are probably already familiar with the parallel processing capabilities offered by the Task Parallel Library (TPL) that was first introduced in the .NET Framework 4. In .NET 4 TPL provided some core building blocks and algorithms for doing parallel computing in your .NET applications. Now that the development for the next version of the .NET platform is well under way, it is no surprise that Microsoft is looking for new ways to improve upon a good thing. One such update which should make the final cut is yet another way for developers to build highly responsive code using the new Async capabilities of .NET (see Andrew Troelson's Async CTP Anyone?), currently available as a community technology preview known as the Async CTP. One component of the Async CTP is TPL Dataflow, a library for doing agent/actor based data processing using parallel techniques.

The TPL Dataflow library was first released for preview as part of the Microsoft Visual Studio Async CTP, and it is also available in a separate TPL Dataflow CTP, both of which you can download from http://msdn.microsoft.com/vstudio/async. Both the Async CTP and TPL Dataflow CTP bits can be installed and used with Visual Studio 2010 SP1.

Typically when you did parallel programming with .NET 4 you were being proactive. It was usually the case that you had some data and you wanted to perform some computation on that data. For example, you may have a range of data that you wanted to perform some computation on, or you might need to filter your data in such a way that it was useful to you in your application. To solve these problems in .NET 4 with the Task Parallel Library you might have used Parallel.For or Parallel.Foreach, or possibly even a PLINQ query to iterate through the data and take advantage of the parallel constructs provided to you by TPL. In all these cases is was typically data first, then computations on that data later using primitives for tasks and data parallelism provided to you by the Task Parallel Library. What was missing was the ability to be reactive. Essentially the ability to setup your computation framework first, and then react to the data as it is coming in.

This reactive method of processing data is commonly referred to as dataflow parallelism. Essentially what you're doing is creating computational networks through which data can flow. Agent-based and actor-based message passing patterns like the producer/consumer pattern follow this reactive model. With the introduction of TPL Dataflow you will be able to use the parallel programming paradigms in your own .NET applications to build reactive dataflow networks. This is not to say that you couldn't have solved these problems in .NET 4 using Task Parallel Library, however it would have involved quite a bit of code to manage buffering data, scheduling tasks and dealing with the inter-process communications required to perform the work. The TPL Dataflow library gives you a lot of the primitives that you need to solve these problems out of the box without having to worry about the minutia required to implement such architectures.

So what is TPL Dataflow? Essentially it is a parallel processing library that exposes primitives for doing in-process messaging passing and processing. TPL Dataflow provides a set of agents, commonly referred to as dataflow blocks, or simply blocks, that contain the infrastructure required to buffer and process your data in an asynchronous and parallel manner. TPL Dataflow provides the infrastructure for being able to build data parallelism into your applications.

At the core of the TPL Dataflow library is its interface hierarchy, pictured below. These interfaces describe the behavior of a dataflow block. At the very top of the hierarchy is IDataflowBlock, defining contract for dealing with the lifetime of a dataflow block. Below IDataflowBlock are three sub-interfaces that define contracts for blocks that can be a source of data, blocks that can be a target for data, and blocks that can be both a source and target for data. ISourceBlock represents a source of data, defining a contract for buffering and receiving data. ITargetBlock represents a target for incoming data, defining a contract for buffering and passing data. Finally IPropagatorBlock represents a block that can be both a source and a target for data, defining a contract for receiving data from sources, possibly transforming that data and propagating the result on to other targets.

With these interfaces you can develop your own blocks to build your own custom dataflow networks, but there are also several built in blocks for the most common scenarios like buffering and propagation of data, acting on data, and even blocks for joining data from multiple sources then buffering and presenting the result to a target.

For buffering and propagation of data TPL Dataflow provides the following blocks:

BufferBlock<T> - buffers incoming data and delivers that data to a target in an asynchronous and parallel fashion.

WriteOnceBlock<T> - accepts one piece of data and delivers that piece of data in a broadcast fashion to all target blocks interested in that piece of data.

BroadcastBlock<T> - accepts multiple pieces of data, buffering them as they arrive and broadcasts each piece of data to all interested target blocks.

For acting on incoming data TPL Dataflow provides the following dataflow blocks:

ActionBlock<Tin> - an ISourceBlock that accepts and buffers incoming data and performs some action on that data.

TransformBlock<Tin, Tout> - an IPropagatorBlock that accepts and buffers incoming data, executes some function on that data and then buffers the output to be consumed by a target.

TransformManyBlock<Tin, Tout> - very similar to TransformBlock, however the relationship to its targets is one-to-many. It buffers and transforms incoming data, then buffers and makes that data available to multiple targets.

For joining and grouping data TPL Dataflow provides the following dataflow blocks:

BatchBlock<T> - An IPropagatorBlock that accepts and buffers incoming data and groups that data into batches (arrays).

JoinBlock<T1, T2> - Accepts and buffers data from two different source blocks, combines data from each source into tuples, then buffers and makes those tuples available to a target.

BatchedJoinBlock<T1, T2> - a combination of BatchBlock and JoinBlock that groups pairs of collections of incoming data into tuples of those collections, buffering and presenting that data as output to a target.

As you can see TPL Dataflow provides you with some significant capabilities for developing parallel dataflow capabilities into your own applications without having to reinvent the infrastructure to do so. This was a quick look at the TPL Dataflow and the interface hierarchy upon which it is build, as well as some of the built in capabilities for building applications that incorporate data parallelism. Watch for future posts where we'll look at some of these built in mechanisms along with examples demonstrating how you can get started using TPL Dataflow.

If you are interested in looking at the current state of this new technology, here are some helpful links: 

• Whitepaper: Asynchrony in .NET
• Async CTP (preview bits and sample code)

Visual Studio has supported visual class designers for quite some time.  As useful as these features are, the one problem is that the diagram produced is *not* UML proper, but a ?UML-like? notation.

Awhile back, Microsoft released a Visual Studio Feature Pack for MSDN subscribers which allows you to generate proper UML diagrams (of various flavors). You can download this feature pack by clicking on the ?Visual Studio 2010 Feature Pack 2? link at this web site.

Once you have installed the feature pack, you will be able to:

• Use the Generate Code command to generate skeleton code from elements on UML class diagrams. You can use the default transformations, or you can write custom transformations to translate UML types into code.
• Create UML class diagrams from existing code.
• Explore the organization and relationships in C, C++, and ASP.NET projects by generating dependency graphs.
• Import elements from UML sequence diagrams, class diagrams, and use case diagrams as XMI 2.1 files that are exported from other modeling tools.
• Create links and view links from work items to model elements.
• Create layer diagrams from C or C++ code and validate dependencies.
• Write code to modify layer diagrams and to validate code against layer diagrams.

Just to give a taste, assume you have a current C# project, and which to generate some UML class diagrams. First, from the Architecture menu option, select New Diagram.  From here, you can pick from any of the following:

Assuming you select a new UML Class Diagram, you can open the Architecture Explorer window, and drag types onto the created visual designer:

The resulting UML is then generated by the tool:

Another great feature of this feature pack is the ability to generate dependency graphs of your code. For example, if you were to select the Architecture | Generate Dependency Graph menu option, you will find a diagram such as the following:

There is much more you can do with this feature pack, and if you have an MSDN subscription ID, I?d say it is certainly worth a download!

Happy coding.

This is a live recording of the Coded UI Testing presentation given on 9.21.11. Find more information about the presentation and other upcoming presentations at www.vstsmn.net

Intro

This is part 8 in a series of posts on creating and maintaining Coded UI tests with Multiple UI maps. My intent here is to give a little more detail to help those new to Visual Studio.

Part 1: Creating a new Coded UI solution

Part 2: Adding a New UI Map

Part 3: Modifying an Existing Coded UI Map

Part 4: Adding a UI Map to the TestRunUtility

Part 5: Assembling the test

Part 6: Changing Recorded Methods

Part 7: Deleting actions when recording with the Coded UI Test Builder

Part 8: Modifying Generated Code

Credits

This technique is an extension of the technique found in the following links by Anu , a Program Manager in the Visual Studio ALM Test Tools group and the MDSN documentation. http://blogs.msdn.com/b/anutthara/archive/2010/02/08/scaling-up-your-cuit-ui-automation-for-real-world-projects.aspx

http://blogs.msdn.com/b/anutthara/archive/2010/02/10/walkthrough-using-multiple-coded-ui-maps-in-test-automation.aspx

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

Modifying Generated Code

I mentioned that we should not edit code found in the <Page>Map.Designer.cs file. What should we do if we want to customize our code (we will make our AssertQuantity more robust)? Double click on the uitest file that contains the code you want to modify. In the UI map editor highlight the method you want to change -> click the Move Code button -> click the save all button or ctrl + shift + S.

Now double click the ShoppingCartPageMap.cs and notice we have code. We can safely edit the code now without fear that the code generator will overwrite our changes.

Here is the AssertQuantity method before our changes:

public void AssertQuantity()
        {
            #region Variable Declarations
            HtmlEdit uIQuantityEdit = this.UIHomeTailspinToysWindWindow.UIHomeTailspinToysDocument.UIQuantityEdit;
            #endregion

            // Verify that 'Quantity' text box's property 'Text' equals '1'
            Assert.AreEqual(this.AssertQuantityExpectedValues.UIQuantityEditText, uIQuantityEdit.Text);
        }

We are going to modify the method signature and the highlighted expected value to accept a parameter rather than the constant 1 (so that we can validate quantities other than 1).

The altered code looks like this:

        public void AssertQuantity(string expectedValue)
        {
            #region Variable Declarations
            HtmlEdit uIQuantityEdit = this.UIHomeTailspinToysWindWindow.UIHomeTailspinToysDocument.UIQuantityEdit;
            #endregion

            Assert.AreEqual(expectedValue, uIQuantityEdit.Text);
        }

Once we make this change, our test case will no longer run because our call to AssertQuantity does not pass in a parameter.

To fix that we need to pass in the value we expect in the Quantity text box, a ?1?.

The altered code will look like this:

[TestMethod]
        public void AddOneCoffeFlyerToCartTest()
        {
            TestRunUtility trUtility = new TestRunUtility();
            try
            {
                trUtility.HomePage.NavigateToTailspinToysSite();
                //On the home page click the Model Airplanes button
                trUtility.HomePage.NavigateToModelAirplanes();
                //From model airplane page, click the view fourth coffee flyer button
                trUtility.ModelAirplanePage.ViewFourthCoffeeFlyer();
                //From the fourth coffee Flyer details page, click add to cart
                trUtility.FourthCopyFlyerDetailsPage.AddFourthCoffeeFlyerToCart();
                //We should be at the shopping cart now
                //Validate the quantity
                trUtility.ShoppingCartPage.AssertQuantity("1");
                //Clean out the cart
                trUtility.ShoppingCartPage.RemoveItemFromCart();

            }
            finally
            {
                //close the browser
                trUtility.HomePage.CloseBrowser();
            }
        }

For fun, change the ?1? to a ?2? . Now when you run the test (not debug), we should see the test fail and we should still see the browser close which is the behavior we want.

Intro

This is part 7 in a series of posts on creating and maintaining Coded UI tests with Multiple UI maps. My intent here is to give a little more detail to help those new to Visual Studio.

Part 1: Creating a new Coded UI solution

Part 2: Adding a New UI Map

Part 3: Modifying an Existing Coded UI Map

Part 4: Adding a UI Map to the TestRunUtility

Part 5: Assembling the test

Part 6: Changing Recorded Methods

Part 7: Deleting actions when recording with the Coded UI Test Builder

Part 8: Modifying Generated Code

Credits

This technique is an extension of the technique found in the following links by Anu , a Program Manager in the Visual Studio ALM Test Tools group and the MDSN documentation. http://blogs.msdn.com/b/anutthara/archive/2010/02/08/scaling-up-your-cuit-ui-automation-for-real-world-projects.aspx

http://blogs.msdn.com/b/anutthara/archive/2010/02/10/walkthrough-using-multiple-coded-ui-maps-in-test-automation.aspx

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

If during the course of recording your actions in the Coded UI test builder you interact with something you don?t want recorded (like you send an instant message or an email) you can delete those actions from the recording by clicking on the Show Recorded Steps button

A list will display of all actions that have been recorded since you last generated code:

You may delete items from this list by highlighting the item or items you want removed, right clicking and selecting Delete.

This is part 6 in a series of posts on creating and maintaining Coded UI tests with Multiple UI maps. My intent here is to give a little more detail to help those new to Visual Studio.

Part 1: Creating a new Coded UI solution

Part 2: Adding a New UI Map

Part 3: Modifying an Existing Coded UI Map

Part 4: Adding a UI Map to the TestRunUtility

Part 5: Assembling the test

Part 6: Changing Recorded Methods

Part 7: Deleting actions when recording with the Coded UI Test Builder

Part 8: Modifying Generated Code

Credits

This technique is an extension of the technique found in the following links by Anu , a Program Manager in the Visual Studio ALM Test Tools group and the MDSN documentation. http://blogs.msdn.com/b/anutthara/archive/2010/02/08/scaling-up-your-cuit-ui-automation-for-real-world-projects.aspx

http://blogs.msdn.com/b/anutthara/archive/2010/02/10/walkthrough-using-multiple-coded-ui-maps-in-test-automation.aspx

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

Editing/Changing Recorded Method Names

If you are unhappy with the name of your asserts or methods, you can double click the <page>Map.uitest file to open the UI Map editor -> highlight the method you want to change and press the F2 key or click the rename toolbar button

Changing the actions in a Recorded Method

If you have recorded something that needs to change, because the application changed or you recorded some action that shouldn?t be in the test, you may rerecord the actions and replace the old method.

First open the browser and navigate to the page you want to modify.

Right click on the <page>Map.uitest file and select Edit with Coded UI Test Builder

Record your actions but this time we want to reuse the existing method. Click the drop down arrow and select your method

Notice the button becomes ?Replace and Generate?.