Archive for the ‘Uncategorized’ Category

Howdy folks,

Here we are back again with an introduction of the new features of the upcoming Visual Studio 2010. Its release has been postponed to the 12th of April, so in the meantime we’ll have to stick to the Beta 2, which is pretty stable already. There are so many improvements that we’ll have to divide it into multiple parts. Let’s dive right in!

1. UI: WPF-Based

The UI is now WPF based, which means a better usability and more extensibility options for us developers. Clearly, introducing VS2010 as a WPF-based application is a big push in the direction of visualization and diagramming. We’ll see later how this can be performed using the new IDE.

The editor, for example, is now WPF-based. Cool, but what does that mean for us? Here are the advantages:

Change font size w/ mouse only, or better: No more Options->Change font size during presentations!

Extension Manager allows easy-to-install-and-use add-ins: Also from online galleries – Single click install and enabling!

Highlighting of related variable/method names (Figure 1)


Figure 1: Highlighting related variable. Note that the highlighter correctly references only the name variable passed as a parameter

You can navigate between the highlighted elements using CTRL + SHIFT and the ARROW keys!

2. Intellisense – Improvements:

Method Matching: When VS2010 brings up the list of available methods (after you typed something), it performs not a simple .StartsWith name comparison, but a .Contains. This leads to the results shown on the next screenshots:

Filtered list is gone: When typing letters, the auto completion list that pops up won’t give you all objects/methods/variables that start with the same letter, but only those who are truly related. Consider Figure 3: We typed IF. In the old version, VS would have brought up not only the items shown in the completion list, but possibly many many more, all starting with I (but not containing or continuing with F). Now the IntelliSense search is narrowed, which makes it a lot easier for the developer to select the correct entry.


Figure 2: Highlighting the related object/variable/method.

Case sensitivity: Another nice feature highlighted in figure 2 is the Pascal-Case typing of the capital letters IF, which brings correctly up our method, since its signature contains both I and F as of the method name. Try typing If (f is lowercase), and you won’t find the IsFasterThan method in the auto completion list anymore.

3. References dialog improvements

Remember the Add References dialog in figure 3?


Figure 3: Add references underwent some perception changes.

First of all, Microsoft realized that most people are using it to reference other projects, so they brought up the Projects tab by default. But that’s not all: We all LOVED to wait 30 seconds for the list of .NET or COM objects to appear, right? Because of that, while we are browsing by default the projects, VS2010 is asynchronously loading the available assemblies already. Saves time and nerves.

4. Search and Navigation

Let’s press CTRL + , anywhere in the editor. The window Navigate To will appear, providing us a very powerful search across the entire solution. The search results are updated as we type. From here, we can navigate directly to the found item. Figure 4 shows the dialog.


Figure 4: The Navigate To dialog is a powerful search and navigation mechanism, providing also essential information about the found items. Big improvement over the VS2008 style’s CTRL+SHIFT+F (and subsequent find results crawling without navigation to the desired item)!

5. Call Hierarchy

Remember the Find All References option in the editor’s context menu? It provided us information about where a method/variable has been used. Tell you what. We have a much more powerful way of doing this now: The Call Hierarchy option (Figure 5).


Figure 5: Context menu for the IsFasterThan method, highlighting the new View Call Hierarchy option.

This is the result: A list of all callers (“Calls To”) and callees (“Calls From”) of IsFasterThan (Figure 6). Every caller/callee can be expanded into its own callers/callees. As of figure 6, e.g. Main. This is a really expressive feature which outperforms Find All References by far. However, a possible drawback might be that you could expand the list to infinity by alternating the caller/callee relationship. Figure 6 shows the resulting


Figure 6: The View Call Hierarchy window, showing callers/callees of IsFasterThan.

6. Project dialog with search and .NET version selection

Figure 7 shows the improved New Project dialog.


Figure 7: The NewProject dialog. Please note the search field in the right upper corner and the .NET framework dropdown list (center), where now also version 4 of the .NET framework is available.

7. Code Snippets

The code snippets are accessible via the Tools menu, or by pressing the shortcut CTRL + K, CTRL + B

Additional snippets are now available also for HTML, JavaScript and SQL. In sub-categories you can find the different snippets already provided by VS2010. Moreover, you can add your own snippets (as we already know from previous VS versions), as well as remove and import snippets. Figure 8 shows the Code Snippets dialog.


Figure 8: The Code Snippets dialog, showing the newly available languages, as well as subcategories in the Code Snippets Manager.

8. Environment settings: Code Optimized

