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.
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.
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.
Just so you know, we’re continuously trying to improve the coding experience of everyone who works with XAML. ReSharper 7.0 that we have released a couple of months ago was highly focused on supporting Windows Store application development and quite frankly, didn’t contain many changes targeted at a broader crowd of XAML pros. Come 7.1, it’s time to make everyone happier, even if you’re not very much into Windows Store apps right now.
The main challenge that we’ve solved in ReSharper 7.1 was to come up with fast, smooth and smart automatic code completion in XAML markup. Providing code completion lists in XAML is sometimes a non-trivial task: for example, WPF actually exposes hundreds of public types with lots of members like attached properties and events that should be taken into account while building completion lists. By virtue of reviewing our caching strategies in ReSharper 7.1, we ended up with a nice performance boost in code completion and whole XAML support as well.
Automatic completion by design drops many possible types that you can possibly use to qualify properties in XAML markup and includes only types that can bear a meaning in the current context:
If you’re looking for the full list of possible types with attached properties/events, just invoke symbol completion (Ctrl + Space). This behavior differs from that used in other languages where automatic completion works pretty much the same as symbol completion. However, it makes XAML lookups much cleaner and more precise in most cases. If you happen to find this behavior confusing, please vote or leave a comment under this issue.
Property completion in XAML now highlights a type’s own properties with bold, helping identify control-specific properties among thousands of those inherited from framework classes:
When generating completion lists for markup extensions, ReSharper can now filter out properties that you have already set:
An action to generate event handlers is now available with both automatic and symbol code completion:
If invoked inside an empty x:Name attribute, symbol code completion now suggests name options derived from control type name. If you’re providing a prefix for the new name, it still works as expected:
Automatic code completion is getting much more useful when dealing with resources: completion list is filtered based on expected resource type:
Field modifiers in Windows Store applications are now correctly handled and completion list now includes the previously missing protected modifier:
Different icons help identify markup extensions when using object element syntax:
Automatic closing tag code completion in all XML-based languages now only shows tags that are actually not closed:
A plethora of other small improvements has been implemented in code completion for XAML, including fixes in the calculation of expected types and improvements in Windows Workflow Foundation (WF) projects. As expected, XAML code completion in ReSharper reacts to type changes immediately, without requiring to build your project.
The second important area that has been improved for XAML developers is typing assistance.
ReSharper 7.1 introduces some really nice bits of HTML editing experience to XML-based formats (including XAML, web.config, MSBuild scripts and all other kinds of XML documents) — for example, synchronous tag editing:
A feature called smart slash helps create self-closing tags by automatically removing the closing tag and placing the caret after the new tag for you (and also removing any white space that could have left between the converted pair of tags):
In order to prevent code completion from getting in your way, it should be able to detect when you’re trying to enter characters that had already been completed for you. In the case below, ReSharper auto-completes the closing angle bracket of the opening tag, as well as the entire closing tag. Meanwhile, if you’ve not looking at the screen and proceed to entering the closing angle bracket yourself, ReSharper simply merges the two brackets to prevent duplication:
One of the greatest benefits of using ReSharper with XAML is static typing of data bindings. When ReSharper knows the binding source type it offers you a lot of opportunities: navigation directly to bound properties, code completion for property paths, refactoring support, error validation, and more. Static typing increases maintainability of your XAML markup, especially in applications with heavy usage of bindings (like MVVM-based apps.)
ReSharper is trying to infer the type of binding source in many ways (like in the screenshot above) but in cases where it’s not possible, there’s an easy way to annotate the data context type with design-level annotations, now using a submenu:
Such annotations are usually only required at the top level of XAML element trees. ReSharper 7.0 is trying to utilize the property name you have already typed and suggest a smart choice:
If the suggested type doesn’t fit, you can trigger import completion or enter a new type that can then be declared from usage.
ReSharper 7.1 offers new ways to infer binding source type. One popular scenario that is now supported involves binding through the DataContext property of another named control element. ReSharper can now share information about data context type between different controls:
ReSharper provides code completion and other features despite <DataContext property being of System.Object type. Similar bindings with RelativeSource mode are also supported.
If you are using custom markup extensions as binding source, ReSharper 7.1 can now calculate data context type from [MarkupExtensionReturnType] annotation in WPF (or implementation of IMarkupExtension<T> interface in Silverlight 5):
Binding type calculation also deals with CollectionViewSource in ReSharper 7.1 with respect to design-level attributes like d:DesignSource. Finally, ReSharper 7.1 introduces support for IValueConverter annotated with [ValueConversion] attribute:
ReSharper 7.1 now highlights naming consistency issues in XAML markup just like in other supported languages and offers actions to fix naming. Naming rules are configurable for XAML fields, resources and namespace aliases.
ReSharper’s Create from usage family of quick-fixes can be very useful during development of custom controls or building custom object structures in XAML markup. ReSharper 7.1 knows a lot about all the types that you are using inside markup and improves actions like Create type and Create property with calculation of expected types — similar to how it does in C# and VB.NET:
You can specify a resource for a non-existing property, use nested object element like in the example above or even bind the property to something — ReSharper 7.1 will suggest the correct type for the new property when it creates it from your usage:
ReSharper 7.1 introduces basic support for custom resource dictionaries and binding extensions. Custom structures are currently detected via naming conventions. Inheritors of ResourceDictionary type should be named using “ResourceDictionary” suffix in order to be correctly handled by ReSharper in XAML markup and participate in resource resolution:
There’s a similar story with custom bindings: you should use “Binding” suffix to enable ReSharper support for your custom markup extensions that complement XAML binding capabilities:
In future versions, we’ll be looking to provide adequate tooling without enforcing any particular naming conventions.
We’ve also implemented a number of miscellaneous XAML support fixes including (but not limited to) the following:
Here’s the full list of XAML-related fixes implemented for ReSharper 7.1 this far, and we still have quite a bit on our XAML support improvement agenda.
As usual, any feedback on your experience with ReSharper XAML support is highly appreciated! To test drive the recent changes, make sure to download a fresh ReSharper 7.1 EAP build.
Say hello to ReSharper 7.1 EAP! Starting today, you can download early builds of the new ReSharper update.
In this release, we’re trying to focus on little things: removing minor but irritating flaws as well as introducing small improvements that go a long way towards better usability. The everlasting battle for smooth performance and light memory usage is also in full force. Anyway, read on to learn what we have in store as of EAP launch.
We know that code formatting is a very sensitive set of IDE functionality — to the extent of donating kingdoms in return for fixing formatting issues. Seeing a set of these issues that have accumulated over the years, we decided it was time for action.
Specifically, following enormous demand, ReSharper now provides versatile settings to format chained method calls. For example, you can chop chained calls while giving preference to wrap after delimiter dots:
In conjunction with a new option to align chained method calls, this gives you the following formatting setup:
Second, facing the region controversy, Code Cleanup doesn’t introduce regions by default anymore. Too many people consider regions a code smell, and we had to do something about it.
In other formatting news, code formatter now indents with tabs only if using spaces is not allowed in a specific coding standard; there’s now a new options page which actually makes formatting XML doc comments a feasible task; and if you’re an ASP.NET developer, look for a new option to always use Kernighan & Ritchie style brace layout in markup pages regardless of whatever style you’re using in code-behind. There are even more formatting and cleanup fixes — here’s the full list in case you’re interested.
If fixing some of the weirdness in code formatting behavior wasn’t enough, we handled quite a bit of other annoying bugs. For instance, configured JavaScript abbreviations are now respected by JavaScript naming inspections; moving types or files no longer changes their encoding; and importing types for pasted code doesn’t bring up an ugly dotted box.
Following insightful feedback from John Papa and other long-time users, we’ve revised the experience of working with Inspection Results and Errors in Solution tool windows, primarily in order to streamline sharing ReSharper inspections with non-ReSharper users (amazing but there are some) as well as creating work items based on inspection results.
Specifically, you can now copy individual entries or custom selections of entries from both Inspection Results and Errors in Solution:
This is handy if you’re working in a team environment and assigning work items based on ReSharper inspections to different developers: copy an issue or a group of issues, submit the copy to an issue tracker, and there you go into the wonderful world of delegation!
However, copying an entry or a selection gives you a plain text copy of the issues that ReSharper has detected. If you’re a fan of HTML- or XML-based issue reports, be informed that entries can now be exported from Errors in Solution (this was previously only available from Inspection Results):
Speaking of XML reports, that was the only export format that included line numbers in previous ReSharper versions. In 7.1, we’ve put an end to this inexplicable injustice: HTML and plain text exports now include line numbers, too:
ReSharper 7.1 takes advantage of Caller Info attributes when it implements INotifyPropertyChanged in .NET Framework 4.5 projects. Needless to say, if your project is targeting .NET Framework 4.0 or below, ReSharper still uses the traditional syntax.
The new version also facilitates migration to CallerMemberName-based implementations by highlighting redundant arguments. If you happen to have, say, an OnPropertyChanged implementation that includes a parameter annotated with CallerMemberName, any calls passing explicit arguments will be marked as redundant:
There’s more in store regarding INPC support in ReSharper 7.1, so stay tuned for a separate blog post.
We’ve received complaints stating that we were taking advantage of the Preview tab in Visual Studio 2012 in more cases than it made sense.
In 7.1, all contextual (such as Go to Declaration or Go to Implementation) and context-insensitive (Go to File or Go to Symbol) navigation actions are reverted to open files in standard text editor tabs. The Preview tab is still used to open files that you’re selecting via Enter from tool windows such as Find Results.
Do you think this is a better way to use the Preview tab? Please let us know!
Many refactorings have received a level or two up in terms of stability and functionality. For example, Extract Class is now working with VB.NET in addition to C# code, plus the C# implementation has received a substantial share of bug fixes. (You’ve watched the video on using Extract Class, haven’t you?)
Change Signature now works correctly with default parameter values and handles usages of named arguments just fine. Other fixes cover Extract/Inline Method, Rename, Extract Superclass, Introduce Variable, Pull Members Up and quite a few more refactorings — here’s the full list of fixes.
A couple of code analysis false positives are now gone, and extension methods should now be resolved without extra manipulations with ReSharper caches.
For example, VB.NET quick-fixes for WinRT have been added to pair those available for C#; VB.NET inspections can finally be suppressed with comments; IntelliSense has been fixed for enums and LINQ-to-SQL joins. On top of that, as mentioned above, Extract Class refactoring is now functional in VB.NET code.
ReSharper now consents with the exotic case of wrapping asp:placeholders with styles in ASP.NET markup files. ASP.NET MVC developers should be happier as ReSharper 7.1 handles cases where file names of views are not derived from action names and resolves relative view paths much better. For details on more web dev fixes, see this list.
These traditionally cover all kinds of technologies but most importantly SharePoint, ASP.NET MVC and resource files. On another note, if you’re a fan of typing in web.config files, this should now be a much smoother task.
First off, nested references are now supported for JavaScript testing frameworks (both QUnit and Jasmine).
Another improvement is relevant to a broader scope of unit testing practitioners however. If you have a great load of unit tests in your session, there’s now an easy way to filter the session to specific tests — just use quick search that is now available in Unit Test Sessions:
If you’ve read through to this point, you just owe it to yourself to download a ReSharper 7.1 EAP build.
Questions? Bug reports or improvement requests? We’re all listening.
As of version 5 of dotTrace Performance we started shipping as part of the package, an SDK which allowed us to programmatically make use of dotTrace Performance engine. We are excited to announce that we are now offering this as its own standalone product, with its own installer, and available for free. Download it here.
Performance issues generally are a pain. They usually only appear in production and are hard to pinpoint and even worse to reproduce. When performance issues arise, the first step is to run analysis on the application to try and find the bottlenecks, and this isn’t always easy in production. To begin with, we need to interact with the machine where the application is running. With dotTrace Performance we’ve made this somewhat easier by allowing remote profiling. Secondly however, we need to have some knowledge to collect this information, in other words, know how to work with dotTrace Performance. This usually means a member of the support team or developer. Not the customer.
Wouldn’t it be great however if this weren’t necessary? Imagine if we could just instruct the program to profile itself. Well that is what the SDK is bringing to the table, and more!
Let’s take a look at some of the scenarios that the SDK enables.
As mentioned previously, one of the great advantages of the SDK is to allow an application to profile itself and gather performance metrics. In ReSharper 7 we are already making use of this functionality. When you install ReSharper, you will notice a new menu entry under Help menu:
When we execute this option, the dotTrace performance engine kicks in and attaches itself to the running process. It then starts to gather information about everything that is going on in the application. Once enough information has been gathered, it creates a snapshot file that can be analyzed by dotTrace Performance and more importantly, it can be detached from the process. As we know, running an application under a profiler has a performance penalty so it is fundamental to only do it for the minimum time required.
By default, when invoking this functionality, the dotTrace Controller pops up:
However, this functionality can be customized to one’s own needs, so we can in fact have something that blends in more with our application and we also have access to events that allow us to intercept the snapshot and do what we want with it.
When analyzing performance snapshots, we usually focus on our own application code and ignore system code such as the BCL calls or libraries and frameworks that we cannot necessarily do anything about. With some applications this is easy to accomplish as dotTrace Performance grays out irrelevant code and allows us to focus on our own. However with certain types of applications, it’s not always straightforward as it’s hard to often distinguish entry points from the users perspective.
The SDK now allows us to indicate where we want to focus our performance analysis by allowing us to define entry points. For instance, in an ASP.NET WebForm application, we can add the following code to the Application_Start event:
This means that if we’re running under dotTrace Performance (in other words profiling the application), to start monitoring our code. We can then indicate where we want to stop monitoring also:
and thus allowing the focus to stay within the bounds of the code we are interested in. Notice how we do not have to make explicit calls to the profiler. We just indicate when we want to start and when we want to finish.
By doing this, we can now activate the Use Profiler API checkbox in dotTrace Performance
and thus removing all irrelevant infrastructure code that we are not interested in from the analysis.
Although not a scenario as such, the ability to pause and resume performance, gives us the ability to provide on-demand profiling in our applications. We can have SDK calls in the code and activate them on demand.
Once we download and install the SDK, the application folder where it is installed contains 4 folders:
The Doc contains the documentation for the API classes which we’ll examine briefly in a moment. The Lib folder is the two assemblies that are referenced in applications that use the SDK. An important folder is the Redist. This contains a redistributable copy of the dotTrace Performance engine which should be shipped with your application if you’re using the Self-Attach functionality. Finally Samples provides two documented samples of how to work with the SDK in the scenarios depicted previously. One of them is the VSTool Visual Studio self-profiling add-in and the other is an ASP.NET WebForms application.
The SDK itself has a small surface area, with only a few classes. Namely the important ones include:
When using the SelfAttach class, we can indicate how we want the behavior to be once a snapshot has been taken. We can opt on opening the snapshot file, saving it or have it processed by a third party assembly. Each of these options have their own settings and are defined by different classes:
We pass as constructor to argument to SelfAttach an instance of one of these classes. The VSTool demo shows example usages of all three.
An important option among the configuration classes is the ProfilerControlKind property which indicates how the profiling process is controller. The default option (as described above in the Self-Profiling) is to use the dotTrace Controller window. Alternatives are None or using the API.
This is the first big release of the SDK and based on the feedback we receive we want to improve it and make it more versatile, so we appreciate any and all comments. As mentioned the SDK is freely available. You do not need to own a license of dotTrace Performance to distribute it. You do however of course need dotTrace to analyze the results. The point is though to make it simple and cheap for you to include this functionality inside your applications
You can download the SDK from here.
Enjoy and please give us any feedback.
We’re happy to announce that dotTrace Performance received Jolt Productivity Award as a leading developer utility!
Starting from 1991, the Dr. Dobb’s Jolt Product Excellence & Productivity Awards are presented annually to showcase products that have made the task of creating software faster, easier, and more efficient. We are very grateful for this award, and would like to thank Dr. Dobb’s, the Jury and our users who continuously help us improve our products.
dotTrace 5.2 Performance has just been released and ready for you to download now! This is a minor release update that includes close to a dozen bug fixes, and it also lays some ground-work for some exciting features in upcoming releases.
dotTrace 5.2 Performance provides support for .NET 4.5 applications. As such we can now profile any managed application targeting the newest version of the Microsoft platform. Currently there is no integration with Visual Studio 2012 but we will be adding support for that in an upcoming release. It is possible however to use dotTrace Performance standalone to profile .NET 4.5 applications. dotTrace Performance works perfectly under Windows 8.
We are also pleased to announce that dotTrace Performance now joins the ranks of our other tools by offering Classroom and Academic licenses. If you are a School, University, College or Trainer, you can apply for a classroom license for dotTrace performance.
Among some other important updates, next release will include support for both Metro style application as well tight integration with Visual Studio 2012, as well as continuous enhancements to the profiling SDK which is coming soon.
Hello everyone! Hope you’re having a good time using the new ReSharper 5.0. If you do, just ignore this post :)
If you’re facing issues with ReSharper 5.0, read on. There are certain bugs, usability problems and otherwise weird behavior that users report following the release (surprise!). Some of them you can work around, others you can’t, but both kinds of issues will be addressed in the upcoming ReSharper 5.1. It’s scheduled for release in June but we’ll open the Early Access Program in May, and chances are that the most annoying issues will be fixed in these early builds.
Here are some of the most annoying issues that have known workarounds:
GetTempFileName() in Windows 7 or in Windows Server 2008 R2 causes UnauthorizedAccessExceptionGetTempFileName() function in Windows 7 and Windows Server 2008 R2 handles a duplicated file name incorrectly. Download this Microsoft hot fix to remove the issue.We also receive reports about performance issues when renaming and doing Find Usages in large projects that contain aspx files. We are doing performance analysis and aiming to solve these issues in time for the bug fix release.
Just in case you’re interested, here’s the full list of issues currently scheduled for ReSharper 5.1.
On a different note, people report on a regular basis about Visual Studio 2005 or 2008 installations that freeze or crash after opening web forms, or Solution Explorer that hangs up. There are known solutions to this kind of issues (not having anything to do with ReSharper), including:
Before you contact us with such issues suspecting ReSharper, please make sure to try the solutions provided above.
By the way, if you’re using Visual Studio 2010, have you installed Windows Automation API? Rumors say it really boosts Visual Studio performance, particularly with ReSharper.
If you haven’t done so yet, check out Ilya Ryzhenkov’s blog for some insight concerning ReSharper 4.5. Scheduled for release in early 2009, this new version is supposed to bring support for VB9, core productivity enhancements, and more.
Tweets about .NET tools