Recently I purchased a Sony VAIO laptop and after having it for nearly two months, I have to say, it’s by far the best laptop I’ve owned to date (previous ones included the older VAIO Z series, HP, Toshiba, Fujitsu, LG). I purchased mine online (www.sony.es) and you can customize it to your exact needs. Prices start at 1.500 Euros up to 5.000 Euros (512GB SSD + Blu-Ray recorder, etc.). I went for the modest option of the lower end processor and regular SATA HDD (7400 rpm).

Screen

The screen is extremely bright and of amazing quality. It’s 13.1 inches with a resolution of 1600 x 900. There’s an option for 1920 x 900 although it adds around 150 Euros to the price. I’ve got the former and it’s more than enough space. It’s also small enough to work comfortably on the plane.  It also comes with a Hybrid Graphic System, controlled by an external button, allowing you to switch from external to internal graphics to save on battery life.

Speed

Overall I get very good performance out of if. I purchased the lower end CPU, which is the i5 2.40 Ghz and despite that, I’m very pleased. I do quite a bit of video rendering, recording, etc and it behaves! I did however go for 8GB of RAM (which only cost 80 Euros more, over the default 4GB). I'm running Windows 7 Ultimate 64bit.

Touchpad

Nothing out of the ordinary. The mouse keys a little on the tough side. The fingerprint reader is located between both buttons and on the whole works well, although I’m glad that you can still type in a password in those rare cases it doesn’t like your fingers.

Keyboard

The touch and layout of the keyboard is amazing. The spacing between keys is more than sufficient for comfortable typing despite the overall small size of the laptop. The cursor keys are conveniently located and the corresponding PgUp, PgDwn are function keys on the cursors, making navigation very smooth. Insert and Delete keys are also positioned in an adequate location (looking at you Toshiba!). I also went with the optional backlight which allows me to work nicely in darker environments (uses sensor to detect light). As with many laptops, it comes with a couple of VAIO specific buttons (Support, Care, etc. which I hardly use).

Battery life

I went with the extended battery which supposedly gives me around 10 hours of battery life in Stamina mode (there are three modes: Automatic, Speed and Stamina, controlled by an external button). Have I ever managed to get 10 hours of battery life out of it? Keep on dreaming. I’ve got about 5-6 hours on Auto mode which to be honest is not bad at all. Initially I was concerned about the extra battery since the web site does indicate that it sticks out. Now if you’ve seen the Lenovo’s you know that usually means a bad case of hemorrhoids. However, Sony have been clever here in that they’ve designed the battery to act as a leaver. Instead of sticking out from the back, it sticks out from underneath. This provides two benefits: it raises the laptop a bit, which usually people like their keyboards raised, and by lifting the laptop from the table, it provides more room for air circulation, keeping it running cooler in general.

Weight and Size

Extremely light. Specs indicate 1.4Kg. The extra battery adds a bit more weight to it, but overall, very light. And in all in all quite compact. As I mentioned previously, can work perfectly in a plane with it.

Heat

One of my main concerns with laptops is heat. Unfortunately the heat normally is dissipated where you rest the palms of your hands (left and right of the touchpad) or on the keyboard. In this case, the area around the touchpad is completely cool. You can detect a bit of heat on the left side of they keyboard (near the QWERTY keys) when working with it extensively. However, nothing out of the ordinary (looking at you Fujitsu and HP).

External inputs and other features

Other features it includes which come in very handy:

• SD Card Reader
• Sony MS and HG Duo
• Built-in Motion Eye Camera
• Built-in Microphone/Speaker and external jacks in front of the keyboard
• External button for switching off WiFi/Bluetooth
• VGA and HMDI output
• 3 USB ports (you can pick 2 + 1 iLink)
• Network port
• Optionally WAN (I didn’t go for that option)

Case and Design

The outer case comes in various colors and material. I went for the black Carbon and it looks quite nice. They have platinum, etc. As for the overall design, sorry Apple fan boys, new kid in town.

Support