One more newly available feature is a new default environment setting (remember you had to choose which default settings you wanted to use when starting VS2010 for the first time?). There is one newly available feature which will simply allow you to reduce your viewport to only the code when developing (hence removing the designer). If you have already chosen your first-time-startup environment settings: Don’t worry! The next screenshot explain how you can access the new Web Development (Code Optimized) default environment setting. First, choose Tools –> Import and Export Settings.


Figure 9: Import and Export Settings wizard. Choose Reset all settings here. Then you will be prompted whether or not you want to save your current settings. Choose as you wish there. Then proceed.


Figure 10: Default environment settings. Note the Web Development (Code Optimized) option, which is new to VS2010. Choose it and VS will immediately switch to those settings, removing e.g. the designer buttons and providing you with a much more lightweight code editor window. Very handy for developers who want to only focus on the code.

9. Conclusion

So I’d say this is about it for this time. Of course there are a lot more features which need to be covered.

The next lessons will deal with creating customized startup pages for VS2010, and introduce the new language features and tools of Visual Studio 2010.

In the meantime, enjoy exploring VS’ new capabilities and features, and hang on till the next time!

Best regards,



Read Full Post »

Howdy ladies and gents out there,

Here we go with another NHibernate common problem solved for you. Recently the question arose whether it is possible or not to execute a query with NHibernate that checks whether a property lies in a given range of values or not. Not much of a problem, we would say, since HQL can do it just directly using its SQL-like syntax. For example, if we recall our example DevJour1 from part 1 of the NHibernate noob series, we could define a query in the Book.hbm.xml file:

   1: <query name="GetAllBooksWithinRange">

   2:   <![CDATA[

   3:     select b from Book b where b.Title in ('It', 'Salem's Lot',                                                  'Langoliers');

   4:   ]]>

   5: </query>

Snippet 1: Excerpt from the Book.hbm.xml file: HQL query returning all books whose title lies within a certain range of values.

Problem solved? Not quite. Another requirement to this query was to provide custom sorting w/ a custom field and a custom sort direction. Sounds familiar, doesn’t it? Remember our first NHibernate troubles post: Custom Sorting. Simply put, using HQL, this is not possible. So we had to use Criteria queries. But how do we implement the range value check for a given property using Criteria queries? It’s simple, really:

   1: public static List<Book> GetAllBooksWithinRange()

   2: {

   3:     String[] titles = { "It", "Salem's Lot", "Langoliers" };

   4:     ISession session = Program.OpenSession();

   5:     List<Book> books = session.CreateCriteria(typeof(Book)).

   6:         Add(Restrictions.In("Title", titles)).

   7:         List<Book>().ToList<Book>();

   8:     return books;

   9: }

Snippet 2: Excerpt from the Book class.

BookGetAllBooksWithinRange()explained (line by line):

3: Definition of our range of values

4: Opening a session, recall from Program class of the Custom Sorting article.

5: Creating criteria for type Book .

6: Crucial part: Adding Restrictions.In (NHibernate.Criterion), passing the property that needs to be checked (Title) and the list of range values.

7-8: Calling the List() method(s) and returning the retrieved list

Important: This works also, when comparing a property of a property with a range of values. Example: Assuming, Book contains a class Author , which in turn contains a property Surname. Then we could formulate such a comparison statement like follows:

.Add(Restrictions.In(“Author.Surname”, names)).

Under the assumption that names is an array containing strings.

That’s it! I’m sure there are more problems to be solved!

See you later!

Best regards,


Read Full Post »

Hello all,

This time we’ll do a quick exploration of how we can apply Code Contracts to interfaces. As you know from our post First Steps with Code Contracts, the preconditions and postconditions (Contract.Requires and Contract.Ensures calls, respectively) must be placed inside a method body.

Therefore, when defining an interface, we run into a problem: We do not have method bodies there. Of course we could put such calls inside each effective implementation of the interface methods. Clearly, this is not what we want, since

  • We do not want to replicate code in x classes that implement our interface and
  • Future implementations of our interface would contain the conditions we need

Luckily, the Code Contracts provide us with a powerful mechanism that allows us to define a class which implements that interface and which will do the necessary checks.

The Contract Class

Let’s see how this is done, right? For this example, please recall our example from the First Steps with Code Contracts introductory article.


   1: namespace Vehicles

   2: {

   3:     interface IVehicle

   4:     {

   5:         void Drive(Int32 speed);        

   6:     }

   7: }

Snippet 1: The IVehicle interface

Also do recall that we did not define any pre- or postconditions for our interface (how could we? – there is no method body).

This is exactly the place, where we will put a so called Contract Class, that will implement our interface. Every time the interface is called, the conditions put into our Contract Class will be injected. This holds for every implementation of our interface.

We basically need two things:

1. A class that implements our interface IVehicle that is marked as Contract Class via an attribute:


   1: [ContractClassFor(typeof(IVehicle))]

   2: public class IVehicleContract : IVehicle

   3: {

   4: }

Snippet 2: Contract Class implementing the interface we want to fulfil requirements

2. Another class that links up our interface to the ContractClass

   1: [ContractClass(typeof(IVehicleContract))]

   2: public partial interface IVehicle

   3: {

   4: }

Snippet 3: The link between the interface and our Contract Class

Hint: Don’t worry: You do not have to implement these two classes from scratch: The Code Contracts come with a bunch of predefined snippets that can be executed right away. The following snippet will do the trick for generating the Contract Classes for an interface:


cintf ->(TAB – TAB)

The next step is to implement the interface for IVehicleContract.


Figure 1: Explicitly implementing the interface IVehicle for the IVehicleContract class.

The result is shown in Snippet 4:

   1: [ContractClassFor(typeof(IVehicle))]

   2: public class IVehicleContract : IVehicle

   3: {

   4:     void IVehicle.Drive(int speed)

   5:     {

   6:         throw new NotImplementedException();

   7:     }

   8: }

As a next step, we can implement our conditions in the method body of IVehicle.Drive method in IVehicleContract, like shown in Snippet 5:

   1: [ContractClassFor(typeof(IVehicle))]

   2: public class IVehicleContract : IVehicle

   3: {

   4:     void IVehicle.Drive(int speed)

   5:     {

   6:         Contract.Requires(speed >= 0);

   7:     }

   8: }

Snippet 5: precondition in interface method implementation.

What does this mean now? Well, for every implementation of the interface IVehicle , the code precondition will be injected. In other words:


The condition we define in the Contract Class must hold for all implementations of the interface.


That was it already (for this time)! It is as simple to use as it seems.


Enjoy and stay tuned for the next time!

Best regards,


Read Full Post »


You might already guess it: Pex won’t let me go, and so I’d like to explain in short a few of Pex’ concepts.

1.1 Code Coverage

Pex is an abbreviation for Program Exploration. You guessed it: Nomen est omen. It analyzes the branches (if, then, else, etc…) of control flow and tries to cover each and every branch. This leads to a highly elevated code coverage, or, in other words: It helps to increase the amount of tested code.

1.2 The Main Idea of Parametrized Unit Testing using Pex

…is to elevate any values that should not matter (i.e. that should not influence the program’s runtime behaviour) into parameters. Pex will then care about how to deal with them, about creating test cases for all possible values they can assume. Short & sweet: Pex cares about your parameters and helps to ensure there are no cases where your program would fail because of them.

1.3 The Nuts and Bolts of a PUT

Figure 1 gives you an example of what a Parametrized Unit Test (PUT) looks like:


Figure 1: A simple PUT

We just use the [PexMethod] attribute to denote that the following method is a PUT.

Sometimes we need some of the parameters to be null, in order to get a method running at all. In such a case, we can give Pex the instruction not to generate tests which would assume that parameter as NULL. We simply do this by adding the attribute


in front of the parameter type. Sounds straightforward, doesn’t it?

Within the PUT method, you can (as suggested by Pex upon generationg of the tests) multiple assertions to ensure the correct behaviour of the method. What Pex does for you, is the following:

  • Detecting dereferencing of potential null values (and generates a test case)
  • Analysis of e.g. loop boundaries (and generates test cases for each assumable value, including boundary values)

There is only one drawback: This way of testing only works as long as we have implemented method bodies. Are there cases where we don’t have them? Of course: Interfaces. Let’s see how Pex deals with interfaces.

1.4 Extending our Example

In order to see how Pex generates test code for interfaces, we need to add an interface to our project BookStore (which we created in Pex – Automated White Box Unit Testing).

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;


   6: namespace BookStore

   7: {

   8:     public interface IStorage

   9:     {

  10:         void DeliverToAddress(String address, Book book);

  11:     }

  12: }

Snippet 1: The IStorage interface.

As a next step, we are going to use it somewhere, namely: We let our class Store implement IStorage.

public class Store : IStorage

Please note that the IStorage member method DeliverToAddress(…) has already been implemented in our previous post. Hence, the code should compile as soon as you implemented the changes.

What comes next? Pex cannot possibly know about our newly created interface, so we need to tell it somehow to generate stubs for the interface. And how do we do that?

Re-run Pex!

For that, right-click on the project BookStore and select Run Pex from the context menu. Pex generated the following class:

   1: public partial class SIStorage : IStorage

   2: {

   3:     Action<string, global::BookStore.Book> DeliverToAddressStringBook;

   4:     void DeliverToAddress(string address, Book book)

   5:     {

   6:         return DeliverToAddressStringBook(address, book);

   7:     }

   8: }

Snippet 2: The generated stub class for the IStorage interface: SIStorage.

As shown in Snippet 2, the generator creates a class named S + <interface name>, which implements the interface. For each method defined in the interface, a property (a delegate, in fact)will be added which resembles the method’s signature (method name + parameters’ types, camel case).

1.5 Customizing the stub

Now we’ll dig a little deeper. We modify our DeliverToAddress method from Snippet 1. Why do we do this? We simply double-check that the amount of ordered books is equal to the amount of the actually delivered book.

   1: // <copyright file="StoreTest.cs" company="Scientific Network">Copyright © Scientific Network 2010</copyright>


   3: using System;

   4: using BookStore;

   5: using Microsoft.Pex.Framework;

   6: using Microsoft.Pex.Framework.Validation;

   7: using Microsoft.VisualStudio.TestTools.UnitTesting;

   8: using BookStore.Stubs;

   9: using System.Collections.Generic;


  11: namespace BookStore

  12: {

  13:     [TestClass]

  14:     [PexClass(typeof(Store))]

  15:     [PexAllowedExceptionFromTypeUnderTest(typeof(ArgumentException),

  16:                                     AcceptExceptionSubtypes = true)]

  17:     [PexAllowedExceptionFromTypeUnderTest(

  18:             typeof(InvalidOperationException)

  19:     )]

  20:     public partial class StoreTest

  21:     {

  22:         [PexMethod]

  23:         public void DeliverOrders([PexAssumeUnderTest]Store target)

  24:         {

  25:             int count = 0;

  26:             var storage = new SIStorage()

  27:             {

  28:                 DeliverToAddressStringBook =

  29:                 delegate(String address, Book book)

  30:                 {

  31:                     count++;

  32:                 }

  33:             };

  34:             target.DeliverOrders();

  35:             Assert.AreEqual(CalculateExpectedDeliveries(target.Orders), count);

  36:             // TODO: add assertions to method StoreTest.DeliverOrders(Store)

  37:         }


  39:         private int CalculateExpectedDeliveries(List<Order> orders)

  40:         {

  41:             int deliveries = 0;

  42:             foreach (Order order in orders)

  43:             {

  44:                 deliveries += order.Quantity;

  45:             }

  46:             return deliveries;

  47:         }

  48:     }

  49: }

Snippet 3: The modified stub.

StoreTest explanantion, (line by line)

Don’t worry! It looks more complicated than it actually is. The real stuff starts only on line 25.

25: Declaring a counter variable which will serve our comparison

26-33: Declaring an anonymous method that will simply increase a counter each time DeliverToAddressStringBook is called.

34: Perform the actuall delivery, calling DeliverOrders, which itself will call DeliverToAddress.

35: Using an assertion in order to determine whether our expected amount of delilveries (CalculateExpectedDeliveries) equals the actual amount of delivered books (count).

39-47: The method CalculateExpectedDeliveries is only used to retrieve the correct amount of books that is expected to be delivered by the DeliverOrders method.

In order to let the tests run, simply right-click on the DeliverOrders method and choose Run Pex Explorations, as shown in Figure 2.


Figure 2: Run Pex on the PUT.

At this point, you will perhaps notice failing tests where the order.Quantity is equal to a negative number.

I’d like to show you a simple means to prevent Pex from generating and running test cases under certain circumstances: Code Contracts.

For this post, I just show you what you need for that purpose. We’ll probably cover Code Contracts in a future post, since they integrate very well with Pex (and vice versa).

Just drop a statement like

Contract.Assume(target.Orders.Count >= 0);

at the beginning of the DeliverOrders method. For Pex, this simply means to ignore all cases where the store would get a negative amount of orders – hence preventing Pex from generating nonsense test cases.

1.6 Why all this Work?

The advantage of all this customization should be clear: You can test an interface in general, without having to test all single methods that implement the interface.

I hope you are familiar now with (customizable) PUTs and interface tests.

Cheers, and see you at the next post!


Read Full Post »

« Newer Posts