Today we are happy to announce availability of a new maintenance release of our .NET performance profiler. Please feel free to download and try the latest dotTrace 5.3.2 Performance.
Starting from this update dotTrace Performance supports the latest version of CLR. In case you have already updated CLR to version 4.5 or just plan to do it, we would recommend to use this version of the profiler.
On Tuesday, April 9th, we held a free webinar with Hadi Hariri and C# legend Jon Skeet. The concept was simple enough: to play with some of the most sophisticated ReSharper code inspections and have Jon try to break ReSharper with tricky code samples.
The recording of this webinar is embedded below and can be found directly on YouTube and JetBrains.tv. The examples used are also available for download.
We would like to thank all of the webinar attendees for your participation, questions and tremendous turnout and of course to Jon, thank you for taking your time to join us and share your wealth of knowledge!
About This Webinar:
Jon Skeet, man, father, legend. Some call him the Chuck Norris of C#. The guy that the compiler bends to obey joins us for this webinar to walk us through some of the inspections that ReSharper offers. He explains the theory behind it, tells us whether he agrees with it or not and does his best to try and break ReSharper. You can follow Jon on Twitter @jonskeet.
One of ReSharper’s most notable features, Code Analysis, is now unleashed and ready to hunt for bad and dead code—without even opening Visual Studio. Dubbed as InspectCode, it is as simple as a command-line tool can be and requires a minimum of one parameter—your solution file. But as it runs it will apply all of ReSharper’s code inspections—that’s over 1,400 of them—to code in all languages supported by ReSharper!
Can’t wait to try it out? Find the latest ReSharper 8 EAP build, download and unzip the Command Line Tools package, and then run InspectCode [SolutionFile].
While the tool works its way through your code, let’s take a closer look at its features and use cases.
Execution of InspectCode results in an XML file with code issues found within the specified scope (the whole solution or particular projects). The XML comprises two parts:
How the output should be processed is up to you. But here are a couple of recommended next steps: transform the output to an HTML report, or generate some messages on your continuous integration (CI) server based on number and types of detected issues.
Now let’s see how we can use the tool and what exactly we can do with its output. It may be helpful to run it on your local machine, but only if you don’t have ReSharper, because with ReSharper you can get inspection results for a selected scope with a couple of clicks and, if necessary, export detected issues to a report file. A more promising case is to use InspectCode on a CI server where you can integrate it in the build script and add code inspection results to your build reports and messages.
The JetBrains Teamcity team, who is pioneering the use of this tool right now, has created the following visual presentation of the code issues detected by InspectCode:
To learn more, refer to the TeamCity documentation or download the latest version to try it out.
By the way, if you come up with more usage scenarios as you try out InspectCode, please share them with us.
If you have previously worked on the target solution with ReSharper, you may have already configured code inspections settings. If so, InspectCode will find your custom settings in .DotSettings files and apply them. If there are no settings files, then the default severity levels will be used for all inspections.
Besides custom severity levels for code inspections, InspectCode looks for the following settings in .DotSettings files:
/no-swea parameter)If you want to configure InspectCode on a CI server, you can make all configurations locally with ReSharper, save the settings to the Solution Team-Shared layer, and then commit the resulting SolutonName.sln.DotSettings file in your VCS. InspectCode on the server will find and apply these settings.
As an alternative, you can configure InspectCode by specifying a shared .DotSettings file through the /profile (/p) parameter. In this case the specified settings layer will override settings in all other layers. (See this post to learn how to create and share a common settings file.)
We have already mentioned two optional parameters: /profile (/p) and /no-swea. Among other optional parameters (which you can see by typing InspectCode /help) the following may come in handy:
/output (/o) - lets you set the output file. By default, the output file is saved in the %TEMP% directory./project - allows analyzing particular project(s) instead of the whole solution. After this parameter, you can type a project name or a wildcard that matches several projects within your solution./no-buildin-settings - can be used to ignore settings from the Solution Team-Shared layer (SolutonName.sln.DotSettings file)./caches-home - lets you specify a custom location for the data that InspectCode caches. By default, the %TEMP% directory is used, unless there are settings files, in which case the one specified there is used. This parameter can be helpful if you want to use a fast SSD disk for the cache or if you want to store all your build processing data in a single place.So our command line could look like this:
InspectCode C:\Projects\ReSharper\resharper.sln /project=Documents /o="C:\temp data\Results.xml" /no-swea
That’s about all for the introduction of InspectCode. Now let us try and answer some questions you might ask:
If you have more questions or feedback about the Command Line Tools, we’ll be happy to hear from you.
We’ve already had a series of blog posts on remote profiling with dotTrace. We’re now accompanying it with a short video that demonstrates how to attach the dotTrace profiler to a remote server (in this case hosted on Azure), which may become handy when a performance problem only occurs on staging or production. Head over to JetBrains TV to watch this screencast.
Enjoy the screencast! As always, comments and questions are more than welcome.
With dotTrace Performance, we can profile applications running on our local computer as well as on remote machines. The latter can be very useful when some performance problems only occur on the staging server (or even worse: only in production). And what if that remote server is a Windows Azure Cloud Service?
Note: in this post we’ll be exploring how to setup a Windows Azure Cloud Service for remote profiling using dotTrace, the “platform-as-a-service” side of Windows Azure. If you are working with regular virtual machines (“infrastructure-as-a-service”), the only thing you have to do is open up any port in the loadbalancer, redirect it to the machine’s port 9000 (dotTrace’s default) and follow the regular remote profiling workflow.
Since we don’t have system administrators at hand when working with cloud services, we have to do some of their work ourselves. The most important piece of work is making sure the load balancer in Windows Azure lets dotTrace’s traffic through to the server instance we want to profile.
We can do this by adding an InstanceInput endpoint type in the web- or worker role’s configuration:
By default, the Windows Azure load balancer uses a round-robin approach in routing traffic to role instances. In essence every request gets routed to a random instance. When profiling later on, we want to target a specific machine. And that’s what the InstanceInput endpoint allows us to do: it opens up a range of ports on the load balancer and forwards traffic to a local port. In the example above, we’re opening ports 9000-9019 in the load balancer and forward them to port 9000 on the server. If we want to connect to a specific instance, we can use a port number from this range. Port 9000 will connect to port 9000 on server instance 0. Port 9001 will connect to port 9000 on role instance 1 and so on.
When deploying, make sure to enable remote desktop for the role as well. This will allow us to connect to a specific machine and start dotTrace’s remote agent there.
That’s it. Whenever we want to start remote profiling on a specific role instance, we can now connect to the machine directly.
And then that moment is there: we need to profile production!
First of all, we want to open a remote desktop connection to one of our role instances. In the Windows Azure management portal, we can connect to a specific instance by selecting it and clicking the Connect button. Save the file that’s being downloaded somewhere on your system: we need to change it before connecting.
The reason for saving and not immediately opening the .rdp file is that we have to copy the dotTrace Remote Agent to the machine. In order to do that we want to enable access to our local drives. Right-click the downloaded .rdp file and select Edit from the context menu. Under the Local Resources tab, check the Drives option to allow access to our local filesystem.
Save the changes and connect to the remote machine. We can now copy the dotTrace Remote Agent to the role instance by copying all files from our local dotTrace installation. The Remote Agent can be found in C:\Program Files (x86)\JetBrains\dotTrace\v5.3\Bin\Remote, but since the machine in Windows Azure has no clue about that path we have to specify \\tsclient\C\Program Files (x86)\JetBrains\dotTrace\v5.3\Bin\Remote instead.
From the copied folder, launch the RemoteAgent.exe. A console window similar to the one below will appear:
Not there yet: we did open the load balancer in Windows Azure to allow traffic to flow to our machine, but the machine’s own firewall will be blocking our incoming connection. To solve this, configure Windows Firewall to allow access on port 9000. A one-liner which can be run in a command prompt would be the following:
netsh advfirewall firewall add rule name=”Profiler” dir=in action=allow protocol=TCP localport=9000
Since we’ve opened ports 9000 thru 9019 in the Windows Azure load balancer and every role instance gets their own port number from that range, we can now connect to the machine using dotTrace. We’ve connected to instance 1, which means we have to connect to port 9001 in dotTrace’s Attach to Process window. The Remote Agent URL will look like http://<yourservice>.cloudapp.net:PORT/RemoteAgent/AgentService.asmx.
Next, we can select the process we want to do performance tracing on. I’ve deployed a web application so I’ll be connecting to IIS’s w3wp.exe.
We can now use our application and try reproducing performance issues. Once we feel we have enough data, the Get Snapshot button will download all required data from the server for local inspection.
We can now perform our performance analysis tasks and hunt for performance issues. We can analyze the snapshot data just as if we had recorded the snapshot locally. After determining the root cause and deploying a fix, we can repeat the process to collect another snapshot and verify that you have resolved the performance problem. Note that all steps in this post should be executed again in the next profiling session: Windows Azure’s Cloud Service machines are stateless and will probably discard everything we’ve done with them so far.
Since we are profiling a production application, we may get in the way of our users by collecting profiling data. Another issue we have is that our own test data and our live user’s data will show up in the performance snapshot. And if we’re running a lot of instances, not every action we do in the application will be performed by the role instance we’ve connected to because of Windows Azure’s round-robin load balancing.
Ideally we want to temporarily remove the role instance we’re profiling from the load balancer to overcome these issues.The good news is: we can do this! The only thing we have to do is add a small piece of code in our WebRole.cs or WorkerRole.cs class.
Essentially what we’re doing here is capturing the load balancer’s probes to see if our node is still healthy. We can choose to respond to the load balancer that our current instance is busy and should not receive any new requests. In the example code above we’re checking if the file C:\Config\profiling.txt exists. If it does, we respond the load balancer with a busy status.
When we start profiling, we can now create the C:\Config\profiling.txt file to take the instance we’re profiling out of the server pool. After about a minute, the management portal will report the instance is “Busy”.
The best thing is we can still attach to the instance-specific endpoint and attach dotTrace to this instance. Just keep in mind that using the application should now happen in the remote desktop session we opened earlier, since we no longer have the current machine available from the Internet.
Once finished, we can simply remove the C:\Config\profiling.txt file and Windows Azure will add the machine back to the server pool. Don’t forget this as otherwise you’ll be paying for the machine without being able to serve the application from it. Reimaging the machine will also add it to the pool again.
When working with TeamCity and Visual Studio, we can do a lot of things right from within our IDE. We can trigger a remote run, fetch dotCover code coverage information from the server, view changes and builds from a tool window, navigate to unit tests and a lot more. In this post, we’ll be looking at some of these features. But first things first: let’s install this nifty tool!
Every TeamCity installation ships with several tools for IDE integration (with our IntelliJ IDEA based tools as well as with Visual Studio). We can find the plugin on every TeamCity server under the My Settings & Tools page. We can download the plugin right there!
After downloading and installing the plugin, we can find a new menu item in our Visual Studio.
From this menu, we can connect to our TeamCity server using the Login… menu item. After entering the URL to our TeamCity server and providing the correct credentials, we can start exploring.
When developing a project in Visual Studio, we can initiate a personal build using the TeamCity plugin for Visual Studio. We call this a “remote run” because the build that is triggered runs on a TeamCity build agent, not on the developer’s machine. The interesting thing here is that this remote build uses the current version control repository sources plus the changed files in the developer’s IDE. All steps from the build configuration are executed for this personal build as well.
After changing some files locally, we can use the TeamCity | Remote Run (Local Changes) menu to trigger a remote build. In the dialog that opens, we can select the changes we made locally that should be included in this personal build. We can select all changes or cherry-pick just the changes we want to verify on the build server.
Note that we’re using Subversion as the source control system here. Remote Run is available for TFS, Subversion and Perforce. When using Git or Mercurial, the workflow is slightly different. Check the documentation on branch remote run for more information.
When we click the Configure personal build… icon in the toolbar, we have to make some other decisions. First of all, we must select the build configuration we want to use for the personal build. Next, we can provide a comment for this personal build. This comment will be shown in the TeamCity web UI afterwards to describe the personal build.
One interesting option is the Pre-tested Commit checkbox and its related commit if setting. Using this, submitted code changes first go through testing. If all tests pass, TeamCity will automatically commit the changes to version control and integrate it in the next build. When tests fail, the code is not committed and the developer who made the change is notified about this. Here’s a chart of the pre-tested commit workflow.
We can even customize our build: put it at the top of the queue or add additional build parameters.
After clicking the Run button, TeamCity will run the selected build configuration for the included changes. We can see the results in the TeamCity web UI, consult the build log, check unit test results and so on.
Since this post is about the TeamCity plugin for Visual Studio, we can also verify the status of builds triggered because of our changes by using the TeamCity | My Changes menu.
From the toolbar, we can consult the build log for every personal build listed in the My Changes window. Clicking the Show Build Log icon (or right-clicking the build and selecting the appropriate context menu) will instruct the TeamCity plugin for Visual Studio to download the build log directly from TeamCity.
Did your changes cause a unit test to fail? No worries: we can use the Open Failed Tests context menu from the My Changes window in order to see what is going on. From the window that opens we can re-run the failing tests locally using the ReSharper test runner.
When you have dotCover installed on your machine, the TeamCity plugin for Visual Studio enables us to view code coverage results. Using the TeamCity | Coverage menu item we can select a code coverage snapshot to open.
After selecting and opening a snapshot, we get dotCover’s test runner showing code coverage. We can even double-click a class from the snapshot shown and explore code coverage at the statement level.
Whenever a build fails, we can volunteer to fix the build by starting an investigation. From the TeamCity | My Investigations menu, we can manage our investigations and take action on open investigations by either fixing it or giving up (when working in developer teams in Belgium, that last option typically results in having to bring pastries for the team).
The TeamCity web UI features an Open in IDE button on many places. For example, when inspecting changes that were included in a build, we can open the file that was built in our IDE by clicking the IDE icon.
We can open tests in the IDE as well, again using the Open in IDE function. When working with tests, this will trigger Visual Studio to open the ReSharper test runner and display the selected test.
Give the TeamCity plugin for Visual Studio a go and let us know what you think!
Two quick maintenance releases to our .NET tools become available today: please download ReSharper 7.1.2 and dotTrace 5.3.1 Performance.
ReSharper 7.1.2 contains fixes to Find Usages (RSRP-336714) and auto-completion in XAML (RSRP-337050), brings a pack of unit testing improvements related to running MSTest fixtures in Visual Studio 2012 (here’s the list of fixes), and adds more updates to the installer.
dotTrace 5.3.1 Performance fixes fetching PDB files required for code preview (DTRC-8228), and improves installation in certain scenarios.
If you’re experiencing any of the issues mentioned above, please try out these new updates. However, if previous releases are working fine for you, it’s probably best to just stick with them.
Since ReSharper 5, we’ve had splendid support for ASP.NET MVC. One of the features included for ASP.NET MVC is Navigate to View and Create View. When working in an ASP.NET MVC action method, these methods allows us to either navigate to the corresponding view or create a view with the correct name at the correct location.
The interesting part of this feature is that ReSharper checks for assignments to the different properties on a ViewEngine, such as ViewLocationFormats and PartialViewLocationFormats, to determine the paths to various view types. This means it is possible to diverge from the default conventions in ASP.NET MVC and still make use of the ASP.NET MVC support ReSharper gives us.
Imagine having a project in which views are not located in the conventional Views folder but instead in another subfolder, like UI/MVC/Razor. We can do this in ASP.NET MVC by creating a new ViewEngine implementation and specifying a path template in the constructor:
To ensure ASP.NET MVC makes use of this custom ViewEngine, we must register it in Global.asax under Application_Start:
What’s interesting is that ReSharper immediately tells us no views can be found:
We can now move our views to the correct location or have ReSharper create them for us using the Create View feature. The new view will be located in our project under UI/MVC/Razor/Home/Index.cshtml.
Pretty slick if you ask me!
When Hadi tried to create an Entity Framework app, he realized just how bad of a noob he really was (not surprising). He then decided to call on a favor to Julie, the Data Farm Queen. As Julie was teaching Hadi, he kept interrupting her to tell her about easier ways to do things using ReSharper. That’s when they decided to stop right there and make the whole thing public. Julie would teach Hadi EF and he would in exchange show her some tips on how ReSharper could help with coding. Seems like a win-win situation. What could possibly go wrong?
In this webinar, you’ll join Hadi in understanding how to do Entity Framework Code First while at the same time see what benefits ReSharper offers and how to use it efficiently. Well…that’s the plan anyway.
This free webinar will take place Thursday, January 24th from 16:00 – 17:00 CET (Central European Time). Space is limited; please register now.
Julie Lerman is a Microsoft MVP, .NET mentor and consultant who lives in the hills of Vermont. You can find Julie presenting on Entity Framework and other Microsoft .NET topics at user groups and conferences around the world. Julie blogs at thedatafarm.com/blog, is the author of the highly acclaimed “Programming Entity Framework” books, the MSDN Magazine Data Points column and popular videos on Pluralsight.com. Follow Julie on twitter at julielerman.More and more developers are jumping on the opportunity to create applications for the Windows Store. Since most of these apps are very visual and need to be very responsive, it’s really important to know if and where there’s room for improving the application’s code. With the release of dotTrace Performance 5.3, you can now profile Windows Store applications and test projects from within Visual Studio.
As a sample project, I’ve created a simple RSS feed viewer which displays all blog posts on the JetBrains .NET blog. In the screenshot below, you’ll see that there’s a list of blog posts on the left and their contents on the right.
When using the application, everything feels smooth and responsive. Nevertheless it’s good practice to use a profiler to check if you have any potential bottlenecks. After installing the latest version of dotTrace Performance, you will find a new menu item in Visual Studio 2012 from which you can launch a profiling session.
From this menu, you can either profile the current startup project that’s open in Visual Studio, or launch a profiling session for another application. Let’s go with Profile Startup Project as you will probably have it open in your IDE.
Before the profiling session starts, you have to specify how you want to profile. Specifics on all the knobs and handles can be found in the dotTrace Web Help section. For this profiling session, I’ve selected the line-by-line profiling mode. Typically your first profiling session would be based on sampling (less precise but faster) and once you know what you are after you can have more precise results by selecting the tracing or line-by-line profiling mode. Since my RSS reader is a fairly small and simple application, I’m immediately opting for the most precise results using line-by-line mode.
After clicking Run, your application will be launched. If you’re not sure what you’re looking for, simply navigate through it and use it. I’ve clicked a couple of blog posts and waited for them to show up in the application. Once you feel you’ve collected enough information, click the Get Snapshot button in the dotTrace profiler window.
A snapshot of your profiling session is now shown. On the left hand side, you can select one of the various views available in dotTrace Performance to dive into the collected results. In the next screenshot, I’ve selected the Threads Tree. You will notice that the first two threads shown are annotated with a red arrow instead of a black one. This is because those threads have been using the CPU much more than the other threads.
It may be worth investigating the Main Thread, but most often the time shown here is the total time you have had your application running. Thread #3 in the current profiler snapshot is more interesting. It seems that by clicking just a couple of posts in the application, there’s 1430ms spent in the ItemListView_SelectionChanged method. If I drill down deeper, it looks like the TrackView method is taking 1418ms out of that time. That’s a large percentage of time!
If you look at the source code in dotTrace’s bottom pane, the purpose of this TrackView() method is to gain some insight into which posts are being read through the RSS feed viewer application. This method is obviously taking quite some time and may slow down the displaying of a post when I’m using the application on a slower Internet connection.
By profiling this RSS feed viewer Windows Store application, I’ve now successfully identified a potential performance issue even if there was no direct reason for me to go and dive in. Go and download a trail version of dotTrace Performance and profile your own applications too. It may make them much more responsive once published to the Windows Store.
Enjoy profiling your Windows Store applications!
Tweets about .NET tools