I purchased the laptop with the default OS because like many, I prefer to clean it down and re-install. Being a newer model, I was “pleasantly” surprised to find that none of the drivers for my exact model where available on the site. I called Sony support expecting to be brushed off and instead I received extremely good support. They were very attentive to my issue and every email I sent was replied to in under 24 hours. Fortunately I found drivers from similar models and got it all configured and apparently my drivers should now be available on the web (although I’ve not checked yet). All in all though, very happy with the service I’ve received so far. Extremely helpful and pleasant to deal with.

Summary

To be honest there are very few things I don’t like about the laptop. I didn’t appreciate much the fact that they’d sold me something without the drivers being ready for download, but I worked around that as I mentioned. About the only thing I don’t like are the speakers. The volume is not very high. Even at full-blast it’s something like 40% of my previous LG laptop. The headphones have the same levels. Plugging in external amp solves it though. Other than the speaker level though, there’s not much more I could say negatively about the laptop.

As I said earlier, out of all the laptops I’ve owned (I’ve been working exclusively on laptops for the past 10 years more or less), this is by far my best purchase. It’s extremly lightweight, powerful and feature rich. Considering the price I paid for it, it’s well worth the investment. I highly recommend it.

As of the beta* of dotCover, we included a Console runner to run coverage using the command line, allowing for instance, setup of dotCover in a Continuous Integration environment. Let’s see how it works.

*To get all these features in this post, you need to download the latest nightly build

Console Runner

The Console runner is located under the installation folder (%Program Files%\JetBrains\dotCover\v1.0\bin\dotCover.exe). The best option is to add it to the system path so as to be able to run it from anywhere. The runner accepts several commands based on the operation we want to perform. Each of these commands in turn takes one parameter, which is an XML configuration file. The commands are:

• cover: Coverage of specified application
• merge: Merges snapshots
• report: Creates an XML report of the coverage results
• list: Lists snapshots
• delete: Deletes snapshots
• analyse: Provides an all-in-one analysis and output

We can also obtain a list of commands by typing dotCover.exe help on the command line:

As shown in the figure above, we can find out more about each command by typing help followed by the command. All commands (including help) have corresponding shortcuts. For instance, to get information about analyse, we can type:

dotCover.exe help analyse

or

dotCover.exe h a

Since all commands take as parameter an XML file, when requesting help, all they do is generate a sample XML with comments indicating what each element means. The previous command would therefore output:

The obvious advantage to this is that we can easily get a new configuration file setup by just asking for help and piping the output to some file. In fact, adding a third filename parameter, dotCover will do this for us, without us having to touch up the output (remove headers, etc.).

Coverage in one command

The dotCover console runner is flexible in that it complies with most common requirements in a Continuous Integration setup. Normally in projects, we have multiple test projects we need to cover. We might then want to see the results separately or merge them as one report. dotCover allows for this kind of flexibility. However, in many cases, all we want to do is run coverage on a single test project and see the results. We’ll see how to do that in a single step in this blog post and in a future post we’ll get into the details or merging, listing, etc.

Let’s see how to do this step by step. I’ll be using a sample app that I’ve prepared for this blog post (using MSpec). You can adjust the parameters to your own project paths and unit testing framework as required.

1. Type dotcover help analyse coverage.xml on the command line. I’m doing this in the root folder of my solution.
   
   
   
2. Add coverage.xml to the Solution and open it up in Visual Studio
3. Eliminate all elements except the following
   
    
   
4. Fill in the elements with the corresponding values:
   
   Executable: Is the path to the unit testing framework runner (in this case mspec.exe)
   Arguments: Arguments passed to the runner, the test assemblies (specs.dll)
   WorkingDir: Optional path to the working folder (provide this to not have to fully qualify test assemblies)
   Output: XML Report containing coverage information. Relative to the coverage.xml path (output.xml)
   
    
   
5. That’s it in terms of configuration. Now all we need to do is run it by typing dotCover analyse coverage.xml. If all is configured correctly, we should see the following output:
   
   
   
   and there should be an output.xml file located in the same folder. Opening it up we can see the coverage results
   
   

Filtering from the Console

Looking at the results, we can see that there is a lot of noise, that is, assemblies that we’re not interested in such as the tests, MSpec assemblies, etc. In a previous blog post, we saw how to filter these out using dotCover GUI. Let’s see how we can do this via the command line. If we generate the default coverage configuration, we can see that there is a filter section:

These are used to filter assemblies. We can indicate which assemblies we want covered and which we don’t. In order to filter out all assemblies and concentrate only on our actual code (ClassLib), we can do one of two things:

1. Filter out all non-required assemblies individually by adding them to the ExcludeFilters section, as in:
   
    
   
2. Exclude everything that’s not specifically in the Include section. This is done by leaving an ExcludeFilter section blank and placing what we want covered in the IncludeFilter:
   
   

Based on the needs and depending on which of the two lists (Include or Exclude) are smaller, we can opt for option 1 or 2. The ouput should now be filtered:

Giving it some style

Only thing left to do is to format the output so that it can be viewed nicely inside a browser. This can be done easily using XSLT and some appropriate design skills (something I lack).

Included in the project you have an XSLT to create some HTML as well as one to covert the XML to JSON. Having JSON output allows us to combine it with something like jQuery to display a nice treeview or grid with the results.

Quite some time ago, several OSS leads asked us about whether JetBrains could provide OSS license for YouTRACK. We’ve taken it one step further, and in collaboration with the great folks at CodeBetter and Devlicio.us, we are pleased to announce YouTRACK at CodeBetter. Having TeamCity running most of the OSS projects on there, it only made sense to offer the same facilities for issue tracking at the same location. And seeing that YouTRACK integrates with TeamCity, we can offer all the functionality the combination is capable of.

I’d like to thank Kyle Baley, James Kovacs and Bredan Tompkins for making this possible, as without their support this wouldn’t happen. Not only are they generous in hosting YouTRACK, but also ran the risk of providing me with the credentials to the server, and at one point it looked like it had all gone to hell. Luckily however all seems to be working great now.

What are the next steps?

If you are an OSS project lead and  would like to use YouTRACK for your issue tracking, please email teamcity@codebetter.com with your details and you’ll be up and running in no time. If you want to learn more about YouTRACK, please visit our web site.

Finally I’ve managed to get the second part of the post on plug-ins. Sorry for the delay to everyone that was waiting. Appreciate your patience.  And now we’ll resume my holidays!

In the previous part of this series, we saw the basics of how to create a plug-in for ReSharper, install it and run it. We created a context action that would allow us to mark a public method as virtual (where applicable). However, this was done as an explicit action by the user, as such, you didn’t get any kind of hint or suggestion to do this. What we want to do now is make this a hint, so that highlighting appears under methods that could be made virtual. In this part we are going to expand on the same plug-in and convert it into a QuickFix.

What is a QuickFix?

Have you seen the little squiggly lines that appear in Visual Studio?

They usually indicate a Suggestion (field can be made read-only), Warning (possible null reference) or Error. ReSharper analyzes and can detect potential issues in the code (similar to what static checker of Code Contracts does). These are known as Highlights and they are related to QuickFixes in that usually a highlight has an QuickFix associated to it, which invokes a context action. This is usually done by placing the cursor on top of the highlighting and press Alt+Enter

Highlighting Daemons

In the gutter of the Visual Studio editor (right-side), ReSharper displays a series of warnings, errors and hints, which indicate potential issues on a specific file. These issues are detected by background processes known as Daemons. Since what we are looking for is for ReSharper to warn us of existing methods that could be made virtual, what we need to do is somehow hook into these daemons.

Step by Step Guide

The Daemons in ReSharper use the Visitor pattern to use act on elements, be it code, files, etc. The first step is to implement an IDaemonStage interface, which hold metadata about our daemon stage at at the same time acts as a factory for the actual process we are implementing.

There are two main methods to implement. The CreateProcess is what creates the actual process for us and the NeedsErrorStrip which indicates whether this daemon uses the gutter to display strips. The DaemonProcessKind parameter passed into the first method helps us discriminate on when this process should be executed, i.e. only during checking of visible (current) document, during solution wide analysis, etc.

The next step is to implement the process via the IDaemonStageProcess interface:

The main meat of this class is in the Execute method. We first check to make sure that we’ve not received an interruption (Interrupt Flag raised) due to some external action. Next step is to get access to the current file (remember that we are visiting the entire visible document, not just a specific method). Having the file, we can now create a RecusiveElementProcessor* to perform a tree walk of the AST and perform the specific action on each element. The action to perform is declared as the lambda expression. Since we’re interested in the method declaration, the type is IMethodDeclaration (there are many others). If we look at the expression, we can see that it’s pretty much the same as that of Part 1, the only difference is that we add the results to the highlighting variable.

The HighlightingInfo class has a parameter which can be a Suggestion, Warning or Error, as explained previously. Since in our case we need a suggestion, we pass in the MakeMethodVirtualSuggestion:

This class is pretty simple. The main property to define is the ToolTip, which is the text that will show when we hover of the highlighting. The ErrorStripeToolTip is what’s displayed in the right-hand side gutter. Finally the Attribute StaticSeverityHighlighting is to indicate what type of tip it is (Warning, Error, etc.).

[*Note: In this case, the operation we want to perform is very simple. If we want a more complex scenario where we need to do some processing before and after each element is visited or have a more fine-grained control, we can implement the IRecurisveElementProcessor. I’ll cover this in another post]. 

To recap, right now we would have everything place to display highlighting when a method that could be made virtual is encountered. The only remaining part is to now be able to apply a QuickFix. This is in many ways similar to the ContextAction we saw in Part 1:

The MakeMethodVirtualQuickFix needs to implement the IBulbItem and IQuickFix interfaces. For ease of implementation we can inherit from BulbItemImpl. The constructor should take as parameter always the actual highlighting that has given way to invoking the QuickFix, in our case the MakeMethodVirtualSuggestion. Similar to the ContextAction we implemented in Part 1, the actual fix itself is pretty trivial. All we need to do is make the method virtual. How do we get access to the method? The easiest way is via the Declaration property of the highlighting passed in (this is a property we added before). The only thing left is to call the SetVirtual method on it. Since we are in the ExecuteTransaction method, ReSharper makes sure that any change made is executed as a whole.

The rest of the properties are trivial. Text returns the text of the QuickFix (what appears in the menu), and IsAvailable indicates when the QuickFix is available, which in our case is whenever the highlighting is valid.

The End Result

Once we compile the plug-in and place it in the corresponding Plugins folder under ReSharper\Bin, we’re done. Here’s the end result:

and invoking Alt+Enter on the highlighting gives us:

Summary

Extending ReSharper to create highlightings and quick fixes is pretty simple once you understand how all the pieces fall into place. Most of the code will usually be the same and what will vary will be the actual element processing to be performed and the corresponding QuickFix. As mentioned previously (in the Note), for complex scenarios, we can have more control over the tree walk and that’s something we’ll examine in a future post.

I’ve placed the code up on my github account so feel free to download it, play with it and ping me if you have any comments or questions. The code is updated to work with ReSharper 5.1

[Thanks to Howard for his valuable input on some issues I first encountered]

In this short screencast you can see the basics of dotCover and how to get up and running in a matter of minutes.

dotCover allows us to run coverage analysis on our code. However, there are times when we do not want to perform an analysis on certain areas. This could be our test assemblies, certain third-party assemblies or even specific parts of our own project. Since the analysis has an impact on the overall statistics and potentially can take longer, it is often interesting for us to filter certain assemblies or classes out.

The figure below shows the coverage report of the default MVC project (yes, yet another MVC example, but it ships in the box and probably the ONLY template with VS that comes with tests). In this case we’re using xUnit for tests, which is mostly to demonstrate that dotCover works with other frameworks, not only MSTest (personally I’ve moved on to MSpec, which dotCover also supports).

If we focus on the Coverage results we can see that there are some areas in grey, which indicate that the corresponding PDB files were missing so coverage could not take place. We can also see other assemblies that have been included in the results yet might not be of interest, such as the test assemblies.

In order to filter these out, we can use the Coverage Filters, which can be accessed via the dotCover menu in the IDE

By default, everything is set to be covered, as shown by the Everything entry in the Allow Filters tab (which most likely will be renamed to Included). Examining this entry (clicking on Edit) we can see that it is composed of three values:

• Module Mask indicates the project name
• Class Mask indicates the class name
• Function Mask indicates the method name

(All entries support wildcards as displayed by the * that appears)

