Page Comparison - ReSharper PlugIn 4.0(4.1) to 4.5 Migration Guide (v.11 vs v.12)

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

This document describes changes which should be done by ReSharper PlugIn developers to adopt them from ReSharper 4.0(4.1) to the latest ReSharper 4.5 version.

The steps described below are not complete, they will be updated when new unclear issues raise.

1. Assembly References

You should reference new set of assemblies. They are located at \Program Files\JetBrains\ReSharper\v4.5\Bin
Unfortunately, just change path in ".csproj" is not enough, since assembly set is changed dramatically.

2. New namespaces. Types/Methods look-up

In ReSharper 4.5, we've renamed a lot of namespaces, and moved tons of types to different namespace. The primary goal of all this activity is to improve readability and clearness of ReSharper service layers

The good news is that the vast majority of types were not renamed, so just use our "Import Popup" and "Type Name Completion" features to insert correct using directives into your source files!

For example:

  • JetBrains.ReSharper.Daemon.IBulbItem -> JetBrains.ReSharper.Feature.Services.Bulbs.IBulbItem
  • JetBrains.ReSharper.CodeInsight.Services.CodeCleanup.ICodeCleanupModule -> JetBrains.ReSharper.Feature.Services.CodeCleanup.ICodeCleanupModule

Another issue is that we do use extension methods intensively, so tons of service and utility methods were move from static utility classes to extension methods.

For example: MiscUtil.EnumerateMembers(ITypeElement, string, ....) is now should be invoked as typeElement.EnumerateMembers(string, ...)

The general rule is the following: If you cannot locate the utility/service method, try look-up it as extension method for it's first parameter. Usually, the extension methods collection class is named "<entity_name>Extensions"

3. IPsiModule concept

In ReSharper 4.5, we've introduced new entity called "IPsiModule". This is an intermediate abstraction layer between project model as it comes from VisualStudio and our PSI (Program Structure Interface). For regular projects and assemblies, there is 1:1 correspondance between IModule and it's IPsiModule. The difference comes with ASP, and it will be described in details later upon request. Nearly all PSI classes which dealt with IModules in ReSharper 4.0, new deals with IPsiModules

To deal with IPsiModules, there is component called PsiModuleManager.
To get IPsiModule bu project model's IModule, just call

for IProject the corresponding interface is IProjectPsiModule
for IAssembly the corresponding interface is IAssemblyPsiModule

to get IModule (as project model module) from IPsiModule, you should check your IPsiModule for these interfaces, and then ask for their properties.


All this assumptions are valid only while user's projects are not web-projects. For web-project there are few IPsiModules

4. Error Highlighting (AKA Daemon)

There are few changes in error highlighting subsystem, so if your plugin provides custom IDaemonStage or IHighlighting's, you have to update code


Method CreateProcess have got a new parameter of type DaemonProcessKind. Normally you don't need its value and just have to update your code to make it compilable. But sometimes you may check DaemonProcessKind value, for example, to skip your stage from running by Solution-Wide Analysis (that is, on invisible files).


In previous ReSharper's, when daemon stage analysis is done, it returns it's results in DaemonStageProcessResult structure, so the method signature was:

Code Block
interface IDaemonStageProcess {
  DaemonStageProcessResult Execute();

Now this method accepts delegate, which should be called to provide analysis result from stage to the daemon engine:

Code Block
interface IDaemonStageProcess {
  void Execute (Action<DaemonStageResult> commiter)

For regular user stages, instead of returning results, the provided callback should be called as the last stage statement.


New method is introduced into his interface:

Code Block
interface IHighlighting {
  bool IsValid();

If your custom highlighting holds any PSI data (AST element, IDeclaredElements, etc.) you should check if they are still valid here.

5. DeclarationsCacheScope

If your plugin inspects types in solution, you will notice that there is no more DeclarationsCacheScope. To get it, use the following example:

Code Block
// Get declarations scope
IDeclarationsScope scope = DeclarationsScopeFactory.SolutionScope(solution, true);

// Or, to get scope for specific project.
// Note: to get IPsiModule for specific project, look into PsiModuleManager component
IDeclarationsScope scope = DeclarationsScopeFactory.ModuleScope(module, false);

// Now get declaration cache by scope:
IDeclarationsCache cache = PsiManager.GetInstance(solution).GetDeclarationsCache(scope, true);
6. Navigation

There is no more Navigator class to navigate to declaration/declared elements. Instead, use new JetBrains.ReSharper.Feature.Services.Navigation.NavigatorManager component.
The obsolete and removed interface INavigationResult is now encapsulated by new INavigationPoint.

6. PsiSupportManager

The PsiSupportManager component is no more available for plugins. To check if the given project file is compilation unit or not, call

Code Block