We can now uses these patterns to exclude projects, assemblies, namespaces, classes and methods from out tests.

Excluding entire project

Click on Deny Filters tab (most likely will be renamed to Excluded) and click on Add, entering the following information:

Clicking OK  and re-running the tests, we now see that the entire test assembly has been excluded

Excluding an entire Namespace

We can exclude entire namespaces by setting it in the Class Mask as shown below:

this will exclude all the classes inside the MvcApplication16.Models namespace. If we just wanted a specific class, we add it after Models instead of *.

Excluding a method

We can exclude a method, similar to how we’ve done it with the previous cases:

Adding a series of filters for test and auxiliary assemblies using the previous steps, we can end up with a cleaner and more accurate coverage report:

produced by adding the following filters:

Notice that by using the *.Tests (or alternatively as I call it *.Specifications), we can automatically exclude all our test projects from code coverage.

Beta Disclosure

Note 1: Currently these settings are Global, that is, they apply to all projects. Most likely we’ll be changing it so that they are Solution and Global scoped. This way, common libraries can be excluded for all solutions, and specific projects and/or namespaces can be solution based.

Note 2: We’re also looking at adding functionality to make it easier to define these exclusions (a la Right-Click on Folder, add to Excluded list)

As always, we’re still in beta and feedback is more than welcome!

We are happy to announce the release of dotCover 1.0 Beta, the latest addition to the .NET tools from JetBrains. dotCover is a Code Coverage tool providing you with information on how much of your code is covered by unit tests or execution. In this latest release, you can find the following functionality among others:

Code Coverage based on Unit Tests integrated with ReSharper Test Runner

By running your tests, dotCover can measure how much of your code is covered by these and potentially show you point of failures in your code. As opposed to the coverage tools that ship with Visual Studio, dotCover supports the majority of OSS frameworks such as NUnit, ,xUnit, MSpec, etc. as well as of course, MSTest. And best of all, you get to use ReSharper’s test runner, including sessions, keyboard shortcuts, etc.

Code Coverage based on Code Execution

Don’t have unit tests? Ask yourself why not, and get to work! But in the meantime (during your breaks from catching up on all those unit tests) you can still take advantage of dotCover’s coverage techniques. By executing your application, you can detect what parts of your code have been called and which parts are left out in the cold, during a typical usage scenario.

Console Runner

Want to automate code coverage in a Continuous Integration environment or call dotCover from your build scripts? You can do it easily using the Console Runner that ships with dotCover. In future versions we’ll even provide first class integration with TeamCity.

Filtering Coverage

dotCover provides functionality to filter out code from being covered, be it test assemblies or others. With a few simple settings you can define exactly what you want to be covered.

Covering Tests

Want to know what tests cover a certain section of code? No problem. With a simple operation, dotCover displays all tests covered by specific code.

IDE Integration

Tight IDE integration allows displaying of code coverage directly within the IDE without having to switch tools or change context. See what lines of code have been covered by a running test and which have not with visual highlighting.  You can even define your own colors.

More to come…

This is just the beginning of what we have planned for dotCover. Download the beta now and gives us your feedback. We’re very eager to hear about it!

One of the new features dotCover has added is the ability to find tests that cover a certain piece of code. Something remotely similar has been available in ReSharper, although it has been kind of an archaic solution (i.e. Find Usages on Method calls, locate Test assemblies in Result window).

dotCover makes this easier by providing quick access to this information and extends it in functionality.

Below we can see some tests from an MVC application. Let’s run Code Coverage on it using dotCover first.

Now let’s switch over to the Source Code and select some random source code, in this case the MembershipService.ChangePassword line in the ChangePassword action:

In order to see the tests that cover this line of code, we can either press the default key combination of Ctrl+Alt+K or select the option Show Covering Tests from the dotCover:

dotCover will then display a small window showing all the different tests that cover that line of code.

At this point, we can run the selected tests or add them to the existing ReSharper Test Runner session. This allows us to easily jump from specific sections of code to the corresponding tests and execute them instantly.

One minor note: The default key mapping conflicts with KeePass, but you can easily re-assign it via Visual Studio Tools | Options | Keyboard, or do as I did and change KeePass to Ctrl+Alt+P (P as in Password…makes more sense).